Skip to content
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

Suggestion: TailwindCSS integration #69

Closed
excitedbox opened this issue Mar 14, 2021 · 6 comments
Closed

Suggestion: TailwindCSS integration #69

excitedbox opened this issue Mar 14, 2021 · 6 comments

Comments

@excitedbox
Copy link

Since there seems to be a push for stimulus which is a very simplified JS event system I would suggest matching it with Tailwind which has a very similar philosophy. They also have some of the best documentation out of any project out there.

Tailwind CSS

Tailwind provides a huge number of utility configurations out of the box and on building your project all unused styles are removed so that you have the absolute smallest style sheets possible. This has helped me tremendously in speeding up page loads. You can also easily hook your own style sheets between the TailwindCSS and your site and because it uses postCSS (Already in symfony) you have full support of polyfills and all future css specs.

I already have postCSS and TailwindCSS integrated in my project and the setup was really simple

@Kocal
Copy link
Collaborator

Kocal commented Mar 14, 2021

I don't understand what Symfony UX could provide for setuping Tailwind in a Symfony project, and if Symfony UX should really touch other config files (tailwind.config.js, postcss.config.js, ...).

That's not really hard, and since Tailwind does not provide any JavaScript (except resolveConfig), I think it's out-of-scope of Symfony UX.

You just have to configure Encore like this, to let Tailwind knows about NODE_ENV value:

// Manually configure the runtime environment if not already configured yet by the "encore" command.
// It's useful when you use tools that rely on webpack.config.js file.
if (!Encore.isRuntimeEnvironmentConfigured()) {
  Encore.configureRuntimeEnvironment(process.env.NODE_ENV || 'dev');
}

+// Manually define `process.env.NODE_ENV`, since Encore does not do it already
+process.env.NODE_ENV = process.env.NODE_ENV || (Encore.isProduction() ? 'production' : 'development');

Configure Tailwind like this, it will automatically purge unused CSS if NODE_ENV === 'production':

// tailwind.config.js
module.exports = {
  purge: [
    './templates/**/*.html.twig',
    './assets/**/*.{vue,jsx}',
  ],
}

And configure PostCSS like this to let PostCSS handle Tailwind:

module.exports = {
  plugins: {
    tailwindcss: {},
    autoprefixer: {},
  }
}

@richardhj
Copy link
Contributor

Tailwind CSS can indeed be integrated with any project, but I fail how this relates to Symfony UX? Can you demonstrate how Stimulus can help?

@excitedbox
Copy link
Author

excitedbox commented Mar 14, 2021

UX components need styling/layout and using Tailwind to set the layout would make editing/configuring those UX components simple. If you want to set widths or grid alignments and transformations, Tailwind makes those very simple and intuitive.

I think maybe I misunderstood what it is you are trying to do. I thought you are trying to provide a set of components for building data tables and dashboard components like graphs, menus etc. (Symfony is missing a UI component library as well)

Stimulus is a very barebones JS library for scripting Event responses and data integration (pagination, navigation, ui components). It is not meant for building web apps like React is. It is more like an event handler. I believe Symfony already has a stimulus bridge and it was suggested in the WYSIWYG editor thread.

Alpine JS is very similar to Stimulus and is being offered as a Tailwind integration. So if you look at some of the component examples you can see how easy it can be to style things with tailwind. AlpineJS is NOT READY yet (will it ever?) though. I wasted several weeks trying to make it work but sadly it is missing very important features and has terrible documentation. It is also based on hacks and not conforming to web specs.

Here is a UI component demo using stimulus and tailwind
Github

Even Better example of the 2 working together

If you wanted to build a bar graph you could use tailwind to make a multi row/column grid and use stimulus to change the styles adjusting the lengths of the bar simply by changing the width or height values. Same for pie charts by changing rotations or transform values. If there is interest I can knockup a demo later.

image

Tailwind UI/UX

@tgalopin
Copy link
Contributor

tgalopin commented Mar 14, 2021

Symfony UX isn't named Symfony UI for a key reason: we want to provide reusable behaviors, not reusable user interfaces. Symfony won't become a UI tool, neither on the backend nor on the frontend. There are great tools, like Tailwind, that do it much better. It's perfectly feasible, and even easy, to add Tailwind on a Symfony UX structure.

Symfony UX provides foundations like Symfony does in PHP by providing a structure and helpers. I don't think we should be tied to any CSS framework, it makes little sense IMO. There isn't much CSS in UX packages and I intend to keep it this way.

Unless I'm missing something important, I don't think I'd be in favor of linking UX to any specific CSS framework.

For specific UX packages on the other end, we could provide a way to configure them to use a Tailwind notation, like Forms. That could be useful for Dropzone for instance. I'd be open to review such a PR. We wild need to support Bootstrap too though: that would give us more flexibility.

@excitedbox
Copy link
Author

You are right I misunderstood the purpose of this component. I saw the charting examples etc. and thought you wanted to make actual components but after reading more of the scope, I see it is more about the JS parts of the interaction.

Although I believe the JS ecosystem is so massive (a mess really) there is a solution for pretty much everything on that end as well. Projects like backbonejs for example does event handlers and D3 can make data components of all kinds.

The reason I would argue for using a single UI system is because there is a lot of work in making the php backend work together with the JS frontend on the client side and then building out components that work with those. It provides a clear way forward just as using doctrine gives a clear way of how to work with data or twig does for templates.

Right now the API platform admin uses React for the admin which needs to be integrated into EasyAdmin or Symfony. Having 1 officially supported system means that there is unity and compatibility across the entire ecosystem just as twig is used by everything. It also makes templating with twig easier when there is a component library for creating data tables and such.

Anyway obviously this is the wrong place to discuss all of this, so I guess you can close the thread.

@tgalopin
Copy link
Contributor

tgalopin commented Mar 15, 2021

Right now the API platform admin uses React for the admin which needs to be integrated into EasyAdmin or Symfony

Symfony UX does help a lot on this level already: by using controllers and entrypoints, API Platform will be able to provide a plug and play react-admin context. It's not the case yet but we already discussed it with the persons involved. UX helps here by providing the ability to wire JS packages from vendors into the project seamlessly, allowing Flex recipes to rely on JS declared in vendors.

Also, note that Stimulus is a tiny foundational layer, the equivalent of Twig for JS: it provides the basics for JS behaviors to be reusable across projects and vendors, and it does only this. Inside a Stimulus controller, you can then use React, Vue, Backbone, ..., or vanilla JS as you prefer. There is no limitation there, just as there isn't any to use the CSS framework you like.

Anyway obviously this is the wrong place to discuss all of this, so I guess you can close the thread.

I'm closing this ticket but if you are interested in looking into the concept of adding reusable UI components to Symfony UX, I'd recommend you to check the internals of UX. It can be a bit tricky (I can help, come on symfony.com/slack and ping me on the ux channel) but it will give you a better overview of the initiative.

I do think there are interesting ideas to have regarding components, but I think these components should be kept small (Dropzone, Color picker, Date selector, ...). Perhaps they would benefit from having a CSS framework integration, I'd be happy to think about it on Slack :) .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants