-
-
Notifications
You must be signed in to change notification settings - Fork 354
[Toolkit] Introduce the UX Toolkit ✨ #2539
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
base: 2.x
Are you sure you want to change the base?
Conversation
Let's get to work! 👏 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
First comments on "form" only, just to warn early about some details
Wow, that's a awesome PR! 👏 |
I really like the component idea, but is there any particular reason to store components source code in a json file rather than going through stubs files? I'm afraid it's going to be hard to maintain because you'll have to remember to explicitly include line breaks, indentation and proper escaping! Wouldn't it be better to have the code directly in Unless json are automatically generated 🤔? |
@ker0x yes, all JSON files are automatically generated from the Relying on JSON files may evolve, but for now, it is the simplest and most sustainable solution we've found. It allows for easy discoverability of components, and generating the files is very straightforward. That being said, if we find a way to eliminate the need for them entirely, this approach may change. |
@Halleck45 Thanks for the clarification! I hadn't seen the . But if they're automatically generated, then I don't see any problem in using this format 👍 |
Are you planning to make a component accessible like this: Do you need any help? I can offer some time to contribute to this awesome PR. Thanks for your work! |
This looks very interesting. Thanks! A quick question: how can third-party bundles (e.g. SonataAdmin or EasyAdmin) install and use these UI components to build their interfaces? |
@nfacciolo For now, yes (or rather twig:Button simply). In the future, the syntax might eventually evolve to on its own, but that's something to discuss, think about, etc., in another PR. Yes, help is very welcome, that would be great! We need to adjust quite a few things, but there are tons of components left to build and a lot of documentation to write. The easiest way is probably to connect on the Symfony Slack.
@javiereguiluz Hi! I'm not sure I fully understand the question. As it stands, the components will be freely available for everyone to use and will be 100% customizable. Any Symfony project will be able to integrate them. Was that the intent of your question? |
@Halleck45 let me explain what I mean. You said that using elements from this UI toolkit will be as easy as: (1) Run this command OK. Now, I'm developing a third-party bundle (e.g. EasyAdmin) that has a lot of UI features and I want to use this button from UX toolkit. So, I run the command In those cases, can third-party bundles just copy+paste some files manually from the UX repository to use those components or does this need more configuration + wiring? Thanks |
Hey @javiereguiluz, indeed the command But we will also provide a manual installation (copy/paste) for each components, that will be visible on ux.symfony.com. |
Hi @Halleck45 |
Yes it wil be tightly coupled to Tailwind (since we re-use examples from Shadcn). Thanks to the "pull" system we are implementing (like Shadcn does), the code you download will be yours and so open to fully customization. If you want to drop Tailwind for something else, you can, and yes CVA will make things easier on this point. Also, surely in the future, we may propose other "themes" that can be based on another CSS framework, like Bootstrap for example. |
I'm curious to see some components like dialog or dropdown 😊. |
Thanks @Halleck45 for this change. I tested some of the components (simple copy & paste) and saw that there needs to be additional configuration for Tailwind. There are currently no defined theme variables for things like |
Hi ! We are planning two things:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your work, here are my final review comments. After, I believe we would be ready to merge the PR and continue to iterate on Toolkit.
Thanks!
src/Toolkit/templates/default/examples/Breadcrumb/BreadcrumbDefault.html.twig
Outdated
Show resolved
Hide resolved
src/Toolkit/templates/default/examples/Card/CardBasic.html.twig
Outdated
Show resolved
Hide resolved
src/Toolkit/templates/default/examples/Table/TableDefault.html.twig
Outdated
Show resolved
Hide resolved
Amazing job guys! If i find time i'll review what I can without bothering you too much tomorrow or tuesday, but don"t wait for it, it may also never come :) |
8895b81
to
6e56056
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's perfect 😍
(😇)
2e799ac
to
636acd5
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
First round.
Following internal discussions, I've just removed |
… UXToolkitBundle,
…itecture, and value-objects - The registry system and JSON serialization were fully reworked, no more useless compilation to JSON - Rename "default" theme to "shadcn" - The "theme" term is now known as "kit" useless JSON serialization - Abuse ValueObjects usage for File, Example, Dependency, ... - Add binary for vendors
…allow PHP 8.1 minimal support
Sorry for the rebase, but I had some conflicts after merging #2695 |
…ription/uxIcon/installation steps in `Kit` VO
Following numerous discussions with various people, I'm opening this PR as a draft for a potential ux-toolkit component. This is the result of a joint reflection with @Kocal and @smnandre .
I’m not speaking on their behalf, but summarizing my interpretation of our discussions. Of course, @Kocal and @smnandre, feel free to correct, adjust, or add anything as needed.
Why?
Saving time
Creating Twig components like Badge or Button seems to be a very common step. The same work appears to be done over and over again, with minor differences from one company to another.
Providing a "packaged" toolkit would allow these companies and developers to save time by starting from ready-made templates.
Simplifying the process
Today, a beginner coming to Symfony has a lot to learn. Onboarding on a Symfony project can feel overwhelming, so it makes sense to offer them the most pleasant experience possible—including making it as easy as possible to create a clean and visually appealing web page.
Improving quality and accessibility
By providing a toolkit, we can leverage an entire community to gradually enhance the quality of components, including their digital accessibility. Accessibility is a major challenge, and we can aim to provide components that help companies and developers better support it.
How?
By providing:
symfony console ux:toolkit:install-component Button
command that will generate the corresponding Twig component in the user's project. If necessary, this command will also install any required dependencies (if a component relies on another one).Components will be unique.
It will be possible for the community to distribute unofficial components: for example, the command could accept
symfony console ux:toolkit:install-component Button --registry github.com/MyRemote/UiKit
The website https://ux.symfony.com/ will include:
Philosophy
Since the web is constantly evolving, it would be difficult to commit to maintaining components that require frequent updates.
An approach similar to shadcn seems more suitable: components are generated locally on demand by the developer, who will handle updates if necessary.
This approach likely offers the greatest flexibility: the developer can customize their component as they see fit, add their own variants, and adapt it to their specific needs.
The list of components could be based on the OpenUI initiative, which already provides a solid selection.
The symfony/ux-toolkit package will not be responsible for installing the CSS required for the components to function. It remains the developer's responsibility to manage their assets.
EDIT 14th April: Many many things were done in the PR and it can be hard to follow all the work here. Please see the following links (time asc) to see precisely what's been done:
Enregistrement.de.l.ecran.2025-04-13.a.20.15.39.mov