Principles

Relations

Components

Box

Flex

Input

Text

ui.components.button

Select

Toggle/Switch

Toast

Stack

Tabs

Groups

Primitive

Pattern

Subgroups

ui.layout

Navigation

Data Entry

Data Display

Feedback

References

braid design system

react-native-design-system

react-ui

building blocks

Avatar Button Heading Image Input Link Select Spinner Switch Text Textarea

layout

Stack Grid

molecules

Breadcrumb Card Form Menu Paragraph

theme-ui

https://theme-ui.com/components

Box Flex Grid Button Link Text Heading Image Card Label Input Select Textarea Radio Checkbox Slider Field Progress Donut Spinner Avatar Badge Close Alert Divider Embed AspectRatio AspectImage Container NavLink Message IconButton MenuButton

Others

Categorization

Since the-map-is-not-the-territory to will these seperations into existence will be meat with resistance. It might be better than to view components on being in a spectrum. For example between being most reusable and least reusable.

| least reusable ------------- most reusable|

or

| proximal ------------- distal|

Keeping complexity below a certain treshold is also extremly important.

Identifying and creating "good components" is a trickier process than identifying patterns of "bad components."

Little component guide

All components live under the folder components. This helps to void the notion of "component library components" vs "everything else" which allows us to have all components at our fingertips for an efficient overview and liberates to easily compose and adapt.

Some directories hold multiple components. This allows us to keep related components together and don't unnecessary clutter /src/components. Nested components will never be used outside.

Other than that this approach does not have explicit rules for component categorization. I think this is good because its actually hard to define struct rules and not bump into resistance (the territory is not the map).

Rather I want to provide a vantage point that might be a better fit for the task. I want to point to discoverability and self-emerges and self organization

This is an experiment so bear with me.

Components are part of an organic process

First I want to unearth the frame of looking at the ui as having an deep underlying continuity. Through that we can perceive component boundaries like being cell membranes, instead of implying them to be an isolated thing. To further illustrate I add the metaphore of habitat-habitas. A component dwells in (habitas) another component and likewise a component might be a dwelling place (habitat) for other components. It allows us to see components co-evolving with there surroundings and reciprocally affect each other. This way a boundary goes both ways and the relationship comes to the foreground (I think this is one of the main ideas that this relationship directly dictates how compoments will be implemented).

So as the ui grows and evolves, boundaries emerge and change and some boundaries might not feel right anymore. From here on we can think of components having a dispositional state which are micro configurations (more on this below) that can reach certain tresholds. Once above a certain treshold a component might move into a disregulated state with the danger of becoming disassotiated from its surroundings. It than feels uncomfortable to work with and more a burden then being helpful. (Since we mentioned the boundary relationship before it is important to look also to the surrounding compoments that migh also contribute to the disposition of the component.) We than could say a component (or a set of components) became "bad" and needs some refactoring.

An probably obvious but I think still important sidenote is that since components are not inherently alive, they "become" alive through our participation. Its our participation and by that getting intimate with them, is what allows this organic process to happen.

So how can we conceive or identify dispositional states of components?

Responsibilities

Here we look at general tendencies or inclinations that a component might be working out. Lets define the following:

Reusability

Here we look at the degree of reusability.

                      ┌─── <Modal>                                                        <AnalyticsDashboard>
                      │                                                                       ──┐
                      │                                                                         │
                      │                       <LoginForm>                                       │
<Button> ───────────┐ │                            ──┐                                          │
                    │ │                              │                                          │
                    │ │                              │                                          │
                    │ │                              │                                          │
                    │ │                              │                                          │
                   ┌┼─┼──────────────────────────────┼──────────────────────────────────────────┼─────┐
                   └─┼─────────┼────────────────────────┼──────────────────────────────────────────┼──┘
                     │         │                        │                                          │
                     │         │                        │                                          │
                     │         └────────┐               │                                          │
                     │                  │               │                                          └─ <App>
 <Slider> ───────────┘                  │               └─── <UserProfileCard>
                                        │

                               <SearchIconButton>

– https://asciiflow.com/#/share/eJyrVspLzE1VssorzcnRUcpJrEwtUrJSqo5RqohRsrI0sdSJUaoEsozMjYCsktSKEiAnRkkBK3g0ZQ8cKdj45qck5thhV0kY2DjmJeZUlmQmF7skFmck5ScWpdjFxOThtJhcezBNgiA62AU2iwx7bHzy0zPz3PKLcokNXYg9Nk6lJSX5eXYo8YQLEfInQiHRALdvibCPxIAftYuGdhGTfoYrGg0R4kIENa09wp3u8EiRkCQH2jo8iA4OwCNIqnUg9TaOBQXgytYmOCczJbWIyBqDONcg1NuEFqcWBRTlp2XmpDrjrd%2BxGg1UTViDTXBqYlFyhmdyfh609otRqlWqBQBXvCIN)

On the right side of the spectrum with find components with a lower level of reusability, which we can map to components inclined to have stateful responsibilities. The are likely appearing only once in the component tree and are very much purpose-built.

On the left side of the spectrum we find the most reusable components. They will very likely be presentational components. When working with a component library then the components in it will certainly be reuseable and therefore located there.

Other components will be more located in the middle and can be mapped for having structural tendencies. They are specific enough to accept some state or API data and pass it on. They also might be used in several places since they are not responsible for retrieving state or data themselves.

And some components might also have "mixed" responsibilities. This can be the case when components are still working out their place or just because of their special nature do this.

When looking at the compoment tree we will find that less reusable compoments will be located at the top while more resuable components at the bottom. This happens naturally due to the affordances a compoment provides.

It is also highly unlikely that a very reusable compoment is the habitat of a not very reusable compoment.

Now that we have defined these we can look tresholds we can point to that might mean that a component slides into a "bad" state.

These are not easy to figure out and as mentioned above require getting intimate with the components. When we do that before we reach to solutions such as Prop drilling and React Context our compoments will stay in a healthy place.

For the rest of this guide I have planned to provide more specific pointers. Like how best to style, working with theme scales, use external component libraries, best practices, etc. Maybe I do that on the go and point to them in our async meetings.

But I hope this vantage point already provides a good sense of what it means to build good compoments.

Takeaways

Scratchpad

Sources

tools

Libraries

See

Links