search

formaat-design / reshaped

Community repository for storing examples, reporting issues and tracking roadmap
https://reshaped.so
120 stars 4 forks source link

[Brainstorming] Component structure #115

Closed mmailaender closed 1 year ago

mmailaender commented 1 year ago

Some brainstorming - feel free to include yourself 😉

I was rechecking again some UI Frameworks. Mantine is proclaiming a lot of components in their Navigation: Screenshot_20230115-110654.png And I was noticing in this Youtube Video, that it probably helps people to orientate what a Framework is capable and what not https://www.youtube.com/watch?v=g6VJMPpZlgI&t=561 Pin pointing e.g. AppShell.

On the counter side I experienced it by myself as completly overwhelming, in the beginning, to have so many components in the navigation bar. Also a differentiation between Utility and Components without explanation, was confusing me. (Reshaped)

That brought me to the point to analyze the components a bit more.

So I'm noticing a pattern.

It seems we can differentiate the components in 4 categories:

Base components

These are the base pillars. If you understood these components, you can build all the other component out of it.

Probably we can also count hooks to this section 🤔

Opiniated Components

These components are in some sort of way variants of the base components with some opiniated additional logic. Using these components can save you some time over the base components.

Building Blocks

Multiple components composed for use cases that often occurs once in an app

Themes

A complete blueprint of an App

The frameworks are following different implementation patterns:

'Mantine' is providing a complete own component. So if you're using a Building Block it seems you have limited/hard customization. On the other side the usage of the component includes quite less code.

'Tailwind UI' is wrapping 'Tailwind CSS' with 'Headless UI'. So all 'Building Blocks' and 'Themes' are composed out of the 'Base Components'. That leads to more Code, but you keep the flexibility. And it has some implicit teaching of the 'Base Components'. So if you need to develop something in the future, where no example is provided, you probably have higher changes to succeed with TailwindUI because you learned the 'base components' implicitly. The "more" code problem can be also by passed by wrapping it into a component by myself. (Btw. I experienced Tailwind also a bit confusing in the beginning. There is Tailwind CSS, HeadlessUI and TailwindUI and the components and documentations are scattered between these pages.)

So I'm thinking, if it would make sense to structure the documentation based on

All opiniated components, building blocks and themes would be composed from the base components for implicit teaching. In the Getting started could be explained what level makes sense as starting point for which User group.

E.g.

So the user has every time a red line connection and the navigation bar and documentation in general is not getting mixed with different levels of components that makes the adoption of the UI library harder.

mmailaender commented 1 year ago

Such Split could also have the benefit to have some good paid/free Tier cut to get more traction.

The base components could be free, and the other components paid. Similar to Tailwind CSS and Tailwind UI

blvdmitry commented 1 year ago

Agree, was thinking literally about the same before regarding the base part

mmailaender commented 1 year ago

Some extended thoughts:

ATM Chakra, Mantine, Reshaped etc. are providing their own set of components.

That means Developer need to research time consuming existing UI components e.g. Base components, rich text editor, calendar, Diagrams etc. before they can use them.

Having long-term an one-stop shop would provide an easy component discovery.

Nevertheless developing all these components again, would consume a lot of time and would reinventing the wheel instead of adding any benefit.

So I thought, why not integrating already existing best in class components and wrapping them with the reshaped Design System for easy Integration?

E.g. Rich text editor: You could provide a component, that is wrapping e.g. Plate and is applying the Reshaped Design system automatically.

Benefits:

What do you think?

blvdmitry commented 1 year ago

So we've decided there will be some additions for the library structure with more complex examples covered as guidelines to make sure we don't ship opinionated components bundled with the library. We're also planning to change the way we distribute components sometimes after the v2 stable release is done which will address the separation of the components in terms of what we've discussed before (that we could ship base components as a separate package). I'll be tracking it in our Notion