DEV Community: Parth Narielwala

Take styled-components to the next level

Parth Narielwala — Fri, 22 Jul 2022 20:35:00 +0000

Most of us have been aware of CSS-in-JS libraries since around 2015 and they have come a long way since! The top libraries that most people are familiar with are styled-components and emotion. They have mostly the same API and syntax and for this article, I won’t go into the differences between the two.

One of the main benefits that CSS-in-JS (for this article I’ll mainly reference styled-components) provides is the ability to write, quite obviously, CSS in javascript files. This is usually either through using a template string like:

import { styled } from 'styled-components'

const Container = styled.div`
  background-color: white;
`

…as well as using a Javascript object:

import { styled } from 'styled-components'

const Container = styled.div({
  backgroundColor: 'white',
})

This especially changed the game for the React world because now we can pass props to these styled components for contextual use cases

import { styled } from 'styled-components'

const Container = styled.div((props) => ({
  backgroundColor: props.mode === 'light' ? 'white' : 'black',
}))

const MyComponent = () => {
  const { mode } = useThemeContext()

  return <Container mode={mode}>...</Container>
}

No more messing with classes and CSS (Sass/Less) files!

Pitfalls

The flexibility of styled-components is great for developers to get started using it, but it can also create problems for large teams that may not have the best communication standards and best practices in place. Some developers may use the template literals, while others use CSS objects. This can cause some inconsistency in how design tokens are utilized and can cause one-off values that can make it difficult to update according to a set theme. This is where styled-system can help with giving CSS-in-JS more structure to help build a robust design system component library.

What is `styled-system`

Styled System lets you quickly build custom UI components with constraint-based style props based on scales defined in your theme.

It allows for style props to be added directly to styled-components so that it doesn't need to be done manually. It also hooks into the theme in a type-safe way to take the guesswork out of what type of variable should be used according to the design system.

<Box
  fontSize={4} // 4th index in theme fontSizes = ['0.5rem', 0.75rem', '1rem', 1.5rem']
  fontWeight='bold'
  p={3} // 3rd index in theme spacing = ['0px', '2px', '4px', '8px', '16px']
  mb={[ 4, 5 ]}
  color='white'
  bg='primary' // contextual color value at the theme level
>
  Hello World
</Box>

How does this help?

Why would we want to add something like this to the way we already do things with styled-components?

First-class theming

