How to achieve the reuse of React components (Translation)

Code reuse is one of the most common key points in software development. Many frameworks and libraries are designed to structure the code for reuse. As it turns out, each of the tools has not only its own approach to achieving this goal, but also its own definition of code reuse.

What is meant by code reuse?

The true definition of code reuse is not a special process, but a development strategy. Reusable components must be created from the start based on their reuse, which implies careful planning and an intuitive API. Although modern tools and frameworks can be maintained and stimulated, reuse is impossible only with the help of technology - this requires a streamlined process between teams and commitment at all levels of the company.

Therefore, when we talk about reuse, it does not mean only the technical part. It also includes corporate culture, training, and many other considerations. We will touch on some of them here, but the fact is that code reuse is a process that affects all development stages and every level of organization.

Walmart consists of several brands, including Sam's Club, Asda, and regional subsidiaries such as Walmart Canada and Walmart Brazil. These brands have dozens of applications created and supported by hundreds of developers.

Because each of these brands takes its place on the Internet, each has developers working on components that are common to all Walmart brands, for example: carousel, Breadcrumbs, pop-ups, components of payment forms. Duplication of the same work that the other team submitted is a waste of time and money, and it is also possible to make the same mistakes by different teams. Eliminating duplication allows developers to be more focused on projects.

On the backend, the use of the code is more intuitive: a service can receive requests from different brands and return relevant data for this brand (there are different ways to handle this depending on the form of the data). For the frontend, the situation is a bit more complicated, because the data from the server is converted and stylized according to a specific brand. For frontend, code reuse is not a fully resolved problem.

Reuse of React Components in @WalmartLabs

We chose React for Walmart.com, mainly because its component model is a good starting point for code reuse, especially in conjunction with Redux for state management. Despite this, Walmart still has difficulty reusing front-end code.

Code Reuse Tools

The first task is related to the technical means of code sharing. Components must be versioned, easy to install and update. We started a separate GitHub organization where we put all the React components. Currently, the components are combined in repositories based on the commands that created them, but we are in the process of transition to a more functional form, for example: the “Navigation” repository containing the components “Breadcrambs”, “Tabs” and “Sidenav Links”. We keep all the components in the internal npm registry, which allows you to install certain versions of the components, ensuring that the application does not suddenly break when the component is updated.

Since the code is used by several teams, we need to adhere to a consistent package structure and standards for hundreds of components. Therefore, we came to the creation of Electrode Archetypes for components and applications . Archetypes contain eslint, babel and webpack configuration files and are the main place where we manage dependencies using Gulp tasks and npm scripts. Starting development with a standardized structure allows us to maintain high standards throughout the company, it also gives developers confidence in someone else’s code and increases the chances of code reuse. It also increases the confidence of the streamlined Continious Integration and Continous Deployment processes that run Eslint, performance tests and cross-browser tests using different screen resolutions. When creating pull requests, Continious Integration can publish beta versions of components and run functional tests of all applications using this component. This guarantees that the pull request will not break anything.

Meta team

In the first days of this project, most of the shared components were brought in only by certain teams, and these components changed very quickly. In the end, we selected several developers with a deep understanding of the structure of Electrode and Walmart from the inside and created a group that we call the meta team. These people devote several hours or one day every few weeks to look at the code that is included in the organization of the components, to ensure that all the best practices are followed and, in general, they help and help in possible ways. This team also collected general information about what is being created throughout the organization, and promoted Electrode in its own teams. Meta team members also distributed information about upcoming archetypes changes in their teams and collected feedback for the main Electrode team.

It was a good start, but we still saw additional possibilities on how to improve code reuse.

The problem of finding hundreds of components

We started to notice a lot of similar messages in our Slack channels. Developers asked if a component already exists for a specific task. UX teams wanted to see which components are available. Managers were interested in what components are created by other teams. The common thread of all these messages was the detection of the components. We need a quick and easy way to find out what components are available, to see how they are used and how to interact with them, to learn more about implementation, configuration and dependencies.

Our response to this problem was Electrode Explorer , which I described in a previous post . Explorer allows developers to view hundreds of components available in @WalmartLabs, read their documentation and see how they really look in the browser, and even view previous versions of the component and see how they have changed over time. Since Electrode Explorer provides a web interface for all React components in an organization, developers do not need to run npm install in order to see and interact with the component.

Difficulties to completely avoid duplication

Even with all these tools and processes to reuse code, we still had difficulties. One of the problems was that teams often developed new components, not realizing that they could be useful to other teams. Components could not be reused unless they were originally included in the ecosystem with code reuse. Even within the framework of a common system of components, we observed a lot of duplication, there were also components that were slightly different from the approach in other components with similar tasks. We realized that a single technological solution was not enough - it was necessary to change the thinking on a company scale, in which all interested parties at all levels use a code-oriented approach. This included allocating project time to generalize components, expanding existing components instead of creating new ones, and consciously look for code sharing opportunities where possible.

To help in this process, we created a process where we could offer new components. Under this system, developers discuss new components before starting work on them. This gives developers in other teams the opportunity to propose existing solutions or alternative approaches and informs other people in the team about what is happening.

The process of proposing components along with the meta-process helped avoid duplications that still occurred from time to time.

The Importance of Continious Integartion and Continious Deployment (CI / CD)

We are faced with one serious problem, that as long as one team will work on a component, this can harm the application of another team. If you have not blocked a component on a specific version in a project, your CI / CD may report failed tests, because the component was changed in another team. These are very unpleasant situations that have led many teams to block components on certain versions, which does not even allow accepting new patches for a component.

Exactly at this moment CI / CD manifests itself in all its glory. When a component is updated, automation should run tests for applications that use the same major version of the component. Tests are run even if the application has blocked the component on a specific version. The CI / CD system creates a pull request for a request to update a locked version to a new one if the tests were successful. In case of failures on tests, teams receive notifications, and later jointly solve the problem.

Inner source philosophy

The underlying factor for reuse has been our understanding of the open source / inner source philosophy described by Laurent Desegur in a previous article . WalmartLabs has been actively using and developing open source for many years, as evidenced by projects like Hapi, OneOps and Electrode. Outside the company is not so noticeable, but we are very committed to the model of the inner source, which, in fact, is a closed implementation of open source. In the inner source approach, no team or developer “owns” a component — all components are common to the entire organization. This reduces potential errors and allows developers to focus on improving existing components.

This policy has greatly enhanced reusability. More importantly, she informs developers of our commitment to the philosophy of collaboration. It also allows developers to use their time and knowledge where they are most needed, instead of spending time catching a complex error in the code, and they bring real benefits to the company, which is easy to notice.

findings

Reuse is not just a technical solution, but also a philosophical approach that requires organizational commitment and has long-term implications. At WalmartLabs, we saw the benefits it can bring - we are now transferring SamsClub.com to the Electrode platform, and our developers reuse hundreds of components from Walmart.com with settings for Sam's Club.

Tell your reuse history - what problems did you encounter? How did you solve them? What would you like to improve in the future?

Original text of the article