-
-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Zeitwerk-based, efficient, decorators loader #60
Conversation
6b4c1ee
to
6ba6c9b
Compare
I like this a lot! It's not clear if the current change is backward compatible though. Do we need to change all stores/extensions to make it work once we merge/release this? |
It supports both zeitwerk and classic and can be adapted to cover existing stores and extensions. |
6ba6c9b
to
eb07e8f
Compare
eb07e8f
to
7b1bee3
Compare
Co-Authored-By: Andrea Longhi <[email protected]>
63a72ed
to
ee62cb0
Compare
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
@elia @kennyadsl is this still necessary now that we bumped Rails to >= 7.0 and a fix (#86) has been merged? |
Closing it, the diff will still be there in case anyone wants to dig it up 👍 |
This is inspired by solidusio#60. We can leverage Zeitwerk's `on_load` hook and it's capacity of knowing which constant a file should define in order to load decorators, including when reloading. This should greatly speed up reloading, as only those decorators that are needed for the current request are loaded. However, there is a few restrictions that come with this: 1. All decorators MUST use a Zeitwerk-compatible naming scheme 2. All decorators MUST use Module.prepend, where Module is the fully qualified class name being modified. Co-Authored-By: [email protected]
This is inspired by solidusio#60. We can leverage Zeitwerk's `on_load` hook and it's capacity of knowing which constant a file should define in order to load decorators, including when reloading. This should greatly speed up reloading, as only those decorators that are needed for the current request are loaded. However, there is a few restrictions that come with this: 1. All decorators MUST use a Zeitwerk-compatible naming scheme 2. All decorators MUST use Module.prepend, where Module is the fully qualified class name being modified. Co-Authored-By: [email protected]
This is inspired by solidusio#60. We can leverage Zeitwerk's `on_load` hook and it's capacity of knowing which constant a file should define in order to load decorators, including when reloading. This should greatly speed up reloading, as only those decorators that are needed for the current request are loaded. However, there is a few restrictions that come with this: 1. All decorators MUST use a Zeitwerk-compatible naming scheme 2. All decorators MUST use Module.prepend, where Module is the fully qualified class name being modified. Co-Authored-By: [email protected]
This is inspired by solidusio#60. We can leverage Zeitwerk's `on_load` hook and it's capacity of knowing which constant a file should define in order to load decorators, including when reloading. This should greatly speed up reloading, as only those decorators that are needed for the current request are loaded. However, there is a few restrictions that come with this: 1. All decorators MUST use a Zeitwerk-compatible naming scheme 2. All decorators MUST use Module.prepend, where Module is the fully qualified class name being modified. Co-Authored-By: [email protected]
This work is built on the awesome work by @fxn on zeitwerk for Rails and @aldesantis on prependers for Solidus
The code in this PR has been tried successfully on a couple of real-world projects with multi-year legacy. The basic principle is that we should only load the decorators for the base classes that are required for the current request, finally playing nice with Rails own autoloading/reloading mechanisms.
One thing that was very interesting is seeing classes autoloaded from initializers (which is an anti-pattern) and the ripple effect they create in terms of loading their dependencies, fixing that kind of stuff would make Solidus stores startup virtually as fast as a pristine Rails app.
As a side note this work will be also proposed for the Rails guides that currently suggest eagerly loading all the decorators, we think, for lack of a better alternative.
from the inline documentation