-
Notifications
You must be signed in to change notification settings - Fork 445
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
WIP: Extract strict_helpers_enabled? to component-local config #2092
base: introduce-component-local-config
Are you sure you want to change the base?
WIP: Extract strict_helpers_enabled? to component-local config #2092
Conversation
lib/view_component/base.rb
Outdated
|
||
if child.superclass == ViewComponent::Base | ||
child.define_singleton_method(:config) do | ||
@@config ||= Rails.application.config.view_component.inheritable_copy |
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 leave a comment to this effect, but ViewComponent::Base starts out with the defaults. These overrides allow subclasses to inherit from Rails.application.config to start with and cascade down from there.
To achieve our goal of making sure that changes to config don't broadly interfere with gems that want to integrate with ViewComponent, we should probably make it easier here for folks to override config
with a base 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.
I guess this'll be done by gems having their own ApplicationComponent
equivalent now that directly inherits from Base
.
56f28b9
to
001de33
Compare
Made some good progress today, but I'm struggling to diagnose the failure with the generator. Looks like it's not creating anything at all, but the generator does finish and run its I should probably also remove |
@boardfish sorry for not being supper active, I have just been extemly busy, I will try my best to make time to look at this this week |
No problem at all! I think this is almost ready as far as getting back to parity with what we have already - just need to diagnose and fix that failing test. Because this touches config as a whole, I think there's probably wider discussion necessary about how to roll this out – it's a breaking change, and I think it might be difficult to fully preserve the old behaviour as an option. |
I think that approach makes sense, with the plan to remove the old behavior in v4 ❤️ |
That's good @joelhawksley – so just to be totally clear, the current state of this PR means that folks still interface with global config via I guess as far as v4, we can try and draw distinctions between global config ( |
8380bd0
to
8c737f6
Compare
ViewComponent::Base itself will always use the defaults. Any classes inheriting from ViewComponent::Base will cascade config down using InheritableOptions, only specifying any overrides. Generate options being on their own "layer of config is currently unresolved - it might be that config needs to be a new object inheriting from InheritableOptions that has method accessors for everything in that namespace. This was initially written to support extracting the incoming strict_helpers_enabled? option, but applies to everything.
…config as necessary
I've opened #2124 to introduce component-local config in isolation of Reegan's original PR, EDIT: It's green now – @reeganviljoen, it might be a good idea for you to rebase #1987 onto #2124 to separate the two changes. There are some things I've needed to drop from my commits here because that PR won't actually create component-local config, only reshuffle things to make it a possibility. |
No settings actually use it, but this would be the way to introduce it once we come to need it.
ViewComponent::Base itself will always use the defaults. Any classes inheriting from ViewComponent::Base will cascade config down using InheritableOptions, only specifying any overrides. Generate options being on their own "layer of config is currently unresolved - it might be that config needs to be a new object inheriting from InheritableOptions that has method accessors for everything in that namespace. It seems like this solution is now applicable to everything, not just strict_helper_enabled?
…config as necessary
8c737f6
to
e8bc4ef
Compare
161cee3
to
6378768
Compare
2dcc88d
to
62e0960
Compare
3ef2840
to
51e99fb
Compare
Based on #1987
Aims to have
strict_helpers_enabled?
able to be set at an application level byRails.application.config.view_component
without affecting the base value for the setting stored onViewComponent::Base
, which may be consumed by gems.