-
-
Notifications
You must be signed in to change notification settings - Fork 45
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
Provide a default component library #206
Comments
This is an excellent idea, esp since they are CSS based component libraries. From looking at both it seems daisyUI offers more abstraction then flowbite. |
Perhaps it would be good to make something more tangible as a starter app then? Perhaps something such as a "todo" app or something else simple that can show off how components work? |
That might be worthwhile. Right now the starter app is a combination of a new-app template and a demo/example app. Maybe it should be split up so the starter app gives you more of a blank template and there's a separate repo with a demo TODO app or something. |
@jacobobryant I'm trying out daisy ui. What would be your approach to install it? |
@nickdex, you can follow the standard daisyUI install instructions; they'll work just fine whether you're using the tailwind binary or if you've installed tailwind via npm. i.e. run |
I will say I'm kinda surprised by daisyUI's landing page:
I'm shocked the authors could have spent so much time with Tailwind and still misunderstand it this badly. The whole point of Tailwind is that you do style reuse via react components or the equivalent (plain functions in Biff's case). Unless the authors get that but they're still using that angle as a marketing ploy? In any case, for both DaisyUI and Flowbite, I'll be interested to see how smooth it is to modify the built-in components' styles. It's easy to package up a bunch of defaults; it's harder to do that while still giving full control to the user. frameworks vs libraries basically... of course even if they're not easily modifiable, there's still a class of projects where that's OK. I'd just want to make sure anything that's packaged with Biff has a good modifiability story. |
@jacobobryant I went with CDN to give it a try. Daisy supports full override from tailwind classes (need to be added before tailwind script line, in case of CDN) and you would want to remove tailwind base (and likely components) styles . I wanted uniform look so that my effort is spent more on logic than style at current stage, daisy is doing good job for now. |
For my React projects I've been using Flowbite as I find it more 'Tailwind-ish'. But the Daisyui aproach somewhat shortens the class list, and i've found that on Hiccup I prefer the shorter class list (in part because the dots make the list somewhat harder to read than whitespaces and in part due to lack of support of the excellent VSCode TailwindCSS plugins with Intellisense and docs for the class names). If you want to add support for Daisyui and don't want to tinker with NPM, you can use this: Regards. |
@Peluko interesting, I'll take a look at that sometime. FYI for long class lists I like to put them one-per-line (and sorted alphabetically): [:div {:class '[max-w-screen-sm
mx-auto
p-3
w-full]}
...] |
And I've found a solution to make the TailwindCSS VSCode plugins to work with Hiccup, here Support for ClojureScript?. |
Probably have the starter app use some pre-existing Tailwind component library like Flowbite or daisyUI. Need to see if those work well with server-side rendering or if they're mainly built for use with React/other SPA frameworks.
The text was updated successfully, but these errors were encountered: