symfony / ux

Symfony UX initiative: a JavaScript ecosystem for Symfony
https://ux.symfony.com/
MIT License
824 stars 298 forks source link

[Twig component] How to have a storybook like feature ? #624

Open allan-simon opened 1 year ago

allan-simon commented 1 year ago

It's an open question, but a great feature that goes with components is the ability to easily see them all and have a way to interactively play with them

I wonder if:

  1. should it be directly handled by the component ? (i.e in dev mode , to have in the toolbar a page listing them all ?)
  2. should it be a plugin to something like Storybook though it seems specifically oriented to react ?
weaverryan commented 1 year ago

That's a really cool idea :).

Maybe a dev-only (or perhaps you could make it on prod, but "admin only") section - e.g. /_twig_components that shows all of the components. The tricky part is the "input": if a component requires, for example, a Post object, there needs to be some way to declare what needs to be passed to each component and how to find/get that data. But I really like this.

sabat24 commented 1 year ago

We tried such approach in our last project. Based on https://wingsuit-designsystem.github.io/ we changed their include approach into the component one. We created a Maker for Twig Components and a parser which is able to generate php class from yaml storybooks definition. It works nice for atoms and molecules as the components are quite "dumb". There is no much logic and simple data.

The downside was the maintain process. There had to be a Storybook first approach. If you want to change anything, you had to change that thing in Storybook then run parser tools to update php class and recreate template. The flexibility of such components were also limited as in Storybook you weren't able to use many things from Stimulus.

weaverryan commented 1 year ago

Hmm, interesting. So, to ask a bold question since you have real-world experience: how should it ideally work? You mentioned potentially as a Storybook plugin. Do you think that's the correct approach? If so, feasible? I don't yet have direct experience with Storybook, which is why I'm asking :). Or, would be it just as easy to implement something ourselves, without Storybook (or is that a horrible idea because Storybook is so feature-rish)?

thx :)

allan-simon commented 1 year ago

Maybe a dev-only (or perhaps you could make it on prod, but "admin only") section - e.g. /_twig_components

yes that would make sense

The tricky part is the "input": if a component requires, for example, a Post object, there needs to be some way to declare what needs to be passed to each component and how to find/get that data. But I really like this.

I would offload that to the user , i.e

  1. you may require the user to implement an interface a ( StoryBookComponentInitator , i'm bad at naming) that provide a) a methd that describe a list scalar input needed to have all the information b) a method that instantiate the component from said inputs , and so the list of component displayable in the "story book" would be dependant of how many initator there are
  2. as a bonus you may do that automagically if the constructor of the component is only scalar properties
excitedbox commented 1 year ago

Have you checked out the bolt design system. It may be a good starting point and it supports twig out of the box. It is based on pattern lab which is what lead to the development of storybooks if I remember correctly.

sabat24 commented 1 year ago

Hmm, interesting. So, to ask a bold question since you have real-world experience: how should it ideally work?

Storybook is mainly an isolated environment for components, working as their library. Its primary purpose is to allow coders to create a project elements based on materials provided by graphic designers in nice, object oriented way. They are able to create properties for components and mock all data they need.

However, Storybook's main strength lies in its interface and additional capabilities. Take a look at this video:

https://storybook.js.org/cdb19b23da5e96c112ff3b8fded28a82/storybook-hero-video-optimized-lg.mp4

You have got a defined list of properties, which you can easily change and provide any data you want. It's great for all kind of testing how component will look like when something change. There is also a documentation tab and code generator, how to insert such component in real application (for example include statement for twigs).

There is only one rule. You should use exactly same css and js files in Storybook and your application and keep same structure of elements and templates. This is because the only thing you should do when adding a component to your project is paste the storybook generated code (and replace mocked data with real ones).

In my opinion the best option would be use Live Components as a Storybook and create a some live components which provide the whole interface for presenting Twig Components. Live components can also refresh automatically the preview of component during user interaction.

I will try to test this approach in our next project.

GromNaN commented 1 year ago

Just published an article about using @storybook/server to render Twig templates in Storybook.

To have a useful integration of Storybook with Symfony, it should not be reserved to Twig Components as simple UI components can be single twig files.

The first part to work it the a generic controller that renders a template.

weaverryan commented 1 year ago

And some extra context we spoke about on Twitter after :) https://twitter.com/weaverryan/status/1635238713239429120

kbond commented 1 year ago

For the inputs, we could use property access, property info & reflection to help.

carsonbot commented 5 months ago

Thank you for this suggestion. There has not been a lot of activity here for a while. Would you still like to see this feature?

allan-simon commented 5 months ago

yes