You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This proposal is aimed to enable storybook users to recursively nest stories within each other for preview/debugging purposes.
This means that you should be able to select another story to embed into your selected story where applicable (e.g. react's children field), and you should then be able to also edit/view properties of this embedded story.
Problem Statement
While Storybook has the capability to help development, testing and documentation of individual components, it lacks the ability to quickly do the same for nested components, often requiring templates or manually nesting components with a render function.
This RFC aims to solve the problem of having no (UI-only) way to nest and test components.
Non-goals
Drastically changing the UI is not a part of this proposal.
Changing existing apis is not a part of this proposal.
Implementation
I propose that we introduce a serialisation change so that we can directly nest properties within another story preview.
I also propose that we implement the selection of other stories by dragging stories from the Explorer Tree into an applicable nesting field.
Doing this:
Should result in this:
Determining which fields should be able to nest stories would be the responsibility of the framework.
Prior Art
No response
Deliverables
Add support for serialisation of nested stories - nested stories should be a string in the ui for now.
Enable rendering and resolve any platform-specific rendering issues if applicable.
Create the drag and drop ui. The dragging should actually move the element from the tree instead of the inbuilt browser dragging, and the nested field should display the stories' properties. Make sure that this works with nesting components within nested components.
Risks
These set of changes may make serialisation much more complex, we can mitigate this by keeping our serialisation model simple. A story id field, and a field for the story's natural unedit data will help with this.
There is also the risk that urls may grow too large. This can be mitigated by nesting the current url format instead of embedding json into the url.
Unresolved Questions
How will this effect serialisation - are there unimagined consequences?
Do these ui additions fit in with the rest of the codebase?
Will there be any complex changes to framework backends to make this work?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Status: in-review; championed by @shilman
Summary
This proposal is aimed to enable storybook users to recursively nest stories within each other for preview/debugging purposes.
This means that you should be able to select another story to embed into your selected story where applicable (e.g. react's
children
field), and you should then be able to also edit/view properties of this embedded story.Problem Statement
While Storybook has the capability to help development, testing and documentation of individual components, it lacks the ability to quickly do the same for nested components, often requiring templates or manually nesting components with a render function.
This RFC aims to solve the problem of having no (UI-only) way to nest and test components.
Non-goals
Drastically changing the UI is not a part of this proposal.
Changing existing apis is not a part of this proposal.
Implementation
I propose that we introduce a serialisation change so that we can directly nest properties within another story preview.
I also propose that we implement the selection of other stories by dragging stories from the Explorer Tree into an applicable nesting field.
Doing this:
Should result in this:
Determining which fields should be able to nest stories would be the responsibility of the framework.
Prior Art
No response
Deliverables
Risks
Unresolved Questions
Alternatives considered / Abandoned Ideas
No response
Beta Was this translation helpful? Give feedback.
All reactions