Skip to content

Commit 0b15b7d

Browse files
committed
More examples in the autoloading guide
1 parent 43ff2bf commit 0b15b7d

File tree

1 file changed

+13
-12
lines changed

1 file changed

+13
-12
lines changed

guides/source/autoloading_and_reloading_constants.md

Lines changed: 13 additions & 12 deletions
Original file line numberDiff line numberDiff line change
@@ -258,7 +258,7 @@ NOTE: For historical reasons, this callback may run twice. The code it executes
258258

259259
### Use case 2: During boot, load code that remains cached
260260

261-
Some configurations take a class or module object, and they store it in a place that is not reloaded, for example, within the state of the framework.
261+
Some configurations take a class or module object, and they store it in a place that is not reloaded.
262262

263263
One example is middleware:
264264

@@ -277,22 +277,23 @@ Rails.application.config.active_job.custom_serializers << MoneySerializer
277277

278278
Whatever `MoneySerializer` evaluates to during initialization gets pushed to the custom serializers. If that was reloadable, the initial object would be still within Active Job, not reflecting your changes.
279279

280-
Corollary: those classes or modules **cannot be reloadable**.
280+
Yet another example are railties or engines decorating framework classes by including modules. For instance, [`turbo-rails`](https://github.com/hotwired/turbo-rails) decorates `ActiveRecord::Base` this way:
281281

282-
The easiest way to refer to those classes or modules during boot is to have them defined in a directory which does not belong to the autoload paths. For instance, `lib` is an idiomatic choice. It does not belong to the autoload paths by default, but it does belong to `$LOAD_PATH`. Just perform a regular `require` to load it and done.
283-
284-
As noted above, another option is to have the directory that defines them in the autoload once paths:
285-
286-
```
287-
# config/application.rb
288-
module YourApp
289-
class Application < Rails::Application
290-
config.autoload_once_paths << Rails.root.join('app', 'serializers')
282+
```ruby
283+
initializer "turbo.broadcastable" do
284+
ActiveSupport.on_load(:active_record) do
285+
include Turbo::Broadcastable
291286
end
292287
end
293288
```
294289

295-
in this option, you can autoload serializers during initialization, because they are managed by the `once` autoloader.
290+
That adds a module object to the ancestor chain of `ActiveRecord::Base`. Changes in `Turbo::Broadcastable` would have no effect if reloaded, the ancestor chain would still have the original one.
291+
292+
Corollary: Those classes or modules **cannot be reloadable**.
293+
294+
The easiest way to refer to those classes or modules during boot is to have them defined in a directory which does not belong to the autoload paths. For instance, `lib` is an idiomatic choice. It does not belong to the autoload paths by default, but it does belong to `$LOAD_PATH`. Just perform a regular `require` to load it and done.
295+
296+
As noted above, another option is to have the directory that defines them in the autoload once paths and autoload. Please check the [section about config.autoload_once_paths](https://edgeguides.rubyonrails.org/autoloading_and_reloading_constants.html#config-autoload-once-paths) for details.
296297

297298
Eager Loading
298299
-------------

0 commit comments

Comments
 (0)