May 26, 2017 at 07:45How to Reuse 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 initially be designed with reusability in mind, which requires careful planning and an intuitive API. Although modern tools and frameworks can support and stimulate, reuse is impossible only with the help of technology - this requires an established process between teams, and commitment at all levels of the company.
Therefore, when we talk about reuse, this does not imply only the technical part. It also includes corporate culture, training, and many other considerations. We will cover some of them here, but the fact is that code reuse is a process that affects all stages of development and every level of organization.
Walmart is comprised of several brands, including Sam's Club, Asda, and regional affiliates such as Walmart Canada and Walmart Brazil. These brands have dozens of applications created and supported by hundreds of developers.
Since each of these brands has its own place on the Internet, each has developers working on components that are common to all Walmart brands, for example: carousel, Breadcrumbs, pop-ups, payment form components. Duplication of the same work that the other team handed over 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: some service can accept requests from different brands and return the relevant data for this brand (there are different ways to deal with this depending on the form of data). For the front-end, the situation is a little more complicated, because the data from the server is converted and styled according to a particular brand. For front-end code reuse is not a fully resolved issue.
Reusing React Components in @WalmartLabs
We chose React for Walmart.com, mainly because its component model is a good starting point for code reuse, especially when combined with Redux for state management. Despite this, Walmart still has difficulty reusing front-end code.
Code Reuse Tools
The first task is related to technical means of code sharing. Components must be versioned, easy to install, and updated. We set up a separate GitHub organization where we put all the React components. Currently, the components are combined in the repositories based on the commands that created them, but we are in the process of moving to a more functional look, for example: the Navigation repository containing the Breadcrambs, Tabs and Sidenav Links components. We keep all components in the internal npm registry, which allows us to install certain versions of the components, ensuring that the application does not suddenly crash 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 adds confidence to developers in other people's code and increases the chances of code reuse. It also increases confidence in the streamlined Continious Integration and Continous Deployment processes that run Eslint, performance tests, and cross-browser tests using different screen resolutions. When creating a request pool, Continious Integration can publish beta versions of components and run functional tests of all applications using this component. This ensures that pull request does not break anything.
Meta team
In the early days of this project, most of the shared components were introduced only by specific 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 review the code included in the organization of the components, ensure compliance with all best practices and, in general, contribute 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. Members of the meta team also shared 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 opportunities to improve code reuse.
The problem of detecting hundreds of components
We began to notice many similar messages in our Slack channels. Developers asked if a component already existed for a specific task. UX teams wanted to see which components are available. Managers were interested in which components are created by other teams. The common thread of all these messages was the detection of components. We need a quick and easy way to find out which components are available, to see how they are used and how to interact with them, to learn more about implementation, configuration and dependencies.
Our answer to this problem was Electrode Explorer , which I talked about 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 a browser, and even view previous versions of a component and see how they have changed over time. Because Electrode Explorer provides a web interface for all React components in the organization, developers do not need to run npm installin order to see and interact with the component.
Difficulties in completely eliminating duplication
Even with all these tools and processes for reusing code, we still had difficulty. One of the problems was that teams often developed new components without realizing that they could be useful to other teams. Components could not be reused unless they were initially included in the ecosystem with code reuse. Even within the general system of components, we observed a lot of duplication, there were also components that were slightly different from the approaches in other components with similar tasks. We realized that a technological solution alone was not enough - it was necessary to change the thinking at the scale of the company, in which all stakeholders at all levels use an approach focused on code reuse.
To help with this process, we created a process where we could offer new components. As part of 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 keeps other people in the team informed about what is happening.
The component suggestion process along with the meta-process helped to avoid duplications that still occurred from time to time.
The Importance of Continious Integartion and Continious Deployment (CI / CD)
We faced one serious problem, that while one team will work on a component - this may harm the application of another team. If you did not block the component on a specific version in the project, your CI / CD may report failed tests because the component was changed in another command. These are very unpleasant situations that led many teams to block components on certain versions, which does not even allow you to accept new patches for a component.
Exactly at this moment CI / CD shows itself in all its glory. When a component is updated, automation should run tests on applications that use the same major version of the component. Tests run even if the application has blocked a component on a specific version. The CI / CD system creates a pull request to request the upgrade of a locked version to a new one if the tests are successful. In the event of failures in the tests, the teams receive notifications, and later jointly resolve 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 inner source model, which, in fact, is a closed implementation of open source. In the inner source approach, no team or developer “owns” the 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 expanded the possibilities for reuse. More importantly, it informs developers of our commitment to a collaborative philosophy. 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.
conclusions
Reuse is not just a technical solution, but also a philosophical approach that requires organizational commitment and has long-term consequences. At WalmartLabs, we saw the benefits that it can bring - we are now moving SamsClub.com to the Electrode platform, and our developers are reusing hundreds of Walmart.com components with settings for Sam's Club.
Tell your reuse story - what problems did you encounter? How did you solve them? What would you like to improve in the future?