Box component as escape hatchclassName and styleref to root for ability to set ref to the underlying DOM nodegrow for use with flex layout sets flex-grow to 1high adds 100% heightwide adds 100% widthmax adds 100% height and widthfullscreen adds 100vh height and 100% widthFlex
display: flexFlex.Row
direction: rowFlex.Column
direction: columnAvatar Button Heading Image Input Link Select Spinner Switch Text Textarea
Stack Grid
Breadcrumb Card Form Menu Paragraph
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
avoid the binary notion of "components library components" vs "everything else".
general taxonomy of responsibilities
useful for discovery but not when imposed
useful other conceiving metaphores
declarations
timeless
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.
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.
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>
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.
src/components.