I noticed in my rails 6 project that adding the following to config/initializers/rails_admin.rb results in a deprecation warning:
RailsAdmin.config do |config|
config.parent_controller = ApplicationController.to_s
# ...
Warning:
DEPRECATION WARNING: Initialization autoloaded the constants ApplicationHelper, AboutHelper, GroupHelper, MapHelper, DeviseHelper, ActionText::ContentHelper, and ActionText::TagHelper.
Being able to do this is deprecated. Autoloading during initialization is going
to be an error condition in future versions of Rails.
Reloading does not reboot the application, and therefore code executed during
initialization does not run again. So, if you reload ApplicationHelper, for example,
the expected changes won't be reflected in that stale Module object.
These autoloaded constants have been unloaded.
Please, check the "Autoloading and Reloading Constants" guide for solutions.
(called from <main> at /opt/app/config/environment.rb:5)
One workaround for this is to simply use "ApplicationController" instead of ApplicationController.to_s, but is there a way to do the latter approach without this deprecation warning?
yes, you are right
# Which class should be used for the controllers
config.parent_controller = '::ApplicationAdminController'
here the issue in the library issue_link
Related
There are probably hundreds of these questions on here but I haven't been able to get one to work yet. I'm using Rails 6 and I always have trouble writing custom modules.
I have a file for creating email tokens: lib/account_management/email_token.rb
module AccountManagement
module EmailToken
def create_email_token(user)
....
end
end
end
Then in my controller I have tried all kinds of things:
require 'account_management/email_token'
include AccountManagement::EmailToken
Calling it with: create_and_send_email_token(user)
At one point I added config.eager_load_paths << Rails.root.join('lib/account_management/') but I didn't think you still had to do that.
Whenever I try to call the controller action I get one of a few error messages:
*** NameError Exception: uninitialized constant Accounts::SessionsController::EmailToken
#this happens if I try to manually send through the rails console
(although inside of a byebug I can call require 'account_management/email_token' and it returns
true.
Most commonly I get:
NoMethodError (undefined method `create_email_token' for #<Accounts::SessionsController:0x00007ffe8dea21d8>
Did you mean? create_email):
# this is the name of the controller method and is unrleated.
The simplest way to solve this is by placing your files in app/lib/account_management/email_token.rb. Rails already autoloads any subdirectory of the app folder*.
/lib has not been on the autoload paths since Rails 3. If you want to add it to the autoload paths you need to add /lib not /lib/account_management to the autoload/eager loading paths. In Zeitwerk terms this adds a root where Zeitwerk will index and resolve constants from.
config.autoload_paths += config.root.join('lib')
config.eager_load_paths += config.root.join('lib')
Note that eager_load_paths is only used when eager loading is turned on. Its turned off by default in development to enable code reloading.
/lib is added to $LOAD_PATHso you can also manually require the file with:
require 'account_management/email_token'
See:
Autoloading and Reloading Constants (Zeitwerk Mode)
Rails #37835
This is a tricky one to explain. I have a module in another module namespace like so:
# app/models/points/calculator.rb
module Points
module Calculator
def self.included(base)
base.send(:include, CommonMethods)
base.send(:include, "Points::Calculator::#{base}Methods".constantize)
end
end
end
So then in other classes all I need to do is:
class User
include Points::Calculator
end
I've specified this directory in application.rb to be autoloadable...(even though i think rails recurses through models...)
config.autoload_paths += Dir[ Rails.root.join('app', 'models', "points") ]
In development env, everything works fine. When running tests(and production env), I get the following error:
Unable to autoload constant Points::Calculator, expected /Users/pete/work/recognize/app/models/points/calculator.rb to define it (LoadError)
I actually followed the advice here to fix the problem: Stop Rails from unloading a module in development mode by explicitly requiring calculator.rb in application.rb.
However, why is this happening??
I stuck some debug output in ActiveSupport's dependencies.rb file and noticed that this file is being required twice. The first time its required I can see that the constant is indeed loaded.
But the 2nd time its required the constant has been unloaded as far as Rails can tell, but when the actual require is called, ruby returns false because ruby knows its already required it. Then Rails throws the "unable to autoload constant" error because the constant still isn't present and ruby didn't "re-require" the file.
Can anyone shed light on why this might be happening?
Rails augments the constant lookup mechanism of ruby.
Constant lookup in Ruby:
Similar to method missing, a Module#constant-missing is invoked when a reference to a constant fails to be resolved. When we refer to a constant in a given lexical scope, that constant is searched for in:
Each entry in Module.nesting
Each entry in Module.nesting.first.ancestors
Each entry in Object.ancestors if Module.nesting.first is nil or a module.
When we refer to a constant, Ruby first attempts to find it according to this built-in lookup rules.
When ruby fails to find... rails kicks in, and using its own lookup convention and its knowledge about which constants have already been loaded (by ruby), Rails overrides Module#const_missing to load missing constants without the need for explicit require calls by the programmer.
Its own lookup convention?
Contrasting Ruby’s autoload (which requires the location of each autoloaded constant to be specified in advance) rails following a convention that maps constants to file names.
Points::Calculator # =>points/calculator.rb
Now for the constant Points::Calculator, rails searches this file path (ie 'points/calculator.rb') within the autoload paths, defined by the autoload_paths configuration.
In this case, rails searched for file path points/calculator in its autoloaded paths, but fails to find file and hence this error/warning is shown.
This answer is an abstract from this Urbanautomation blog.
Edit:
I wrote a blog about Zeitwerk, the new code reloader in Rails. Check it out at -> https://blog.bigbinary.com/2019/10/08/rails-6-introduces-new-code-loader-called-zeitwerk.html
If someone is having this issue in rails 6 which has zeitwerk autoloader,
Change ruby constant lookup back to classic in your application.rb
# config/application.rb
#...
config.autoloader = :classic
#...
Read more details here Rails Official Guides
Calculator should be a class to be autoloaded correctly
module Points
class Calculator
...
end
end
This is how a typical config/environments/*.rb file begins:
MyApp::Application.configure do
config.cache_classes = false
...
end
The block passed to configure dereferences the symbol config which is apparently unbound. How does this technically work? The symbols used in a block/Proc/lambda should be bound in the context of its declaration, not left to be resolved in the dynamic scope at the call site.
A related question is, where exactly is the Application.configure method declared? It's not in either application.rb, engine.rb, or railtie.rb. Maybe if I managed to find this method, I would have found the answer to my main question.
Also related, I have studied the Rails initialization procedure in excruciating detail, and I can't find even a mention of a config/environments/*.rb file. If I knew how these files were treated by the init procedure, that may shed some light on this.
It's a method config in Rails::Application in the railties gem in lib/rails/application.rb which returns an instance of Application::Configuration, defined in lib/rails/application/configuration.rb.
The method configure is contributed to Railtie from the autoloaded module Configurable, lib/rails/railtie/configurable, and is defined as
def configure(&block)
class_eval(&block)
end
which explains why the block that configure accepts can resolve the config symbol. Note that class_eval is another piece of rubyist magic that makes this work: it rebinds the passed-in block's self symbol to the call site's class.
Check the comments in the first file in the Booting Process section, which explains where, how and in what order all this goodness comes from, including how the /config/environments directory is processed.
When storing files in a custom directory (Eg: app/presenters/), how do you ensure that namespaced classes are loaded?
For example, if you have:
app/models/mega_menu.rb
app/presenters/catalog_presenter.rb
app/presenters/mega_menu/catalog_presenter.rb
Rails fails to load MegaMenu::CatalogPresenter:
CatalogPresenter.new
=> #<CatalogPresenter:0x85bca68 #_routes=nil>
MegaMenu::CatalogPresenter.new
(irb):3: warning: toplevel constant CatalogPresenter referenced by MegaMenu::CatalogPresenter
=> #<CatalogPresenter:0x85750a0 #_routes=nil>
I've created a sample Rails 3.2 app that reproduces this problem.
In config/application.rb, the app's configured to load files in app/presenters/.
I solved this issue by using a require statement in an initializer. I don't like it much but I liked the structure and class names of my application, they made sense so an initializer was my best solution. In the initializer try:
require File.join(Rails.root, "app", "presenters", "mega_menu", "catalog_presenter")
require File.join(Rails.root, "app", "presenters", "catalog_presenter")
This problem occurs because autoload relies on const_missing being called which won't happen in your case.
When ruby first encounters a reference to MegaMenu::CatalogPresenter, the mega_menu/catalog_presenter.rb file has not been included. Standard ruby behaviour causes it walks up the namespace tree (figure of speech) and it instead finds the top level reference CatalogPresenter as this HAS been included at this point.
Creating new toplevel constants inside classes raises this error. You want something more like this in catalog_presenter.rb:
class MegaMenu
class MegaMenu::CatalogPresenter
end
end
Can anyone tell me how to silence deprecation warinings in Rails 3?
I have a few situations where it is throwing false positives. Namely using - for loops in haml and f.error_messages from the dynamic_form plugin.
Thanks
To silence all deprecation warnings you can do:
ActiveSupport::Deprecation.silenced = true
This could be placed in an initializer or in the environment file for a specific environment (e.g. to silence only in production for example.)
Or for a specific section of code, enclose it in a block:
ActiveSupport::Deprecation.silence do
# no warnings for any use of deprecated methods here
end
This works for both Rails 3 & 4.
The accepted answer didn't work for me with Rails 3.2.12. Placing it in either the environments/production.rb or an initializer still outputted the warnings. I had to put it in my config/environment.rb file before the application was initialized:
# Load the rails application
require File.expand_path('../application', __FILE__)
::ActiveSupport::Deprecation.silenced = true if Rails.env.production?
# Initialize the rails application
Notices::Application.initialize!
Ryan Daigle wrote an article about this, in which he also showed how you can intercept the deprecation warning and do something else with it, like send it to a log file:
ActiveSupport::Deprecation.behavior = Proc.new { |msg, stack| MyLogger.warn(msg) }
http://ryandaigle.com/articles/2006/12/4/how-to-turn-deprecation-warnings-off-in-rails