This blog is part of the Blinkit React Native blog series. Through this series, we attempt to share the journey of integrating React Native into one of India’s largest e-commerce grocery web & native apps.

Two years ago, we at Blinkit (formerly Grofers) decided to integrate React-Native to power our frontend platforms (android, iOS, web). During this time, we found many goods and bads of React Native. So after migrating most of our screens to React-Native, we decided to revamp our app.

During the planning phase of revamping, we figured out the problems we used to face during development. As a result, we decided to make our own design system. We had already discussed the need for a design system in our previous blog. This blog will shed some light on the problems we faced from an engineering perspective and how we built our storybook-powered React-Native design library for our design system.

Why Design System?

Design System Illustration

First things first. Why Design System? Some might argue that a frontend developer can always look at the design on some tool and create screens. Furthermore, reusable components can be created, and things can go on based on some common usage.

S̵a̵m̵e̵ Different Component

Generally, before creating a screen, designers share a screen-level design with the developer. On small-scale projects, you can create the whole screen in a single file. When the project starts to grow, the need for reusable components is realized. Finally comes the point when the project becomes so complex that it’s difficult to identify existing reusable components.

On a large-scale project, without a proper design library and documentation, the visibility of existing components is low. For a developer, creating a new component is less time-consuming than finding an existing one as we need to put more effort to understand the use-case and see if we can use the existing component or not. One major reason devs go for new components is you don’t have to worry about breaking things at other unknown places.

We too, realized that we were creating new components in cases where some existing components could be used. Designers and developers were out of sync, and we were unnecessarily increasing the size of our codebase.

For reference, here is an illustration of a few buttons we had in our codebase:

They’re all the same!

Build, Build, Build

In most cases, every single line we wrote in react-native impacted all our platforms (Android, iOS and Web). However, sometimes the result is not the same across platforms, so it’s necessary to do a design review on all platforms before any release. For a web developer working on react-native, building and deploying every platform and getting reviews done for each one requires extra effort and time. In cases where some changes are required after review, the same process has to be followed repeatedly. Due to this, the time to release any feature also increases.

Creating a design library will separate the UI logic from the code(less size and build time), and all components could be tested on all platforms beforehand.

The journey from Design System to Design Library

After understanding the problems, we decided to create our own design library. Our objective was to make it easier to develop, view changes instantly across platforms and reduce deployment time. More importantly, we wanted to increase the visibility of the design library.

So we begin with a basic react-native typescript project structure. Inside the src directory, we created the levels from our design system i.e Constants, Elements, Components as folders. Each of them has an index file which exports all its content. Finally, we have an index file at the root level, which exports the index file of Constants, Elements and Components. This can be further used as main for our project.

To view the content we were creating, we created an example folder in parallel with src. Example folder is basically an expo project where our root src was linked through project reference.

The example folder route was not enough for what we were trying to achieve (visibility of components & documentation). Henceforth, in addition to that, we started exploring different tools out there.

After some time of researching, we decided to go with Storybook.

Storybook supports both react and react-native and has some amazing features which make documentation and UI Testing much easier. Storybook react provides better documentation, viewport and some amazing addon. so we decided to use it for viewing and documentation purposes apart from testing on the web platform. We created a web folder inside storybook which is essentially a storybook react project. Similarly for android and ios, we initialized a new expo project inside storybook/native and installed storybook react-native as a dependency.

For using our design library we shipped the transpiled version of our project (except the storybook folder) to other projects.

How to use the library inside storybook projects?

Our idea was to deploy the master branch of our storybook across different platforms. We realized, that the best option available to view changes while developing was storybook. In order to achieve that, we installed our library package master branch in each of our storybook projects under the storybook folder. So while in the development mode, we pointed the installed design library in storybook to local root folder.

Deployment

Storybook react provides pre-configured scripts, so building storybook web was direct. For storybook native (android & iOS), we used expo export provided by expo.

The build for both native and web projects were incredibly fast and light. Generally it takes 30–40 minutes to create a build for any platform(this includes business logic code + Automation testing). The design library takes around 5–10 minutes to build and deploy all platforms.

We created a Jenkins Pipeline to deploy changes continuously–by deploying the build to AWS once any pull request is merged into master.

Sometime later, we realized that our build was so light that we could deploy a build for every Pull Request that was being created.

Visualizing Button in design library

Here are some variants of the button which was created on the design system.

Design System for Button

And each one of them can be viewed on a single storybook canvas

Button Storybook implementation

And in the documentation section, we can check what the usage of each Props

Button Storybook Documentation

Result

The first problem that was around the visibility of components was solved using storybook. Apart from that, storybook UI Testing provides another great feature of viewing components with different props. This helped us to quickly check edge-cases of a component that might get missed while developing.

The second problem with the long deployment time got solved with the design library and Jenkins Pipeline. So here is how it works now:

Once a pull request is raised, the Jenkins pipeline starts to build storybook web and native in parallel. Once the deployment is complete, a design reviewer gets a web URL and two expo URLs (android + iOS) for testing which is unique for each pull request. If some changes are required from the design side, one needs to just commit the changes into the pull request and it will start the deployment again to the same URL. Once the changes are deployed, the designer can refresh the exact URLs to view the updated change.

Since all these components are tested on all platforms prior to production deployments, we can directly use them in our main project. In 99% of the cases, our components from the design library don’t break in our production build.