[RFC] Embeddable Stories

[KrystilizeNevaDies]

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

1. Add support for serialisation of nested stories - nested stories should be a string in the ui for now.
2. Enable rendering and resolve any platform-specific rendering issues if applicable.
3. 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?

Alternatives considered / Abandoned Ideas

No response