Share your happiness and your UI KIT
The UI Kit is one of the key factors in keeping a clean and tidy web application. It’s a powerful way to efficiently and globally update the UI of an app.
To enjoy all the benefits of a UI kit, it is mandatory to have only ONE SOURCE OF TRUTH. This file must be trusted and relied on in just one place. Where things get messy: keeping a consistent, singular and versioned UI Kit (regardless of the technologies used).
I’ve identified two potential catalysts of UI kit conflicts; modification, and (technical) implementation. Let’s see how to keep things clean during these two phases.
Multiple actors, only one UI KIT
Let’s create a mess! I joke because it’s not far from the truth. In my current work, there are a lot, I mean, A LOT, of projects going on at the same time. Features, MVP, refactoring, re-design… all of them could potentially sabotage my efforts to work in an orderly way. New font sizes, gradients, box shadows are created/updated making the UI Kit ever evolving. But, to reiterate, the key is keeping ONE version, in ONE place.
Improving communication between the teams, sharing better processes, new guidelines, and all other management keywords could help. Yet, following one simple rule works pretty well for me: “one source of truth for designer and developer, in one place”.
I recently found a brilliant tool to help implement this process: brand.ai. Designers can upload and update styles directly from SKETCH and developers can fetch it under different format (JSON for instance) or view it on the web app. Pretty good concept, go ahead and try it! But how do you deal with different technologies?
Inline Style, CSS pre-processors and UI KIT
I will describe here how to deal with the UI Kit and ReactJS. I’m sure you have heard about it. But, if you haven’t, I strongly advise you to have a look at it, it’s pretty awesome.
There’s different approaches regarding how to deal with components style in React: inline style, css with css modules… I’m pretty fond of inline style because you can have the style and the logic of your component in the same file, keeping things tidy (again). There are tons of libraries, helpers and concepts to deal with it and you can find a really good list of these in the CSS-IN-JS list. Take a look!
If you like simple inline style as I do, you can pass the CSS attributes via a JS Object. Let’s see a simple example:
Simple and clean, ey? I love it! As you can see here we apply the attribute colour: ‘blue’ to our main container in the component.
But wait a second, it’s not blue, it’s coming from a file!
Well spotted! Indeed it’s coming from the ui-kit.json file. This is the ONLY file describing the UI Kit, required by WebPack (or other supporting JSON formats). It is containing an object with all the variables needed in the web-app : colours, font sizes, spacing… So in your React component, simply require this file and apply the style you want.
Ok, I’m familiar with inline style and javascript, there’s nothing new here.
I agree, it’s simple but it demonstrates my first concept: keep only one file for your UI Kit. It will help avoid duplication and a messy situation. But, how do you avoid that if you’re using a CSS pre-processor?
This is where it gets interesting. I will take the example of Stylus pre-processor here but I’m sure all of the others can achieve that as well.
Stylus API provides a function called JSON and gives you the ability to upload variables from a JSON file. This way, you can simply import the ui-kit.json file in your app.styl file and use these variables in your app!
You now share your UI KIT between Inline-Style and Stylus.
Sounds interesting, examples?
I built a boilerplate including WebPack, React, Redux and Immutable (and other little components like side-menu sliders or modals…) using this UI KIT sharing concept. Check it out here: https://github.com/PBRT/reactogo/. You will see the ui-kit.json file under client/style folder. This file is loaded in Stylus in the app.styl file.
For those who are familiar with WebPack check out the webpack.config.js file. The ui-kit.json file is loaded in the ProvidePlugin via the json-loader. This way you don’t have to require it in all the files you need, it’s in the UI object available globally (i.e. each time WebPack will see the UI variable, it will require the ui-kit.json file).
Conclusion
We know now how to deal with two different styling methods and keep only one UI KIT. Since I adopted this method, everything became easier and cleaner. Adding a colour has never been so easy ;)
To conclude, try to keep one source of truth for your UI Kit, and agree on how to update it!
Thanks for reading, any feedback is much appreciated!
