-
-
Notifications
You must be signed in to change notification settings - Fork 341
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sharing Twig components #2003
Comments
Use the |
Seems like a solid proposal. Usecase also looks valid. Extra example: |
So, here we are right now: ☑️ Key points:
☑️ Several aditional points:
😃 Good news: we can do almost all of this for anonymous components, easily (and with some form of configuration for PHP-class-based ones) And make things work really smootly like this {{ ux_component('@EasyAdmin:User:Avatar') }} <twig:@EasyAdmin:User:Avatar /> Something like this ? But it's not valid in the IDE's 📑 Some resources: |
it's actually the bundle extension alias; the bundle name is just the fallback if not specified. |
Regarding assets, any assets provided by a bundle is installed in the public directory during install https://symfony.com/doc/current/bundles.html#bundle-directory-structure And with AssetMapper, the path of your bundle is automatically mapped: https://symfony.com/doc/current/frontend/asset_mapper.html#third-party-bundles-custom-asset-paths |
Before we start to handle this in UX, i think this should start with some adjustments into AssetMapper, no ? As of today, TwigComponent have no concept of "page" or "body", so that would be a entirerly new feature i guess. First idea: a lazy stimulus controller + CSS imports ? |
(personal note: this is precisely one of the reason i'd like to release a UXBundle .. make the link between framework bundle and the different ux components, handle configuration, check dependencies / enabled stuff, ...) |
This sounds like a cool idea, it could build the bridge to AssetMapper and WebpackEncore by offering the needed tools to make the asset imports easier, I think automatic handling is cool, but a very simple installation step could also be fine, that then could be automated by flex :)
Personally I would love to see the twig: prefix replacable at some point and especially with bundles, which brings a unique Identifier anyway, it would improve readability so much if you could just do: <MyUXBundle:Button>MyButton</MyUXBundle:Button> Not sure if this is possible, but if I imagine a quite complex component structure we will otherwise see code like this: <twig:MyUXBundleBundle:Table:ActionColumn :foo="bar">MyAction</twig:MyUXBundleBundle:Table:ActionColumn> |
<MyUXBundle:Button>MyButton</MyUXBundle:Button> This is not planned right now, and i'm personally not in favor to do so right now.. as it would be mixed with HTML, custom tags, etc.
Couple of reactions:
As I see it, common IRL usage would look like this: <twig:Bootstrap:Alert message="{{ message }}" type="error" /> Or <twig:Bootstrap:Modal title="Update Post">
{# Defining default block exposed by this component #}
{{ form(update_form) }}
</twig:Bootstrap:Modal> |
I gave it a try, and while there are some improvements to be made, everything proposed (in the initial description) is currently possible. No hacks needed—perhaps a bit of magic! The analysis and explanation are too lengthy for a single comment, so I decided to cover it in a blog post. |
Yeah, I agree on one hand, on the other hand it would be nice to kinda mimic having custom tags, but of course that is a matter of taste and I can follow your argument. I also see that it's not an easy task, it was just something I thought to make it even more immersive when working with symfony ux, it's not the end of the world if people have to learn this
Okay, in that case I think it looks pretty cool, thanks for clarifying <3 |
That's something i've been thinking a looot about these last months too.. but i really think we first need to make some internal changes in the Twig/Live implementation. To summarize very roughly, Twig component do things "for" LiveComponents that make them less agile/performant when used "massively" in a template. So let's focus here on the short-term "sharing component" objective, and open another issue for this with a more "middle/long term" goal ? |
See #2019 as the first step. Loading anonymous components from the bundle following a convention |
Hi folks,
I've been using Twig components for some time, but I mostly used them to code some dynamic UI features.
Lately I'm using more and more Twig components to create UI "building blocks" that later I use to create interfaces. I mostly learned this from this nice blog series by @WebMamba: How to integrate Component Architecture into Symfony?
Now, I need to share those UI components with other applications. But, it looks like this is not possible yet.
The use cases:
(1) ACME company uses the same UI in many apps and want to share these Twig components
(2) A third-party bundle (e.g. SonataAdmin or EasyAdmin) defines components to ease the building of custom features with the same UI
For your consideration, this is how I imagine this feature in practice. Let's use the first use case about ACME company:
(1) Create a new
AcmeUiBundle
(2) Define your PHP-based and anonymous Twig components as usual:
(3) Configure the bundle to tell Symfony that it provides Twig components:
(4) When you install this bundle in a Symfony app with Symfony UX Twig Component installed, you can start using those imported components like this:
Open questions:
<twig:Sonata ...
instead of just<twig:Admin ...
)Thanks!
The text was updated successfully, but these errors were encountered: