Remove daisy UI

[rin-st]

[In progress]

Mostly completed

• modal component
• dropdown component
• tooltip component
• table, changed classNames to tailwind
• tabs, changed to regular buttons like debug contracts tabs
• loading component
• input, changed to tailwind
• textarea, changed to tailwind
• toggle component
• button component

Todo

• collapse
• avatar
• badge
• link
• menu
• navbar
• skeleton
• theme
• ...

Fixes #1079

[rin-st]

In general, I created components like Button, Modal, Tooltip etc, and instead of daysy-ui classnames like btn btn-primary I use that components

Example

Some simple or one-time daisy-ui classNames like input just replaced with tailwind classNames

Pros:

• no DaisyUi dependency
• our buttons, modals etc are always the same since we use the same components. Well, we still have className prop in that components but it helps to clearly understand what is inside component and what classes were added for specific case.
• we can change components from one place
• much more customization possibilities with js

Cons

• unusual for se-2 users
• more components

What do you think about that approach at all? Is it fit for us? Maybe some other ideas?

You can see done/todos at the first message + I know about some small colors and styles which I’ll try to make better.

[rin-st]

Forgot to say, I changed Inputs view so they looks similar

Before:

After

If you think I need to return prev styles please lmk

All other things should be the same as before

[carletex]

Thanks for exploring this, Rinat! Great job!!

Took a quick high-level look as you suggested. I think it's good to discuss and have a consensus before moving forward

What do you think about that approach at all? Is it fit for us? Maybe some other ideas?

I like the approach, and I think this could make a lot of sense. I agree with the PROS / CONS.

---

Something that we could discuss: where should we draw the line between just tailwind classes & components.

=> It's clear to me that modals (and similar) should be a Component (because they have some custom styling + "JS" functionality).

=> On the other side, it's not that clear for things like buttons, since it's only styling. I guess the alternative would be to create some extra utility classes (using @apply?) like btn-primary, btn-sm, etc. This applies to things like badges, links, (tooltips?), etc.

I wonder if there would be a nice dynamic way to create variations with themes/colors/sizes for all of these utility classes.

Pushing back on myself: if we are expecting people to use either raw TW or Shadcn, maybe the approach of having button, etc as components is not a bad idea.

But yes, for me, not relying on custom components for simpler things seems better. I feel that it makes SE-2 less opinionated and closer to HTML / CSS. People can always create their own components (custom, shadcn, etc)

Anyway, just opening the discussion! Let me know what you all think!

Thanks again!!!

[rin-st]

=> On the other side, it's not that clear for things like buttons, since it's only styling. I guess the alternative would be to create some extra utility classes (using @apply?) like btn-primary, btn-sm, etc. This applies to things like badges, links, (tooltips?), etc.

I'll try to add more pros/cons.

How I see it with utility classes:
Pros:

• less components and js as already mentioned

• But yes, for me, not relying on custom components for simpler things seems better. I feel that it makes SE-2 less opinionated and closer to HTML / CSS.

Cons:

• it allows to make mistakes like writing className="btn-sm btn-lg" for the same button
• we need to add information to the docs why we use utility for buttons and components for modals and if I would be newcomer it would be weird to me

People can always create their own components (custom, shadcn, etc)

• (less important) if someone wants to keep part of our button when creating custom component, he will need to migrate that part to component from utility class
• (less important) if we keep daisyui-like classNames (btn, btn-sm etc), our users could think that daisy still works and won't understand, why btn classes work but modal is not since they will expect daisyui to work.

With components:
Pros:

• it's much more familiar to react devs and hence it's much easier to configure and update for specific project needs
• typechecks: you couldn't set two sizes at the same time (as btn-sm btn-lg)
• as Carlos mentioned, it's easier to update component to use Shadcn/whatever

Cons:

• it could be specific style cases which is not fit any props and/or conflict with them. Sometimes it could be easier to fix that cases with utility classes. For example in the PR you could see that inside Dropdown I use regular button, not Button component. But it could be fixed (or maybe not))

Non of these are critical but I'm still voting for components

---

I wonder if there would be a nice dynamic way to create variations with themes/colors/sizes for all of these utility classes.

If I undersood you right, It could be implemented the same way as in the daisy, relying on CSS variables. Example:

.btn {
  height: var(--size);
}

.btn-lg {
  --size: calc(var(--size-field, 0.25rem) * 12);
}

.btn-xl {
  --size: calc(var(--size-field, 0.25rem) * 14);
}

[technophile-04]

But yes, for me, not relying on custom components for simpler things seems better. I feel that it makes SE-2 less opinionated and closer to HTML / CSS.

100% agree on this!

People can always create their own components (custom, shadcn, etc)

