Lots of busywork adopting components in real app

[RXminuS]

This isn't a feedback for a specific component but rather a request on how to structure components, especially the larger ones. Just to have something concrete to discuss I'll take Brand sidebar with light header as an example.

Whenever I'm copying these components over to React I find myself spending a lot of time locating the "repeat-points" of sub-components. For instance the navbar links on the side (x2, one for the mobile and large-screen) I need to figure out that the <a />'s are the components I'm looking for and then have to compare the classes between the active and inactive state.

All just so that I can split out the html into smaller components and split out the state based classes into a separate list from the base classes. Reading the HTML is also often hindered by the long streaks of SVG icon code.

I get that it's nice to be able to copy the final HTML and instantly play around with things, but I think it would be great if there was an alternative view where you can see the final component split out into subcomponents. That way the HTML would be a bit more readable and you could easily copy those elements of the components you care about.

I get that we're not trying to start a Vue/React/Svelte war. So maybe even something as simple as handlebars/mustache templates would be enough.

But I've found that the amount of busywork is quite prohibitive in adopting components and I find a lot of errors creeping in.

[mikebronner]

What I have done is take the examples and created components out of them in a private repo that I can include in any of my projects. The drawback is that they don't get updated as these examples or as tailwind gets updates, but it makes the application and maintenance much easier.

[RXminuS]

Yeah that's what I've done as well, but that's exactly the problem...everyone who wants to adopt TailwinUI in a real-world project is going to do exactly the same work of splitting out in components. Probably easier if TailwindUI simply provides that out of the box.

[ghost]

It's better to have your own selected components, in that way you are developing your own lightweight design system if you are focusing on a large applications where multiple developers are contributing to the frontend. That will make there life easy.

In my case I am focusing on the micro frontends or molecule level of segmentation of the components. Where I am making the components from scratch but with the abstraction which leads to decouple the small components (which are fixed or updates with every release).

Probably easier if TailwindUI simply provides that out of the box.

When you talk about supporting the frameworks out of box like vue, react angular there's a lot of time involved in these task as well as lots of work with every new release or fix. Which I guess you can understand from your own experience. Tailwind UI is more focused on the better UI guidelines and methods which leads to the better user experience and design system.

[RXminuS]

I think that’s beside the point @outlawvik. Yes have your own component libraries. No I’m not saying to support a framework out of the box. I’m saying the blob of HTML isn’t easily to adopt into any framework or component structure of your own.

The translation step from the blob that tailwind presents to easily identifying repeated class structures is a PITA. Because the HTML is filled with data and arbitrarily copied rather than being in a for loop so you can easily spot “oh this is the table row and to make it active they’ve added these 3 classes on top of it”.

Now I need to manually go through trying to figure out where a row starts and ends and then compare classes between them to figure out if there’s any differences. And sometimes you miss things like “on the last row they remove the negative margin for smaller breakpoints”.

If instead the HTML was split up into a table.html row.html and last-row.html that would be much easier to understand. Or use handlebars, or vue, or makeup your own system...it’s not about supporting a framework it’s about presenting the structure in a more convenient way

[hedgerh]

One low effort solution would be if they added comments to the markup to make it easier to parse. Then it'd actually be pretty trivial to present the sub-components individually some way in the code section of the UI.

[ivosabev]

I am in the same boat, it is extremely time consuming to extract components out of the markup on the website which is very disappointing. Components should be split into building block components and base classes should be separated from variation classes. There is also a lot of code shared across components which also should be extracted.

[jits]

It sounds like it may just be worth investing time into building a VueJS component suite version of TailwindUI?

I could imagine a high quality set of reusable and repurposable VueJS components coming out of the existing suite. Such a component suite would complement (and not replace) the existing HTML "components"; it could be both a full library that's imported in the usual way (like Vuetify, Quasar, etc.), or allow folks to copy and paste just the components they need and then customise to their heart's content.

Note: I'm not yet a customer, and am considering whether to purchase this (expensive) toolkit. I realise that the suggestion above requires a lot of time and energy from Adam and Steve, but it would address (for me and others) the single biggest complaint – that TailwindUI isn't really an easily reusable set of "fully responsive HTML components" (quoted from https://tailwindui.com/), especially when compared with existing component suites (unfortunately all of which lack the sweet TailwindCSS goodness).

[jacobq]

... I’m saying the blob of HTML isn’t easily to adopt into any framework or component structure of your own.

This hasn't been my experience. Although I've only been using TailwindUI for about 2 weeks, and I hadn't even used Tailwind CSS before that, so far I've found that it's at least as easy to work with as what I've typically gotten from designers. In the "learn framework X from scratch" workshops that I've been part of, the opening exercise has typically been to go through the process of templatizing/componentizing (or whatever you would call transforming a big chunk of mark-up into smaller, re-usable pieces), and doing this with TailwindUI feels natural and, for the most part, intuitive.

...the single biggest complaint – that TailwindUI isn't really an easily reusable set of "fully responsive HTML components" (quoted from https://tailwindui.com/), especially when compared with existing component suites (unfortunately all of which lack the sweet TailwindCSS goodness).

I guess the truth of that statement depends on one's concept of "easily reusable". So far my experience is that it does live up to this claim. However, is it as easy as bootstrap? No, but it's a lot more flexible and simpler to customize. Is it as easy as a UI component library that's already available for your framework? Definitely not, but that's largely the price of keeping it neutral / framework-agnostic, which is an approach that I really appreciate.

That said, I think there is room for improvement in making it easier to assimilate the TailwindUI HTML into "real apps". In addition to previous suggestions, here are a couple other things that might help:

1. Add HTML comments just before (or classes on) major areas in large components (e.g. the "Brand sidebar with light header" mentioned) (EDIT: looks like this is the intent and has gotten better than when I had last looked 👍 )
2. Add a control (checkbox?) to the preview/code tool that removes the alpineJS stuff (it's nice to be able to click the preview, but presumably most users will not actually be using this library in their application) EDIT: Sounds like this is being addressed too (#7, #106, etc.) -- guess I should've joined Discord sooner so as to not be behind on everything :)

[J05HI]

Vue Components! +1

[simonswiss]

Hi folks! 👋

Lots of valid points in this thread. Happy to report that we're definitely going to add React and Vue versions of the components.

@RobinMalfait, who joined the team today 🎉 will be developing headless UI Tailwind libraries for React and Vue, and these will power the ability to provide React / Vue versions of our Tailwind UI components. 👍

It's worth mentioning that Tailwind UI is more of a "starting point to scaffold great looking UIs with HTML" rather than a design system or component library per se. But I hear your pain points.

We're also working on adding better comments and context (like the dynamic classes for transitions, show/hide elements etc).

[tabacitu]

Thanks for the update @simonswiss - glad to hear you guys plan to address this.

Are there plans for something that would work without Vue and without React? Something like Blade components maybe, that would also be useful with Alpine (inside the TALL stack)?