Pattern libraries and Atomic Design
- Design Systems, wtf?. Design is changing the world, so we… | by Marcos Peebles | Medium
- Using React within a Design System | by Panos Voudouris | Medium
There are buttons, drop-downs, forms, animations and what-not that we have to build, day-in, day-out to create the various apps we put out for our customers to use. The traditional approach so far was that some UX person does what a UX person does, then a UI designer does what a UI designer does and eventually a developer ends up with some PDF or PSD file that has a breakdown of the, let’s say, address details form to decipher and build. By the time the code is done, the UI/UX people have moved on and the developer has a raft of unanswered answers:
- “John Smith” fits nicely in that box but what about “Maria de Los Angeles Hernandez”?-
…so the form breaks to the smaller layout at 800px while the header does so at 750px…?
In any case, these questions are likely not to even be asked until QA has picked this up, which in some cases can be weeks after the code was done. Where I’m getting at is this: by the time the issues are done, nobody knows where the design came from, who coded it and why it was even required. So we might as well release it, because the boss is asking for something, /anything/, to be released. The big red deploy button is pressed and…everyone is disappointed. The customer, the designers, the developers, the CEO. Predictably, it is /your/ fault for not implementing the glossy design properly.
Enter Storybook. Storybook is a great tool for showing our React components. At a basic level it is just a React application itself which displays our React components. The way it works is by writing “stories” that describe how the components are to be displayed and setup. This is similar to writing a unit test and the syntax is very simple. Here’s a one line explanation from the docs:
Technically, a story is a function that returns a React element.
If we start to look at what it gives a developer, on their local machine, it is this: the ability to visualise the React components without having to run the actual application being developed. The advantage of this is that we can now view our component, /interact/ with it (after all, this is a React app using our React components) and see very quickly what it is we are developing. This cannot be underestimated. The alternative is to either run the actual app, mocking the flow to the point where we can see our new component, or to build some artificial page showing the components.
https://codeburst.io/atomic-design-with-react-e7aea8152957
When we started to use Atomic Design within React we had to adjust some rules of the methodology to ensure that components were reused as much as possible, that they were stateless, without styles of positions and very specific margins so to avoid any side effects in the pages of application.
So with each new component we asked ourselves: “Are these components generic enough to avoid specificity and/or repeated code in whatever context they are used?”
So we were able to write a few rules:
The Atomic Design should have a file of variables and it must be imported by each component;
The atoms should be written without margins and positions;
Only the molecules and organisms can set the positions of atoms, but these stacks can’t have any styles of margins and positions;
Templates have only one function: to set the grid of pages but never positions of specific components;
Pages render the components with a template defined and it’s here that the Atomic Design will be connected to the rest of the application;
Created on: 28th October, 2022
Last updated: 28th October, 2022
Tagged With: