Skip to content
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

Open
wants to merge 44 commits into
base: main
Choose a base branch
from

Conversation

boardfish
Copy link
Collaborator

@boardfish boardfish commented Feb 22, 2022

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.generate map back to config.view_component.generate.

The scope of this PR has been extended to have ViewComponent::Base.config be the new source of truth for config. It's mirrored to the ViewComponent::Base class level for backwards compatibility's sake, and also mirrored to app config via the Rails engine. Now, at all times, folks can expect for example ViewComponent::Base.generate.sidecar, Rails.application.config.view_component.generate.sidecar, and ViewComponent::Base.config.sidecar to be functionally equivalent.

@Spone
Copy link
Collaborator

@Spone Spone commented Feb 22, 2022

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?

@boardfish
Copy link
Collaborator Author

@boardfish boardfish commented Feb 22, 2022

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 👍

lib/view_component/base.rb Outdated Show resolved Hide resolved
@boardfish boardfish force-pushed the generate-options-in-config-namespace branch from 21ef508 to 3c9b994 Compare Feb 23, 2022
@boardfish boardfish marked this pull request as ready for review Feb 23, 2022
@boardfish boardfish force-pushed the generate-options-in-config-namespace branch from 3c9b994 to 05fdf79 Compare Feb 24, 2022
@boardfish boardfish force-pushed the generate-options-in-config-namespace branch 2 times, most recently from b4d5497 to 5298d3c Compare Mar 29, 2022
docs/api.md Outdated Show resolved Hide resolved
@boardfish
Copy link
Collaborator Author

@boardfish boardfish commented Mar 29, 2022

Besides the coverage gap, I still need to make ViewComponent::Base.config the source of truth that's mirrored by Rails.application.config.view_component. As it stands, Rails.application.config.view_component being the source of truth breaks rake docs:build, as that doesn't rely on a backing Rails app to deal with components.

@boardfish boardfish marked this pull request as draft Mar 29, 2022
@boardfish
Copy link
Collaborator Author

@boardfish boardfish commented Mar 29, 2022

Alright, I think this is in a much better place now. The functionality is in, but I still need to:

  • Ensure documentation for all config options remains
  • Potentially add a deprecation warning for the config_accessors - ideally, we should get rid of the top-level accessors
  • Get test coverage back up to 100%

@boardfish boardfish changed the title Add generate options to ViewComponent engine config Centralize ViewComponent::Base config Mar 29, 2022
@boardfish boardfish marked this pull request as ready for review Mar 30, 2022
@boardfish boardfish marked this pull request as draft Mar 30, 2022
@boardfish boardfish marked this pull request as ready for review Mar 30, 2022
@boardfish boardfish requested review from Spone and joelhawksley and removed request for Mar 30, 2022
@boardfish
Copy link
Collaborator Author

@boardfish boardfish commented Mar 30, 2022

Think it's good for review again now. I'm not sure we should deprecate the config_accessors until they cause a problem - it's more correct that we shouldn't pollute the class-level namespace for methods with them, but I don't think their existence hinders anything we'd otherwise try to do.

Copy link
Contributor

@joelhawksley joelhawksley left a comment

👏🏻 LOVE it.

lib/view_component/config.rb Show resolved Hide resolved
lib/view_component/config.rb Show resolved Hide resolved
end
end

def initialize(parent = nil)
Copy link
Contributor

@joelhawksley joelhawksley Mar 31, 2022

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...

Copy link
Collaborator Author

@boardfish boardfish Apr 1, 2022

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
Copy link
Contributor

@joelhawksley joelhawksley Mar 31, 2022

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.

Copy link
Collaborator Author

@boardfish boardfish Apr 8, 2022

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.

Copy link
Contributor

@joelhawksley joelhawksley Apr 12, 2022

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?

Copy link
Contributor

@joelhawksley joelhawksley Apr 12, 2022

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 ❤️ )

Copy link
Collaborator Author

@boardfish boardfish Apr 12, 2022

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.

Copy link
Collaborator Author

@boardfish boardfish Apr 12, 2022

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.

Copy link
Contributor

@joelhawksley joelhawksley Jun 8, 2022

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?

test/test_helper.rb Outdated Show resolved Hide resolved
@boardfish boardfish force-pushed the generate-options-in-config-namespace branch from 8ddf6e6 to c7eed01 Compare Apr 5, 2022
@boardfish boardfish requested a review from joelhawksley Apr 11, 2022
@boardfish
Copy link
Collaborator Author

@boardfish boardfish commented Apr 11, 2022

Think this is ready for another pass.

docs/CHANGELOG.md Outdated Show resolved Hide resolved
@boardfish boardfish force-pushed the generate-options-in-config-namespace branch from 0e1e9d7 to 04f603e Compare Jun 3, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants