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
Centralize ViewComponent::Base config #1291
base: main
Are you sure you want to change the base?
Conversation
|
Thanks for your quick diagnosis! How come our tests did not catch this? Can we write some tests do make sure we do not break this in the future? |
|
I've just done a quick run-through and a lot of the config options claim to default to certain values when they're actually falsy, so I'll correct that too. And you're right that I should get some tests in place |
21ef508
to
3c9b994
Compare
3c9b994
to
05fdf79
Compare
b4d5497
to
5298d3c
Compare
|
Besides the coverage gap, I still need to make |
|
Alright, I think this is in a much better place now. The functionality is in, but I still need to:
|
generate options to ViewComponent engine config|
Think it's good for review again now. I'm not sure we should deprecate the |
| end | ||
| end | ||
|
|
||
| def initialize(parent = nil) |
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.
In what case is this argument used? I wonder if this is a case for deprecating support for Ruby 2.6...
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 think I had to keep the method signature this way for all cases. Maybe ActiveSupport::Configurable tries to use it? It might hinder composing around InheritableOptions as you mentioned elsewhere, but I'll investigate further and give it a shot.
| require "view_component/deprecation" | ||
|
|
||
| module ViewComponent | ||
| class Config < ActiveSupport::InheritableOptions |
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.
What do you think about composing around InheritableOptions instead of inheriting from it? It might help us avoid overwriting the initializer, etc.
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.
Makes sense to do, but InheritableOptions is a class and not a module, so I'm not sure how I'd go about this.
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.
@boardfish in general terms, what I mean is that we would initialize a new ActiveSupport::InheritableOptions in the Config initializer, then call methods on it in Config, instead of subclassing. Does that make sense?
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'd also be open to some pairing time if you'd like! We're overdue as it is
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.
Ah, I see what you mean now - I'll give it a rejig and see where we get to.
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.
And it might also be good to pair to really wrap this up! I'll be in touch at some point.
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.
@boardfish would you like to pair on this?
8ddf6e6
to
c7eed01
Compare
|
Think this is ready for another pass. |
7893e28
to
430d80b
Compare
ALl it did was make preview-related config accessible on ViewComponent::Base
The pieces are in place, but I think the final aim is that everything for which there's a default and/or a reader is documented
0e1e9d7
to
04f603e
Compare
Co-authored-by: Joel Hawksley <joel@hawksley.org>
Summary
@Spone recognized that the generator options aren't available with the rest of the ViewComponent config options. This PR fixes that by having
ViewComponent::Base.generatemap back toconfig.view_component.generate.The scope of this PR has been extended to have
ViewComponent::Base.configbe the new source of truth for config. It's mirrored to theViewComponent::Baseclass level for backwards compatibility's sake, and also mirrored to app config via the Rails engine. Now, at all times, folks can expect for exampleViewComponent::Base.generate.sidecar,Rails.application.config.view_component.generate.sidecar, andViewComponent::Base.config.sidecarto be functionally equivalent.