How To ‘Design’ a Design System — Part II
In the previous article, I have talked about how we separated our Design System’s atomic components and how we gave styles over the class structure we created.
In this article, we will talk about the components that are not at the atomic level and the communication scheme between them!
As you can remember this was our structure;
In our main application that our customers are using, we used those Atoms to build our interface. At this stage if we want to summarize our project;
- Atoms -> Published in npm
- Molecules -> Published in npm
- Organisms -> Reside under the main application
- Templates -> Reside under the main application
- Pages -> Reside under the main application
Our goal was to create Atoms & Molecules and publish them over npm to give usage for our internal developers to build UI interface in our main application.
Below, you can find a visual representative of usage of the elements. By using Atoms, we create Molecules, by using Molecules, Organisms are created and so on.
There is a breakpoint in the visual if you looked it carefully. There is not any merge process to create Pages, changes are content based. So basically we merge smaller components until Templates step and after that we fill it with the content. It get only the content that we want to show. Most of the time content is based on fetching some data from backend and displaying it to the user. The content is based on the user, all of the functionality and these kind of processes handled under the Pages.
For this structure, we have used props and events to pass and handle the data. I think below image is summarizing this idea perfectly.
I tried to represent an example where we display the username to our user and a field where user can change his/her username. We pass user name value from the most parent component which is under the “Pages”, to its children and from that children to other children by prop. When user requests to change user name by text field we catch that event, let’s say button click. It emits events and we catch it from its parent and repeat this method until we reach “Pages”. Once we reach the Pages we send request to API to handle changing username. Once the API call is resolved, we fetch it with the new value and pass the value to children with props.
With this structure we believe that it’s organized and we know where all the logical code goes.
Thank you for your time, if you have any feedbacks or questions please let us know!
