Laying things out in React

In the React world we encapsulate the styles within the components. Even though we hear about CSS-in-JS quite a lot these days, the JavaScript developers hate to touch the CSS. Then, how do we make JavaScript developers work with designers and HTML/CSS developers without much hiccups?

It’s hard for a developer to switch context between a logical (while writing JavaScript) and a graphical thought processes. To avoid such context switching, we have to separate presentational code from behavioural. So that we can let the designers worry about the presentation and JavaScript developers worry about the behaviour. Back in the days, we achieved similar separation – structure and presentation – using HTML and CSS. Let’s see if we can separate presentation and behaviour within React code today.

When we work on React project, our team will have a HTML/CSS fluent designer or a developer, and a JavaScript (React) developer. The former focus on building stateless components with styles and the later composes the stateless components with stateful components (Containers). Thus, all the scary part of the CSS is hidden underneath the stateless components.

For a small project this will work out smoothly. But while working on bigger projects composing the components will need a bit work. Even though we maintain component library using Storybook developers jitter when start to pick up components and compose. We figured out a way to calm them. We created invisible layout components and use them to compose the visible components.

Layout components

Allow me to explain what is a layout component. Here is a component our designer friend Mr. Dan gave us. How do we make this into a React code? Let’s call it <StatsBar>.

3 column stats
Stats as 3 columns. <StatsBar>

We could make a component called <Stat> only to show the label and the value.

Stat
<Stat>

Then we can use <Stat> inside the <StatsBar>, then write some styles using flex-box or floats in <StatsBar> to show as three column.

For a one-off component like <StatsBar> writing styles to show as three column is fine. When we are working bigger projects like a web product or a pattern library, we might have to create similar multicolumn layouts at different places. Sometimes we might need to show as two columns, or other times four columns. We should not write styles for each cases.

We created a component called <Columnizer>. The only job of the component is to display each of it’s child components in a column. This <Columnizer> can be used inside our previously created <StatsBar> component, instead of writing styles show the child elements to render as columns.

Play with code on CodeSandbox

The <Columnizer> component can take prop gutter (values like 2px, 1em, etc) which can set the spacing between two columns. Similarly we could enhance the layout components through props to take care of special cases.

Now, let’s take a look at a bigger and visible layout component. This is a common page layout pattern in web apps, where you have primary content column with additional column on left or right side. Occasionally columns on both sides too. Usually, this component will have some styles like background color, border radius or shadow.

Block UI Pattern
Common page layout pattern, single content column or content content with a side column

Designers or developers might uses Bootstrap’s grid class names pattern to recreate this design in code using a grid framework. But, such a component is very easy to code with just a few lines of CSS. Also, we can avoid style sheets getting bigger in size by avoiding grid frameworks.

We can create a component <Block>, which render it’s children in the main column. It can take two props, leftSideBar and rightSideBar. Elements passed in to each of these props are rendered in their respective column. See how implemented components responds with presence of content in left and right sidebars. The JavaScript developer need not have to worry about any CSS classes at all.

Play with code on CodeSandbox

The layout components help in running front-end teams smoothly.

Layout Palette

Picking up all the common layout patterns from your projects, create components for each them. Refine them by removing similar patterns and removing one-off components, you get a layout palette. Just like we have colour palettes or typography palettes in design, why can’t we have a layout palette? A better layout palette help in evolution of the product.

We build up layout palette early on while on a pattern library (design systems) project. It helps in reducing inconsistencies creeping up during later phases of the project. Imagine the designer coming up with a way different layout haven’t been used earlier will not be a good idea. It also helps the team to spend enough time testing and tweaking each layout components in different viewport sizes.


Thank you Ciju for suggestions.

Do you have any thoughts on this article? Write to me.