When working with styled-components, we often use the styled function that is offered. With this function, we can define what type of HTML element we want to use. To take that even further, we can even add styles to any React component (granted it accepts and passes the className to the component's underlying elements).

import { styled } from 'styled-components'
import { colors } from 'design'

const Container = styled.div`
  background-color: white;
  color: ${colors.green4};
  border-color: ${(props) => props.theme.primaryColor}
`

As you can see, we have three different ways to define a color. And the right way may not be so apparent, especially to someone who is not familiar with the code base. This ambiguity allows for theming to be a second-class citizen and for it to seem acceptable to have many one-off values (in a few cases it can be acceptable). So what if there is only one real way to define this color (two if you'd like to consider the "escape hatch" css prop as an option)?

<Box
  {/* with Typescript we can restrict these values to what is a part of the theme */}
  bg="white"
  color="green3"
  borderColor="primaryColor"
>
  ...
</Box>

These three values come directly from the theme object if it were to look like this:

export const theme = {
  colors: {
    white: '#fff',
    green3: '#1ea676',
    primaryColor: '#1ea676',
  }
}

Responsiveness

We live in a world that has so many devices and devices sizes to access the web. And because all those different devices have their own screen sizes, our site needs to be responsive to be able to provide an elegant user interface for each of those devices. To do so we utilize media queries and show styling based on the different device screen sizes. The way we currently do that with styled-components looks like this:

import { styled } from 'styled-components'
import { size, mediaQueries } from 'design'

const Container = styled.div`
  margin-top: ${size.sm}px; /* sometimes we forget about handling the mobile size */

  ${mediaQueries.forTabletVerticalUp} {
    margin-top: ${size.md}px;
  }

  /* sometimes we forget about handling the large desktop size */
`

With styled-system, almost every prop comes with a scaled value option - meaning we can easily give a value for each defined breakpoint. Let's say our theme breakpoints are set up like

export const theme = {
  breakpoints: ['400px', '600px', '900px', '1200px'], // mobile, tablet, desktop, large desktop
  size: {
    0: '0px',
    sm: '4px',
    md: '8px',
    lg: '16px',
  }
}

We can write our components like below without having to wrap styled around it and manually set the media queries

<Box
  marginTop={['sm', 'md']} // 'sm' for mobile, 'md' for everything larger
>
  ...
</Box>

Atomic Design

Atomic Design is a design concept that web elements should build upon each other like atoms, molecules, organisms, and so on.

This concept is a bit tough to achieve with styled-components alone because, with the styled method, we tend to "extend" components constantly just to add some styling. When we extend these base components like that, we are essentially trying to recreate the atom with different protons and neutrons and to any newcomer, it looks like a new atom.

With styled-system, we maintain the base components as much as possible by relying on specialization - which means adding different prop values to add a specialization to a more generic component. This way as the team grows and new developers look at the codebase, it is more apparent what the underlying HTML markup is and what the intentions are.

To explain an example:

a button element is an atom
a styled-system + styled-component Button is a molecule
components that ingest a Button would be an organism
a collection of organisms that make up an experience would be a template
templates make up a page

Downsides to `styled-system`

Not actively maintained

Unfortunately, the styled-system repo on Github is not actively maintained but that doesn’t mean it’s useless. This just means that no further improvements or fixes will be made and if the tool does not need any fixes then that’s okay. styled-system is super lightweight and does not have any real (shipped) dependencies. Essentially it’s a collection of methods that can be added to either styled-components or emotion to enable various style props. This is why the package size is ~150kb, which is pretty small!

Other alternatives are more robust

The creators of styled-system also have created theme-ui, which is a more full-fledged (and more fledge-ness coming soon) than styled-system. The main difference between the two is that theme-ui is opinionated to use emotion under the hood and is not compatible with styled-components (read more). Both of them do use the System UI specification as well as a few more that you can find here.

Conclusion

I believe the concept of styled-system is huge, especially when paired with Typescript, in developing a robust design system and component library. It allows for defining the styles inline with the component instead of somewhere else, which can make writing CSS less painful - especially if Typescript can tell you variables you have to pick from and it doesn’t give you an option to veer away from it unless you really try hard. And because it allows you to make your components more strict when it comes to what design token options it accepts, the more resilient to change they are as those tokens can be changed in one place and that change updates all the components respectively since they have to use the tokens and not one-off values.

So, if you work with a large group and would like to avoid rewriting the same styles and CSS values, I would highly recommend styled-system or any of the other libraries using the System UI specification. #happycoding

Replace your test fixtures with builders

Parth Narielwala — Thu, 07 Jul 2022 16:55:04 +0000

I know most of us are not the biggest fans of writing unit tests for our code. We just want to write our awesome, bug free code and ship it fast! As ideal as this sounds, it’s not realistic and bugs will happen sooner or later - especially if other developers are working on your code without much context and breaks something.

We can all agree that unit testing can get tedious and take forever to write, especially when you have to manually defined your test data. Test data can come in all different shapes and sizes but many people are most familiar with test fixtures.

Test fixtures are essentially example data objects that can be used in many instances of your unit tests. In Javascript, you’ll find them typically in a .json file or a Javascript file as an object {} type.

As your application grows, so will your test fixtures with different variations of the same object type. This can create many obscure one-off fixtures that may be difficult to modify and fit your specific test needs.

Object Mother

The Object Mother is one pattern that can help solve this problem. This pattern extracts these fixtures in a more factory-like pattern.

var testOrder = {
  order_id: 123,
  line_items: [{
    line_item_id: 888,
    product_uuid: 'aaa-bbb-111-222'
  }],
  total: '10.99',
}

/* becomes */

var createSmallOrder = () => ({
  order_id: 123,
  line_items: [{
    line_item_id: 888,
    product_uuid: 'aaa-bbb-111-222'
  }],
  total: '10.99',
})

var createLargeOrder = () => ({
  order_id: 123,
  line_items: [{
    line_item_id: 888,
    product_uuid: 'aaa-bbb-111-222'
  }, 
  /* redacted for brevity */
  {
    line_item_id: 101010,
    product_uuid: 'aaa-bbb-111-222'
  }],
  total: '100.25',
})

var OrderMother = {
  createSmallOrder,
  createLargeOrder
}

This pattern is more useful in class-based programming languages that have unique getters and setters, where one could call a method on the Object Mother and only affect that instance but it doesn’t quite work for Javascript land.

Builders

This is where we could look towards “builders”. I like to use the word “builders” instead of factory, because factories remind me of having a getter, and more importantly in this case a setter, on the factory object to make any changes to the test data we need for the specific test case. Builders give us a fresh new object where we can override any property and works with immutable objects.

If we look at our previous example

var testOrder = {
  order_id: 123,
  line_items: [{
    line_item_id: 888,
    product_uuid: 'aaa-bbb-111-222'
  }],
  total: '10.99',
}

/* this would become */

const baseLineItem = {
  line_item_id: 888,
  product_uuid: 'aaa-bbb-111-222'
}

const baseOrder = {
  order_id: 123,
  line_items: [baseLineItem],
  total: '10.99',
}

const aLineItem = (overrides) => ({
  ...baseLineItem,
  ...overrides,
})

const anOrder = (overrides) => ({
  ...baseLineItem,
  ...overrides,
})

This allows us to essentially build our test objects with defaults while being able to override what is important to the test. If the test if checking for the total price to be of a certain value, we can set that value manually and in our tests expect that value to appear

test('outputs proper total cost', () => {
  const order = anOrder({ total: '19.99'})
  const value = getOrderTotalFormatted(order)

  expect(value).toBe('$19.99')
})

Here we don’t care about what the order_id is or what the line_items are, we just want to know that the output is depending on what we are passing in and defining explicitly.

Specialized objects

This is a very simple and broad example but we can even have some builders that act like Object Mothers, in that they are objects for a specific use case.

const baseLineItem = {
  line_item_id: 888,
  product_uuid: 'aaa-bbb-111-222'
}

const baseOrder = {
  order_id: 123,
  line_items: [baseLineItem],
  total: '10.99',
}

const aLineItem = (overrides) => ({
  ...baseLineItem,
  ...overrides,
})

const anOrder = (overrides) => ({
  ...baseLineItem,
  ...overrides,
})

const anEmptyOrder = () => anOrder({
  line_items: [],
  total: '0.00',
})

Notice that we are using the simple builder here to define anEmptyOrder because we only care about setting certain properties and properties like order_id is irrelevant to this specialized case.

Resilient to change

Another powerful aspect of this is that if the order object gains a new property, let’s say shipping_method_id, then only the baseOrder needs that new property and all the builders will now have it!

/* redacted for brevity */

const baseOrder = {
  order_id: 123,
  line_items: [baseLineItem],
  total: '10.99',
  shipping_method_id: 3
}

/* redacted for brevity */

const anEmptyOrder = () => anOrder({
  line_items: [],
  total: '0.00',
}) // now this will come with `shipping_method_id: 3` 🙌🏽

Conclusion

I’ve been using builders for the past several years and they have made writing unit tests less painful. I love the fact that I can use a default test object and override just what I need in a way it’s clear when reading the tests what the important details are. I encourage you to give this a shot and hopefully this make writing tests a bit less painful for you as well. #happycoding

DEV Community: Parth Narielwala

Take styled-components to the next level

Pitfalls

What is styled-system

How does this help?

First-class theming

Responsiveness

Atomic Design

Downsides to styled-system

Conclusion

Replace your test fixtures with builders

Object Mother

Builders

Specialized objects

Resilient to change

Conclusion

What is `styled-system`

Downsides to `styled-system`