TOSIT-IO
Ways of styling JS #52
Replies: 5 comments 13 replies
-
|
I wonder how you can configure theme with Tailwind. I look at https://tailwindui.com/components/preview and I see this HTML code for buttons: <div class="flex flex-1 justify-between sm:hidden">
<a href="#" class="relative inline-flex items-center rounded-md border border-gray-300 bg-white px-4 py-2 text-sm font-medium text-gray-700 hover:bg-gray-50">Previous</a>
<a href="#" class="relative ml-3 inline-flex items-center rounded-md border border-gray-300 bg-white px-4 py-2 text-sm font-medium text-gray-700 hover:bg-gray-50">Next</a>
</div>I see I look at https://mui.com/material-ui/customization/theming/ to get an example how to configure theme and this does not require changing HTML. Am I wrong ? |
Beta Was this translation helpful? Give feedback.
-
|
But, if we want the color to be customizable via theme selection, you want to write everywhere: clsx({
'bg-white': color === 'white',
'bg-red': color === 'red',
})This does not seem very flexible either. How would you implement multiple theme with tailwindcss and react ? |
Beta Was this translation helpful? Give feedback.
-
|
Using |
Beta Was this translation helpful? Give feedback.
-
|
In my case, it was not about theme but for a button componennt. I have a default button component, eg with background green, which I wish to extend/recycle with an important button component, eg red. I don't think we want to support multiple themes. It is more interesting to customize the default theme in both light and dark modes. This is well documented in the theme doc. To support multiple theme, my current approach is to work with typography: module.exports = {
...,
plugins: [
require('@tailwindcss/typography'),
],
theme: {
extend: {
...,
typography: (theme) => ({
invert: {
css: {
a: {
color: theme("colors.sky.200"),
"&:hover": {
color: theme("colors.sky.400"),
},
},
...
},
},
DEFAULT: {
css: {
a: {
color: theme("colors.sky.800"),
"&:hover": {
color: theme("colors.sky.600"),
},
},
...
}}})}}}Here, we have the default prose, as well as invert, but we could have additional custom prefixes. |
Beta Was this translation helpful? Give feedback.
-
The goal of multi-theming is to be able to set different colors depending the environment (dev, prod...). Are you saying having this is a bad idea ? Or maybe you meant (in last group meeting), that we should just change the color of the band on the left and not a global theme ? |
Beta Was this translation helpful? Give feedback.
-
|
More like the last one. I covered theming in a general context and not for the environment customization. Theming is a much larger/complex topic than just providing some color guidance relative to the environment. It affects all the components. Our environment requirement is very localized inside the UI, for example in the header. To address the environment personalization, we may:
Some easy customization inside the header seems enough, don't you agree: export default () => (
<header className="flex">
<Logo />
<p className={clsx(
'grow', {
[`bg-[${settings.admin_bgcolor}]`]: !!settings.admin_bgcolor
}
)}>
{settings.admin_label || 'TDP UI'}
</p>
<Menu />
<header>
)It is possible to support multiple themes in Tailwind, with the help of plugins but I don't think we need to go that route for now. |
Beta Was this translation helpful? Give feedback.
-
|
I have worked intensively with Bootstrap, Semantic UI, vanilla CSS styles, Material UI and Tailwind. Here is my feedback. My favorites are Material UI and Tailwind. Since they cover the two approaches, I focus on them. Whichever the choices, there are always some limit to the framework in use:
Rich toolsets like Material UI comes with a very large set of components and it is always possible to compose new ones. Advanced personalization is more problematic as you often end up in the source code with the need to understand the source in order to personalize its behavior. There are some strong adherence with the framework which weaken the ability to transparently support upcoming versions. I don't think there is a lot to say about Material UI. The approach is quite common, the library is mature, extensive and well designed. There is more confusion with Tailwind. I was personally reluctant to use it for a few years. Until I tried, and it feels smart. Tailwind provide more control because it works at a lower level, HTML/CSS, and comes without any components. However, the approach has proved to be very pleasant, powerful and even productive. The developer is in control and can compose his own set of components, which in the React world is not such a constraint. Tailwind CSS is also extended with a quality eco-system among which Tailwind UI, Heroicons, Headless UI, Flowbite, daisyUI, ... About the className argument mentioned above, it is true. There is a lot of classes to integrate. While a bit scared at first, it actually makes a lot of sense and is also an advantage. With the usage of tools like The example below illustrate how an input component is styled, it is extensible with the <input
className={clsx(
className,
'mt-1 block w-full rounded-md shadow-sm sm:text-sm',
'dark:bg-slate-100/10',
'border-gray-300 focus:border-indigo-500 focus:ring-indigo-500',
'disabled:opacity-30', {
'bg-red-500': color === 'red',
})}
{...attributes}
/>Over the last few months using it, I found one bug, mentioned in the comments above. It finds its origin in the HTML specification. There is not ordering preference in classes. You mean that |
Beta Was this translation helpful? Give feedback.
-
|
I may have introduced the discussion wrong. Comparing Tailwind CSS and MUI is equivalent to React and Vue: we can't. IMO there are 2 questions in this discussion:
|
Beta Was this translation helpful? Give feedback.
-
|
Yes you wrote your message before me. We should compare for example, Material UI and DaisyUI. We can compare others, this is just a example. I'm not against plugin for Tailwind, just using it directly. It is like comparing React and Vue.js which does not meet the same need that's why we ended up comparing Next.js and Vue.js. Tailwind is great to make a design from scratch but we do not want to make a new component library, we are not designer, we want to dev a UI with a component ready lib. |
Beta Was this translation helpful? Give feedback.
-
|
If we go the Tailwind road, the majority of what we need is already in Tailwind UI. |
Beta Was this translation helpful? Give feedback.
-
|
From the list I posted, we can already filter the small libraries and keep only the 5 most popular:
By far the most popular library is MUI. The top 2 packages from the list are from them, due to a recent change in the branding of the company. Material UI is the implementation of Material Design, the Google design system, one of the most robust and accessible. Among the benefits of MUI :
The other libraries in this top 5 also offer a lot of components and are quite robust too. We can mention that:
IMO if we choose to use a component library, we can't be wrong with MUI. |
Beta Was this translation helpful? Give feedback.
-
|
To follow up this discussion and my PR using the Paperbase template (MUI), which was found too complicated, I made 3 POCs to help us decide:
To note :
|
Beta Was this translation helpful? Give feedback.
-
|
React-bootstrap is not an option. I heard good feedbacks relative to Chakra UI. Don't look at statistics. A project like MUI, related to google through the implementation of material design, distorts the numbers. This is a wrong evaluation approach. Also, this quest of widget is not appropriate nor relevant in web design. In the end, we need control. It applies to web design just like it apply to TDP. Are you happy of spending your time working around Ansible limitations, I wouldn't. Widgets are no magic, they create an external abstraction layer which with time became a pain. Don't underestimate the power of Tailwind in that regard. It places styles where there are supposed to be in the most productive manner. Creates a simple layout representative of the complexity. Then, implement 3 POCs, one with Tailwind, one with MUI, one with a challenger (you can eliminate Ant and Bootstrap, that leave you one). Build, look at the generated file sizes, evaluate the quality of the docs, the community, its traction, search the occurrence of words on HN, look at GitHub trends and stats, share your feedbacks, thoroughly auto-critic the limitations of your evaluation, analysis your dependency locked-in, ... Finally move forward. |
Beta Was this translation helpful? Give feedback.
-
We have to choose how we are going to style our React components on
tdp-ui. I see 2 main ways to do so:Component library
The big advantage of component library is that they provide ready-to-use components.
Component libraries are great for some use cases but can be a disadvantage for more specific needs. Each library is very opinionated and will require specific learning from users. Customizing default components can quickly become complex.
The use of component libraries is possible for certain components, it will however be necessary to complete it with other tools (utility classes, css-in-js, css modules, etc.). Many good libraries exist, we can discuss selection criteria if we go with this option:
Grommet(mobile oriented)Utility class
The main advantage of utility classes is their ease of use, by placing the attributes directly in the JSX. The classes are self-explanatory enough for beginners to work with. They make it possible to create protean solutions.
Disadvantages of utility classes is that they can quickly complicate the JSX with lengthy
className. This problem can be solved by enforcing strong architectural rules. They also don't provide ready-to-use component, everything is to be made.The go-to utility class today is Tailwind CSS. It also benefits from a library of premade components from which we can draw inspiration (see Tailwind UI).
We can also benefit from both of those world by using a component library based on Tailwind CSS such as DaisyUI.
Beta Was this translation helpful? Give feedback.
All reactions