-
Notifications
You must be signed in to change notification settings - Fork 429
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
Initialize ViewComponent::Config with defaults before framework load #1774
Conversation
cb03c95
to
a9fb769
Compare
7a89729
to
e4268dc
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @boardfish thanks for working on this. I don't understand how current
get set - there doesn't appear to be any call to it?
I think the class_attribute :current, default: defaults, instance_predicate: false |
This reverts commit 01510f3.
This commit introduces `ViewComponent::Config.current`, which should not be used directly by consumers of ViewComponent, but is used as the common thread from which `ViewComponent::Base` and `Rails.application.config.view_component` will load their config once each is ready. It'll make config available from the very start with the intent of not relying upon the framework to find these options - we can manually set anything reliant on Action View, for example, within app/engine config.
e4268dc
to
a3ed95f
Compare
Hey folks, is there anything else you'd like me to do with this so we can get it shipped? I'm aware there are now multiple issues that this will fix. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me!
lib/view_component/preview.rb
Outdated
@@ -4,7 +4,7 @@ | |||
|
|||
module ViewComponent # :nodoc: | |||
class Preview | |||
include Rails.application.routes.url_helpers if defined?(Rails.application.routes.url_helpers) | |||
include Rails.application.routes.url_helpers if Rails && Rails.application.present? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we still need the defined?
check to support non-Rails environments?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I think this must've fallen through in a rebate 🧐 I'll make sure to fix it before it gets merged.
@Spone looks like there's a coverage issue as well 😦 |
Do you know what's happening with the coverage @boardfish? |
I think it wants |
Thank you all for your work on this! I ran into this issue today and went down a rabbit hole trying to figure it out. I really appreciate all the work you're doing to maintain VC. |
Thanks for wrapping this up @camertron, and sorry I haven't been able to dedicate the time to it! 😅 🙏 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll open a new PR to address this feedback since this one is already merged
@@ -4,7 +4,7 @@ | |||
|
|||
module ViewComponent # :nodoc: | |||
class Preview | |||
include Rails.application.routes.url_helpers if defined?(Rails.application.routes.url_helpers) | |||
include Rails.application.routes.url_helpers if defined?(Rails) && Rails.application.present? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think #1774 (review) was resolved correctly - I think ultimately this change can be reverted.
Originally @boardfish had committed
diff --git a/lib/view_component/preview.rb b/lib/view_component/preview.rb
index e80087404..3176e4ecd 100644
--- a/lib/view_component/preview.rb
+++ b/lib/view_component/preview.rb
@@ -4,7 +4,7 @@
module ViewComponent # :nodoc:
class Preview
- include Rails.application.routes.url_helpers
+ include Rails.application.routes.url_helpers if Rails && Rails.application.present?
include ActionView::Helpers::TagHelper
include ActionView::Helpers::AssetTagHelper
extend ActiveSupport::DescendantsTracker
in e4268dc before 0d6564a had landed in master
. When the PR was later rebased, this change should've been dropped, as @boardfish realized in #1774 (comment).
Technically, it's possible (though admittedly weird) to have an environment where Rails.application
is present even if Rails.application.routes.url_helpers
is not defined - and the change introduced here would no longer handle that correctly.
# Replaces the entire config. You shouldn't need to use this directly | ||
# unless you're building a `ViewComponent::Config` elsewhere. | ||
attr_writer :config |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need to regenerate the YARD docs after removing this.
# @!attribute current | ||
# @return [ViewComponent::Config] | ||
# Returns the current ViewComponent::Config. This is persisted against this | ||
# class so that config options remain accessible before the rest of | ||
# ViewComponent has loaded. Defaults to an instance of ViewComponent::Config | ||
# with all other documented defaults set. | ||
class_attribute :current, default: defaults, instance_predicate: false |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Likewise, we need to regenerate the YARD docs to include this.
…iewComponent#1774) * Revert "Avoid loading ActionView::Base during initialization (ViewComponent#1659)" This reverts commit 01510f3. * Initialize ViewComponent::Config with defaults before framework load This commit introduces `ViewComponent::Config.current`, which should not be used directly by consumers of ViewComponent, but is used as the common thread from which `ViewComponent::Base` and `Rails.application.config.view_component` will load their config once each is ready. It'll make config available from the very start with the intent of not relying upon the framework to find these options - we can manually set anything reliant on Action View, for example, within app/engine config. * Only include URL helpers if app is loaded * Get this across the finish line --------- Co-authored-by: Cameron Dutro <camertron@gmail.com>
…iewComponent#1774) * Revert "Avoid loading ActionView::Base during initialization (ViewComponent#1659)" This reverts commit 01510f3. * Initialize ViewComponent::Config with defaults before framework load This commit introduces `ViewComponent::Config.current`, which should not be used directly by consumers of ViewComponent, but is used as the common thread from which `ViewComponent::Base` and `Rails.application.config.view_component` will load their config once each is ready. It'll make config available from the very start with the intent of not relying upon the framework to find these options - we can manually set anything reliant on Action View, for example, within app/engine config. * Only include URL helpers if app is loaded * Get this across the finish line --------- Co-authored-by: Cameron Dutro <camertron@gmail.com>
This PR introduces
ViewComponent::Config.current
, which should not be used directly by consumers of ViewComponent, but is used as the common object from whichViewComponent::Base
andRails.application.config.view_component
will load their config once each is ready. It'll make config available from the very start with the intent of not relying upon the framework to find these options - we can manually set anything reliant on Action View, for example, within the app or engine config.#1659 made the config object empty before ViewComponent and Rails were initialised. This would mean that code within ViewComponent that relied on configured defaults would break, resulting in issues like #1741. Since ViewComponent::Config can be loaded independently of Action View, this should hopefully no longer be the case.
If you were affected by #1741, please test against this branch to see if it fixes your issue. Thanks for your patience!