How Paypal, Walmart, and Farfetch Leveraged Component Reusability to Scale Frontend

Component reusability is one of the common buzzwords in application development, which decides the extent to which a component can be reused within an environment. For starters, it eliminates code duplication, helps maintain consistent structure across different frontends, improves application development efficiency, and makes code testing better. Besides, front-end frameworks like React, Angular, Vue, and others simplify reusing components and improve collaboration between teams for any web app development project.

Now, there are many conventional methods adopted for reusing components among the developer community. However, the atomic design methodology by Brad Frost is preferred for the ease of updating and removing components that it brings. According to this methodology, a website is broken down into basic components and then these components work their way up to build an entire application. Frost describes it as follows:-

The five stages of the atomic design are:-

• Atoms are the basic HTML elements (form labels, inputs, buttons) that form the building blocks of an interface.
• Molecules are the simple UI groups that together function as a unit.
• Organisms are complex UI elements that are made up of a group of atoms and/or molecules or other organisms.
• Templates are page-level objects that arrange the components in a layout and establish the design’s fundamental content structure.
• Pages are finally the specific illustrations of templates that show us how the UI looks like with representational content.

Frost further sums up the methodology as:-

Here’s an example of ABC Life and how they used atomic design in their organization to explain it better:

ABC Life leverages the Atomic Design methodology for their component library

ABC Life hit a speedbump where their existing style guide wasn’t sufficient for the implementation process. The product teams needed to write markups to match the prescribed CSS and JavaScript conventions.

To deal with this inefficiency, they introduced a component library.

Similar to Atomic Design methodology, their component library outlines the component design convention in great detail. It includes patterns, naming conventions, language, and everything in between.

Having said that, component reusability is often considered a challenge in large organizations as teams are expected to deliver functional features within strict deadlines. As a result, most developers prefer building components from scratch. This blog explores the common issues faced by organizations in adopting reusable components in their systems. Furthermore, it includes the toolset that organizations leverage for a smooth integration of components.

At Walmart, with hundreds of developers working on similar components used for various frontend applications, the chances of code duplication were high. While React’s component model made reusing the code much more straightforward, there were still many challenges on the way.

Walmart extended its services with 12 websites in 11 countries, including Sam’s Club, Asda, Walmart Canada, and Walmart Brazil. Naturally, its engineering teams were under tremendous pressure while trying to maintain UI uniformity. Furthermore, discovering and sharing 100+ components became a tough task for developers, project managers, and UX teams.

As a result, the developers at Walmart built a solution called the Electrode Explorer in 2016 to tackle these challenges. Intending to improve productivity and create new tools for future scalability, the company migrated to React/Node.js in less than a year.

Electrode Explorer was an independent web application that let the teams display, search, and modify all components. With this app’s creation, the developers had eliminated the need to install components locally and conduct time-consuming searches through multiple repositories. It enabled development teams to view each component with an auto-generated demo in a ‘component playground’.

Similarly, the development teams at Paypal also had their fair share of trouble while adopting a component-reusability model.

Like Walmart, Paypal’s development teams had to solve the difficulty in discovering and sharing components. Component Explorer proved to be the perfect solution that hosted and displayed all components in one place. Further, they used component playground, Storybook to publish the components, and component bot to automate the workflow.

Here are a few quick facts about Paypal’s Component Explorer:

• Interactive components allowed developers and designers to use them without installing them.
• All components were documented and were generated with Storybook docs. They were also packed with a user guide and rendering scenarios for non-technical users.
• Explorer-hosted version tracked components and allowed the users to access changes in the UI evolution.
• It also displayed the production apps that earlier used a component along with its usage and credits.
• Finally, the Storybook plugin system audited components to ensure efficient performance.

More importantly––with Explorer, Paypal introduced component reusability as a practice and not merely a technical process. With this tool, the teams could now devote more time to complex problems and coordination. In this way, component sharing became a part of Paypal’s development cycle instead of remaining just an elective practice.

It was a common practice for development teams at Flock to extract a repository component and use it in two or three different repositories. However, if there was a bug in a code, it also got copied in all the repositories. This resulted in developers spending too much time fixing the bug. Moreover, Flock allows developers to build an application for their Flock teams or even for the whole ecosystem, so maintaining a standard and consistent structure of components was the need of the hour.

The process of creating reusable components started with writing the components in Vue CLI. The developers built extensible components that can consume changes in the future. Although the developers had to restrict themselves from writing these components for situations that may not occur.

Unit tests show developers if a core feature is compromised, so writing them was next in line. For this, Flock created a component library with reusable components. Divyam Rastogi recommends using Storybook to create standalone components and Lerna to modularize components into smaller and manageable repos when they get too heavy to manage.

However, as different teams reuse components, codes become messy and unfit for reuse.
So what can be done in such a scenario?

The development teams at Farfetch found a solution by creating product-agnostic UI components. Let’s take a look at their challenges and approach to solving them:
Farfetch used to create components based on the requirement, but this led to poor component APIs. Additionally, the development teams implemented design specifications without taking into account the approach of designers.

To overcome these roadblocks, development teams began coordinating with designers to analyze the purpose of building components and different areas of usage. Product requirements were kept separate from components. And if a component matched a requirement, it was red-flagged as ‘challenging to reuse’. Additionally, a reusable component API was kept simple with prioritized documentation that included all information required by other teams. Farfetch also utilized tools like Storybook and React Styleguidist to create robust documentation for components.

Creating reusable components is not the answer to all your scaling woes. In its broadest sense, reusability is not a process but a development strategy. It is a practice that requires constant R&D and conscious efforts from the team to make it a success. For organizations to seamlessly integrate component reusability, there are a few things that should not be overlooked. Here’s a quick checklist to help development teams stay on track when adopting reusable components:

5 things to remember while using reusable components

• Always ensure that components are readily available for use by developers and designers.
• A simple and precise user guide on how to use components should be provided to the teams.
• It’s important that components are not complicated and remain bug-free.
• Components need to be easily consumed in other environments without too much processing.
• The cost of components should be reasonable and in sync with the requirements set by the company.

How do you go about reusing components in your organization? What are the different methods you implement? Feel free to share your views, questions, or suggestions on component reusability in the comments below.