refactor!: define colors in tailwind config instead of hardcoding

[hubertmalkowski]

Background

The library aims to be as general-purpose as possible. To support this goal, the current implementation needs improvement. At present, colors are hardcoded in components, which limits the customizability of the library. This approach creates complexity for users who want to adapt the components to match their specific branding, forcing them to manually change colors across many many components.

Solution

Implement a color system by integrating color tokens directly into the Tailwind configuration. The color tokens should be generated and inserted into tailwind.config.js via cli.

Loose thoughts

• With growing number of components - the later the color system is implemented the harder it is to adopt it
• Color tokens named after it's role and not by the color name (eg. "primary" instead of "blue" or "background" instead of "white")

References

• shadcn/ui - has color tokens that are injected by cli to tailwind config
  • salad_ui which is Liveview implementation
• Material Design 3 - example of fairly simple, well defined and widely used color system
• Fluent ui 2, Carbon Design system - examples of big and complex color system

[shahryarjb]

Hello dear @hubertmalkowski ,

Our initial approach was to ensure that users wouldn’t need to modify any files themselves. Additionally, each component would remain isolated and independent, with dependencies limited solely to our other components.

To achieve this, we hardcoded all the colors directly within each component. In this current phase (as you can see from the list of issues), we are re-implementing all the colors because of our redesign. Once this phase is complete, we’ll focus on improving our CLI to allow hardcoded colors to be converted into Tailwind configurations with a single command. However, I believe this will be part of phase 0.0.3, and we have plans for it.

Rest assured, we’ll definitely implement this, as it has also been suggested in the Elixir forum before. It’s worth noting that we’re not solely relying on this solution for color customization. In later phases, our CLI will generate configuration files, enabling developers to easily customize either individual components or the entire library to suit their needs.

Regarding naming conventions: If you’ve noticed, our naming for colors and sizes is consistent. For example, the color named warning represents a shade of brown-orange. This naming convention helps users, especially those less experienced in front-end development, to avoid confusion with various token names for colors.

However, this is not a limitation. Advanced users or those familiar with the system can assign any custom color they prefer, as all properties support customization.

In the next phase, we’ll be adding a section to our documentation titled "Design System." This will include all named colors, token colors, and their definitions. Over time, we’ll expand on these core colors.

Thank you for the references you provided; we’ll definitely review them soon. It may take a little time as we transition to our new infrastructure.

We truly appreciate your suggestion and contributions to improving this project. We’re committed to simplifying everything further and ensuring that any manual operation can be replaced with an automated generator-based solution.

If you have any other suggestions or if you encounter any issues, please feel free to let us know or open/re-open this or a new issue. We’ll be more than happy to assist you.

Thank you!

Ref

• https://elixirforum.com/t/mishka-chelekom-phoenix-and-liveview-ui-kit-and-components/67050/5