Open allan-simon opened 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.
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.
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 :)
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
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.
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.
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.
And some extra context we spoke about on Twitter after :) https://twitter.com/weaverryan/status/1635238713239429120
For the inputs, we could use property access, property info & reflection to help.
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?
yes
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: