Proposal: New Stories and Controls API that leverages ViewComponent Previews #150
jonspalmer
started this conversation in
Ideas
Replies: 2 comments 3 replies
-
For option 2 of defining controls, would it be possible to have the default values be the default values of the preview methods? E.g. controls do
text(:button_text)
end
def ok(button_text: "OK")
render Button component.new(button_text:)
end
def cancel(button_text: "Cancel")
render Button component.new(button_text:)
end |
Beta Was this translation helpful? Give feedback.
1 reply
-
@jonspalmer I think the macros are the ones that make more sense for the controls, maybe would be cool to remove the class ButtonComponentStories < ViewComponent::Storybook::Stories
control :button_text, as: :text, default: "OK"
# or
control :button_text, as: :text, default: -> { "OK #{rand}" }, only: :rand_ok
def ok(button_text: )
render ButtonComponent.new(button_text: button_text)
end
def rand_ok(button_text: )
render ButtonComponent.new(button_text: button_text)
end
end |
Beta Was this translation helpful? Give feedback.
2 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Since this gem's inception there has been a steady background of issues that have been hard to resolve. Most center around the way Controls are declared and the fact that declaring Stories is different in style and feel from ViewComponent Previews.
Examples of these challenges:
The challenges stem from the somewhat convoluted DSL like approach I initially took to controls.
Proposal 1:
ViewComponent::Storybook::Stories
becomeViewComponent::Preview
sSpecifically
class ViewComponent::Storybook::Stories < ViewComponent::Preview
This allows us to take advantage of all the features of
ViewComponent::Preview
- helper tags, custom templates, multiple components etc.Suppose we have a
ButtonComponent
:Today you might declare stories like this
In the new API we simply render a Preview:
Proposal 2: Decouple Control declaration from how and where they're used
Rather than having
constructor
,content
andslot
controls you simply declare controls outside of the story with names that correspond to the story's method params.Today a constructor control is added like this:
Under the proposal you would declare the controls like this:
This approach is simple, powerful and flexible. For example suppose you want to combine two controls in the content of a component. Previously this would require a custom control now we simply declare two controls and use them in the render:
Similarly its easy to see how controls could. be wired up to constructor params, content blocks, slots (polymorphic or not) and a host of other use cases.
Open Question: How should Controls be declared
Key considerations for the Controls API are:
Option 1: Comment Annotations
Inspired by Logbooks approach controls could be declared using custom Yard tags
Pros
Cons
instance_eval
Option 2: Controls helper
Inspired by Rails controller filters
Pros
Cons
Beta Was this translation helpful? Give feedback.
All reactions