Was thinking about this a lot and not sure how beneficial it would be leaving this in peoples hands. Because If they start making their own custom components or plan to use shadcn or daisyUI this thing won't go with the whole app (maybe borders, colors or something) will be a bit different. Devs again would need to go through our codebase or docs to understand how to integrate similar styling in their custom stuff.

The above could be solved if we have nice themeing doc explaining how to use same border radius etc to match it with whole app.

We could have very minimal components like modal, dropdown etc but again we would require docs for them.

it could be specific style cases which is not fit any props and/or conflict with them. Sometimes it could be easier to fix that cases with utility classes. For example in the PR you could see that inside Dropdown I use regular button, not Button component. But it could be fixed (or maybe not))

This is also problem but we could solve it with cva, tw merge + clsx but docs still be required.

Like shadCN already does this for us (themeing, easy merge utils, sensible variants but also since code is in codebase direct tweaking is allowed) (similar to we building our own components and telling devs to use it.

The CONs:

We didn't like this. We could have regular/valid HTML + classes.

Researching more shadCN is not actually tied to above and we could replace radix UI with our own HTML CSS / daisyUI, checkout this tweet

So actually we could go with shadCN way of doing things (following its theme handling etc) and replace radix with our own HTML CSS things.

The benefits of going with shadCN way of doing thing is:

1. We don't need think of how to name, structure the API's
2. Themeing is handled
3. we could reference to their docs, people / AI are already familiar how things are structured in shadCN way to doing things.
4. Since we are compliant with shadCN we could also share this components as shadCN registry so that people could have this components in their non-se-2 codebase

I feel that it makes SE-2 less opinionated and closer to HTML / CSS

If we are fine with dealing with this downside then we can even use shadCN with radix UI so that we don't need to build or own modal (custom js), dropdown components be fully inline with design system and accessbility.

The downside with this approach is if we shadCN updates any component then we need to carefully merge things. But I feel since we will be using very less components from shadCN it's fine? Anywhich way if we plan to create our own components then we have to maintain them?

thinking of Scaffold-UI too I think shadCN cli and registry is actually nice, it will allows to add component nd hooks to any react tailwind project also give minimal API to override / customize that's project CSS vars etc so that our components looks good out of the box incase we need to use CSS vars etc checkout registry:theme

---

Sorry for late realization but I am just paranoid if we don't use daisyUI or do shadCN way of doing things or any other library it would be hard to make consistent apps with SE-2 unless you are in weeds of SE-2 / how things are structured internally or we need to educate people nicely. Benefits of using this seems libraries / shadcn consistent API's and some already familiarity of people.

Maybe I am too concerned or bit biased and missing more disadvantages of shadCN

---

Other research links:

1. Interating daisyUI into ShadCN : how to use daisyui with shadcnui saadeghi/daisyui#2480
2. ShadCN vs DaisyUI:
   https://daisyui.com/compare/daisyui-vs-shadcn/?lang=en
3. Supabse shadcn components: https://supabase.com/blog/supabase-ui-library
4. Small vid about shadCN registry: 1, 2 and 3

[carletex]

This is great stuff!!!

I'll sleep on it a bit and will reply with some thoughts too.

[rin-st]

So actually we could go with shadCN way of doing things (following its theme handling etc) and replace radix with our own HTML CSS things.

Could you add more details, please? As I understand you're proposing to do something like this, but not sure

• use default shadcn config and vars naming
• create our own components based on that vars/classnames etc so it will be similar to and compatible with other shadcn and shadcn registry components. Other than that vars there will be no dependencies like radix UI, and we can build components using whatever we want

something like https://www.jollyui.dev/docs ?

[technophile-04]

So here are the path which we have:

Doing things our custom way:

Creating our own custom css variables nd components where required.

Pros:

1. Zero dependency
2. Ability for us to have valid html/css components

Cons:

1. We need to handle themeing (other people building on top will have inconsistent style)
2. Allowing people to intuitively customize stuff (merging classes etc)
3. educating people how everything works

Doing things shadcn way:

ShadCN mainly provides themeing, utilites to merge class names and have variants, cli.

By default on shadCN website example components are build using RadixUI but we can swap that or not use any library at all.

We now have two paths in shadCN:

1. Use components mentioned on ShadCN directly (i.e using RadixUI)
2. Don't use shadCN website examples instead build our own components.

1	2
PROS: - We don't need to think of JS logic, and having docs on how to use modal instead we point to default shadCN website - Not just our components but people can bring other useful components from shadCN website and will go nicely with whole SE-2 - Devs familiarity	PROS: - We have valid html / css components. - Since we will be building components we can easily fix things not thinking of bug in other library.

(lol sorry for extra rows / cols my weird Obsidian note app had it)

Also, another thing which Carlos mentioned was if we go with 1. We have to make sure that if people use just instead we could have some default styles to such directly using looks similar to .

So the next step would be we create a new PR with basic theme and stuff setup and two components from it button and Modal and let's see how it feels to us 🙌