[HN Gopher] Building React and Vue Support for Tailwind UI
___________________________________________________________________
Building React and Vue Support for Tailwind UI
Author : shayac2
Score : 106 points
Date : 2021-04-12 20:07 UTC (2 hours ago)
(HTM) web link (blog.tailwindcss.com)
(TXT) w3m dump (blog.tailwindcss.com)
| welder wrote:
| This is so ugly and error prone:
|
| <Button className="bg-gray-100 rounded-full flex" ...
|
| How do you remember the names of all your classes? Should your
| IDE know about these classes? Can you autocomplete class names?
| Where's the import statement for these classes so you know where
| they're defined and what they do. There's a better way:
|
| Use site-wide themes (Objects with keys like
| colors.heading.primary having value '#000') and withStyles[1] and
| React.PureComponent[2]. Having your React component render the
| same result given the same props and state makes things so much
| easier to work with. Also, the compiler knows about your theme so
| your IDE helps auto-complete and makes sure the style you're
| using is actually defined.
|
| [1] https://github.com/airbnb/react-with-styles
|
| [2] https://reactjs.org/docs/react-api.html#reactpurecomponent
| ahuth wrote:
| You don't need to remember all the classes. Instead, you can go
| to https://tailwindcss.com/docs and search for whatever you're
| looking for.
|
| Having IDE autocompletion (or even TypeScript integration)
| would be really nice. I'm sure there's plugins for many IDEs or
| editors that can do that, though.
| welder wrote:
| > Having IDE autocompletion would be really nice. I'm sure
| there's plugins that can do that.
|
| Use withStyles [1] and vscode can autocomplete without
| needing a plugin.
|
| [1] https://github.com/airbnb/react-with-styles
| lights0123 wrote:
| VS Code and IntelliJ plugins provide just that, and the VS
| Code plugin goes further by showing the CSS it will expand to
| and show a color preview next to the class name.
| lxe wrote:
| > Should your IDE know about these classes? > Can you
| autocomplete class names?
|
| Yes! (https://marketplace.visualstudio.com/items?itemName=bradl
| c.v...)
|
| Although I wouldn't mind an array instead so I can use the
| typescript typechecker.
| nailer wrote:
| Love this. And anything else that uses design systems rather
| than styling individual elements.
|
| I currently have a tailwind project that's around twelve months
| old. I'd like to add a dark theme.
|
| Normally - in a CSS, SCSS, PostCSS project - this would consist
| of adding a media query overriding a handful of color
| variables.
|
| Using tailwind (which has 'inbuilt dark mode support') I have a
| few thousand colors spread around the project and I have to
| modify them all. Additionally by having a giant palette of
| named colors, we have, for example, multiple occurrences of our
| active color as `blue-400` and `blue-500` and `blue-600` rather
| than a single `var(--active-color)`.
| welder wrote:
| Yep, design systems (your own component library) are the way
| to go with React. Auto-complete, type checking support,
| functional, etc. You do style the component once, but after
| that it's self-contained, reusable, and functional.
|
| Everyone stopped using unstructured cryptic class="bg-
| gray-100" for good reason. Tailwind is backwards progress.
| city41 wrote:
| Tailwind out of the box is a simple, canned design system.
| The Tailwind authors have already decided your color palette,
| spacings, animations, etc. This is perfectly fine for
| prototypes or anything that isn't that important. But if you
| want to have more ownership over the design system, it's
| better to use Tailwind's config and set it up as it makes
| sense for your site. Colors are the most obvious candidates,
| with Tailwind you can setup your own colors and from there do
| `bg-active` or whatever else makes sense for your site. You
| can define whatever is important for your site, and fall back
| to the inbuilt system for the things that aren't.
| lights0123 wrote:
| So make it. Add it to your tailwind.config.js: https://github
| .com/lights0123/lights0123.github.io/blob/7df7..., then use
| some CSS variables: https://github.com/lights0123/lights0123.
| github.io/blob/7df7...
| leadingthenet wrote:
| > How do you remember the names of all your classes?
|
| You don't.
|
| https://tailwindcss.com/docs/extracting-components
| welder wrote:
| So, the dev never reads/modifies the extracted component that
| still uses hard-to-read hard-to-typecheck classes? Doesn't
| seem like a good solution.
| CapriciousCptl wrote:
| Well this completely deprecates my personal react/tailwindui
| library starting on tax day. I guess that's good!
| crad wrote:
| Same here :)
| franciscop wrote:
| Ah I'm not a huge fan of this: <Menu.Items
| className="absolute mt-1 right-0">
|
| I'd prefer it to be like this: <Menu.Items
| absolute mt-1 right-0>
|
| I did some experimenting (I'm the owner of `react-tailwind`,
| please reach out if you want it!) and it's definitely possible to
| do that; but it does imply components are purely visual, which
| I'm not sure it's the way they want to go. It's also not possible
| to use the colon like `md:...`, but you can do `md="..."`
| instead, which is a good approximation IMHO
| CraftThatBlock wrote:
| A big issue I see with this is that having custom classes (the
| whole extensibility point), at least in TypeScript (without re-
| declaring them).
| franciscop wrote:
| If typescript is an issue don't use it ;)
| natural219 wrote:
| Blurring the line between attributes/react props and CSS
| classes seems abhorrent to me, but just my two cents
| mgerullis wrote:
| I feel the exact same way
| franciscop wrote:
| Sure in this "extreme" I'll agree, it was just an experiment
| after all (I do think both the short-hand classes and
| attributes look wrong). Do you think the same about either of
| these? <Button color="red">Hello</Button>
| <Button red>Hello</Button>
| [deleted]
| brundolf wrote:
| > We crawl this document as an AST, and actually transform it
| into four formats...The key to getting sensible output is really
| just having total control of the input format. It's still hard
| work, but when you can encode the intent of each example into a
| custom input format, converting that to another format turns out
| so much better than trying to write something that can convert
| arbitrary jQuery to React or something.
|
| One tends to think of parsing/compiling as a fairly esoteric
| skillset that a relatively small number of programmers ever
| actually need at their jobs, but it always makes me glad to see
| examples like this where a little DSL was a genuine boon to
| productivity in a real product. Once you know how to do it, you
| start to notice more and more little opportunities where it could
| be useful.
| de6u99er wrote:
| That's a great comment. I might use it in the field.
| brundolf wrote:
| You always have to check yourself and make sure it'll
| genuinely be helpful, because it's so tempting to do :)
|
| But that said, I had a good usecase of my own a couple months
| ago where a little s-expression-based DSL was just the ticket
| to open up some data analysis functionality to internal users
| without having to prematurely build out a super complex, much
| more rigid GUI. DSLs are really just small, hyper-flexible
| user interfaces. Once you frame it that way, there are many
| applications. (The drawback of course is
| discoverability/feedback, which GUIs excel at, so you have to
| balance the two for your usecase)
| Scarbutt wrote:
| _One tends to think of parsing /compiling as a fairly esoteric
| skillset that a relatively small number of programmers_
|
| Parsing is the easy/not so interesting part of a compiler.
| ssijak wrote:
| Or just use something like Chakra UI, which is like Tailwind CSS
| but based on styled system and built with Typescript for React
| from the beginning and has a nice set of basic components.
|
| I even built something like Tailwind UI but for Chakra (link is
| in my bio if you want to check it out)
| deergomoo wrote:
| "If we catered to React developers, we'd be making it harder to
| use for the 70% of people not using React."
|
| Third paragraph of the article
| sync wrote:
| Chakra UI is available for Vue as well: https://vue.chakra-
| ui.com
| 5Qn8mNbc2FNCiVV wrote:
| And then you have JSS, no restrictions to the available design
| tokens, no postcss plugin support and your "css bundle"
| increases since you don't reuse tokens but styles are
| generated.
|
| Those things alone are reason for never using Chakra for
| anything serious as these are actual reasons your
| product/saas/whatever is at a higher risk of failing.
|
| And that's just apart from the fact that the components are not
| allowing easy overriding, theming is a mess (especially if you
| want Typescript support again for your custom variants) and
| it's sometimes buggy with the way DOM events are handled (the
| checkbox being the biggest offender). At some point the
| frontend also randomly crashed for me because of the Popover
| component and it's usage of Popper.js
| theturtletalks wrote:
| Chakra-ui uses Styled-system and Emotion. All your points are
| against those 2 projects, not Chakra directly. Chakra turns
| Tailwind into a Styled-system theme that can be adapted and
| changed.
|
| >> Those things alone are reason for never using Chakra for
| anything serious as these are actual reasons your
| product/saas/whatever is at a higher risk of failing.
|
| Emotion and other CSS-in-JS libraries are used extensively
| and don't raise a risk of the project failing.
|
| >> And that's just apart from the fact that the components
| are not allowing easy overriding
|
| You can use Styled-system to create and extend the existing
| theme. This is actually a knock against using Tailwind CSS
| directly since you will need to write custom CSS to override
| the theme. I've even seen projects where Tailwind is used
| with Emotion to extend the existing theme.
|
| >> At some point the frontend also randomly crashed for me
| because of the Popover component and it's usage of Popper.js
|
| I use Chakra (and the Menu component that uses Popper) on my
| landing page and SaaS and have never had any issues. If your
| code is open, I can help you debug this.
| crad wrote:
| I think you missed the point as an opportunity to pitch your
| project.
| mike1o1 wrote:
| Tailwind and Tailwind UI are really great. Tailwind UI as a
| series of blueprints is exactly what I'm looking for and I love
| how often they're updating and adding new blueprints to their
| list of components.
|
| This part from the blog post kind of confused me a bit, though.
|
| "The promise of Tailwind UI is that it's just a code snippet"
|
| Am I the only one who never looks at the code snippets/tab for
| Tailwind UI, and instead jumps straight into inspect element? As
| blueprints the components are great, but I almost always want to
| make some small tweaks or changes to fit my application. Are
| there other people out there actually copying/pasting the
| snippets as they are?
| aidos wrote:
| I'm not sure I get the difference between looking at the source
| vs inspecting it? In any case, they're not expecting you to
| outright copy them (though you can if you want), they're saying
| that the code snippet has everything you need just by copying
| it.
| mike1o1 wrote:
| I guess for me I have trouble visualizing all of the elements
| and classes just by looking at the code snippets. Looking at
| them in the DOM allows me to see them in context, and I find
| to be easier to use than looking at the underlying code
| snippet.
| PaulWaldman wrote:
| Agreed. One reason I find is that I generally use the
| componentized examples and when put together they lack
| consistency. Maybe if you lean toward the full page examples it
| could be used "as is".
| davidwparker wrote:
| I almost always copy + paste them, but then start tweaking them
| in my app. It's easier to just start fresh then change after in
| my app than trying to do things in the console.
___________________________________________________________________
(page generated 2021-04-12 23:00 UTC)