Component Based Development Guide
Modularity has been one of the key principles of software development since the 1960s. Applying this principle brings a lot of usefulness to programming. Modularity contributes to the effective use of the principle of separation of responsibilities, which leads to an improvement in the ability to create, reuse, build code.
Nowadays, the application of the principle of modularity in software design has taken a new form, embodied in the components. This is Component Driven Development (CDD). Modern libraries and frameworks for developing user interfaces, such as React , Vue, and Angular , as well as CDD-oriented tools like Bit , allow you to create applications based on modular components. The programmer has at his disposal the patterns and tools necessary to develop components in isolation and build component compositions.
A component is a clearly defined independent fragment of an application interface. As examples of components, you can cite entities such as buttons, sliders, windows for displaying chat messages. Understanding the features of CDD and knowing how to apply this approach to development, we can use components as the basis of applications. This, when creating software projects, gives us everything that is useful, which means applying the principles of modular programming.
')
If you look closely at what is happening now in the field of web components , you will notice that CDD is becoming a standardized approach to frontend development.
The material, which we are publishing today, is a component development guide.
Work on Bit: creating components, isolating them, reusing and collaborating on them
Simply put, component-based development is designing applications by creating loosely coupled independent blocks of code. Each of them has an interface designed to organize interaction with other parts of the system. Many components combined with each other through composition form a modular application.
For example, the use of CDD in creating React applications means that they first create the components that form the basis of the application, and then proceed to assemble from them larger parts of the application, such as entire pages and large blocks of functionality.
CDD is related to atomic design ( here is useful material on this topic) and to the approach to developing client-side parts of web projects, known as the “ micro frontend ”.
CDD helps break down the development process of a large project into smaller development processes for individual components. Each component is designed independently of the rest of the application and is created taking into account the possibility of interaction with other parts of the system. Designing each component as an independent entity gives the developer many useful features.
Eddie Osmani outlined some of the key benefits of using CDD. He designed them in a set of principles called FIRST .
These principles are:
If the development is based on components, this means that the programmer needs specialized tools. Such tools are aimed at creating components, testing them, organizing general access to them and supporting collaboration on them.
In particular, it is important to design and test components in isolation. This allows them to work in the form of independent units that can be used in the application. In addition, support for the reuse of components and the ability to share them are important. This allows one who works as part of a team on a major project not to reinvent the wheel, which, in the form of a component, has already been invented by one of the team members.
Here are some useful tools to help you organize your work on CDD style projects. In one of the following sections, we will talk about project architectures recommended for practical implementation of CDD principles.
Bit is an open source tool designed essentially to support the practical application of the CDD methodology. Here is a video about Bit. This tool helps you develop components, collaborate on them, and create web projects using them.
The thing is that with Bit means you can isolate components that are developed as part of a project. Say - within an application or library. Bit supports command line tools, it helps organize the encapsulation of components with all their files and dependencies. Bit allows you to develop and test virtual representations of encapsulated components in isolation.
This means that the component created within the application can be equipped with all its dependencies, encapsulated and turned into an entity that can be used and tested outside the application.
Further, Bit allows you to pack stand-alone, encapsulated components and organize their sharing using cloud tools . This allows teams working on projects to use all the components that are shared. The Bit community has about 50 thousand developers. Their efforts created thousands of open source components available to everyone.
Project development using encapsulated components
Thanks to the capabilities of the cloud platform, development teams can install open source components in their applications. Team members can also offer component authors ideas for improving components by doing so directly from their work environment. Bit extends Git's ability to track and synchronize component source code changes across projects. This gives developers the ability to manage component changes and updates.
Bit stores a complete tree of component dependencies. This gives the developer the opportunity to learn about how updating a component can affect dependent components, about what might be “broken” in a project when changes are made to a component. This means that thanks to Bit, the programmer has at his disposal a full-blown environment for organizing development based on components, allowing you to create components, test them and organize joint work on them and their joint use.
Cloud capabilities in CDD
Another useful feature of Bit is that this platform allows development teams not only to work with their components using a single interface, but also to use other components shared in the public domain and to interact with the authors of these components.
Interface designers, representatives of project customers, as well as programmers can, in the course of joint work on projects, use common visual tools. This bridges the gap between designers and programmers. Moreover, it should be noted that in this situation not only designers and programmers benefit, but also end users of applications that encounter fewer heterogeneities and errors. Here , here and here - a few materials on various aspects of using Bit.
StoryBook and Styleguidist are environments for quickly developing user interface elements using React. Both of these projects are great tools to accelerate component development.
StoryBook is an environment for the rapid development of UI components. It allows you to work with the library of components, view the various states of components, engage in interactive development and testing of components.
Work at StoryBook
StoryBook helps design components in isolation from the application. This helps improve the reusability of components and improves the testability of components.
Using StoryBook, you can view the components stored in the library, experiment with their properties online. Changes made to the component immediately, without reloading the page, are visualized. Here are some examples of components created in the StoryBook.
There are various plugins that can speed up the development of components using StoryBook. This allows you to reduce the time elapsed between changing the component code and the formation of its visual representation. It should be noted that StoryBook, in addition to React, also supports React Native and Vue.js.
React Styleguidist is a component development environment. This environment contains a development server that supports a hot boot. It also has an interactive style management system that displays
React styleguidist
This platform supports JavaScript ES6, Flow, and TypeScript. She can, without additional settings, work with the Create React App. Styleguidist has the ability to automatically create component documentation. This allows this system to play the role of a visual documentation portal for components that some team is working on.
If you are interested in projects like StoryBook and Styleguidist, then you might want to look at the React Live project, which is being developed by Formidable.
When working with a StoryBook, a programmer writes “stories” in JavaScript files. When working with Stuleguidist, he writes “examples” in Markdown files. While the StoryBook shows only one variation of a component at a time, Styleguidist can display several variations of different components. StoryBook is great for analyzing the various states of components, and Styleguidist is great for generating component documentation and demonstrating component capabilities.
Work in the style of CDD means that when developing applications, they primarily create components. Moreover, such components should be as independent of each other as possible. This means that the developer does not just create a “set of components”. He also implements the so-called design system of user interface components.
Components can be created both within the framework of the application itself (that is, in the same project, repositories), and in the format of a separate project (repository) - as a library of components.
Tools like Bit allow you to isolate and encapsulate components. This gives the developer ample opportunity to create, test, reuse components, and allows them to be finalized anywhere - no matter where they were created.
If we say that the use of CDD provides for the development of components in the form of the first step of working on a project, then this also implies that the components tend to make them suitable for repeated use. This allows you to apply them when creating various applications. Therefore, the developer needs to find out exactly how he needs to do in order to create such components. There is nothing worse than spending six months to create a library , which, in the end, no one will use. Unfortunately, this happens with many teams.
I’ll be honest with you: Git repositories were not conceived taking into account the possibility of storing atomic components code in them, which are planned to be shared in various projects. To solve this problem, package managers are not suitable. Both were created, which is understandable, to support code repositories. Components are not repositories.
Component sharing in various projects
That is why, if you need to take a component from one application and use it in another application, you need to create a new repository. In order to save yourself from the unnecessary work of creating a separate repository for each such component, most teams create one shared repository designed to store 20-30 components.
When using a tool like Bit, the component library as such does not need to. Such tools allow you to download a component from the application to the cloud and implement this component in other projects. If we compare this scheme of work with traditional repositories, then we can say that this is something like comparing a music CD and Spotify. True, if you are close to the idea of ​​developing and using component libraries - the capabilities of platforms such as Bit and StoryBook will allow you to work with libraries.
When designing a library, you need to make several key decisions. Below will be considered some important principles that will help you with this. The main point of these principles is that your task is to create independent components. The remaining stages of work on the project resemble the assembly of the Lego constructor. If the principle of developing independent components is not respected, then one day you may run into trouble. Troubles will begin when someone needs something different from what is in the library. As a matter of fact, when this happens, the teams stop using component libraries.
Suppose you decide to create a component library. If so - we offer you some tips that will help you with this.
Remember that a library is just a repository that exists in order to facilitate the sharing of components in various projects. Libraries do not scale very well, the code in them becomes obsolete, they suffer from various problems. It might be better to simply provide direct access to the components intended for sharing, using some kind of cloud platform.
Teams that use the CDD principle benefit from accelerated development, increased reusability of the code, improved TDD and a consistent design system interface.
Programmers can write code with access to already written components and work together to make changes to the components. The development of new features or applications comes down to customizing and expanding the basic components. This, in addition, helps prevent errors that are found only in production.
Sharing code means, among other things, reducing the amount of code that needs to be supported. This allows programmers to focus on creating something new. When applications are developed based on components, this standardizes the work due to the fact that everyone uses a single base of building blocks of applications. The component approach also contributes to work flexibility.
Some teams report that their workflows are up to 60% faster thanks to the use of modular components based on design systems implemented as sets of React components. Some organizations have found that through the introduction of CDDs, they can remove approximately 30% of the code from their codebases.
Companies such as Uber, Airbnb, Shopify and others are introducing a component approach.
Personally, I am not surprised that the use of CDD improves the efficiency of software development. According to Brad Frost, author of the book on atomic design, modularity and composition are the most important concepts in biology, economics, and in many other areas. Modularity in application to software development gives speed, reliability, ease of development. It promotes reuse of entities, improves testability and extensibility of the code. Modularity gives the developer the ability to use composition when creating complex systems. All this very well affects the process and the results of application development.
Dear readers! Do you use the CDD methodology when working on your projects?
Nowadays, the application of the principle of modularity in software design has taken a new form, embodied in the components. This is Component Driven Development (CDD). Modern libraries and frameworks for developing user interfaces, such as React , Vue, and Angular , as well as CDD-oriented tools like Bit , allow you to create applications based on modular components. The programmer has at his disposal the patterns and tools necessary to develop components in isolation and build component compositions.
A component is a clearly defined independent fragment of an application interface. As examples of components, you can cite entities such as buttons, sliders, windows for displaying chat messages. Understanding the features of CDD and knowing how to apply this approach to development, we can use components as the basis of applications. This, when creating software projects, gives us everything that is useful, which means applying the principles of modular programming.
')
If you look closely at what is happening now in the field of web components , you will notice that CDD is becoming a standardized approach to frontend development.
The material, which we are publishing today, is a component development guide.
CDD in user interface development
Work on Bit: creating components, isolating them, reusing and collaborating on them
Simply put, component-based development is designing applications by creating loosely coupled independent blocks of code. Each of them has an interface designed to organize interaction with other parts of the system. Many components combined with each other through composition form a modular application.
For example, the use of CDD in creating React applications means that they first create the components that form the basis of the application, and then proceed to assemble from them larger parts of the application, such as entire pages and large blocks of functionality.
CDD is related to atomic design ( here is useful material on this topic) and to the approach to developing client-side parts of web projects, known as the “ micro frontend ”.
CDD helps break down the development process of a large project into smaller development processes for individual components. Each component is designed independently of the rest of the application and is created taking into account the possibility of interaction with other parts of the system. Designing each component as an independent entity gives the developer many useful features.
Eddie Osmani outlined some of the key benefits of using CDD. He designed them in a set of principles called FIRST .
These principles are:
- Acceleration of development (Faster development). The fact that the efforts of developers are aimed at creating separate components allows creating modular parts of the application with highly specialized APIs. This means that components can, on the one hand, be developed quickly, and on the other, that it is easier to develop them to the level of quality required by the project when they are developed.
- Simplification of support (Simpler maintenance). When you need to modify or update a part of an application, you can expand or update a certain component rather than refactoring a large part of the application. This can be compared with a medical procedure, with an operation on a separate organ, replacing an operation that involves intervention in almost all parts of the body.
- Better code reuse capabilities. Through the use of the principle of separation of responsibilities, components, during the creation of a finished application from them, can be reused or expanded. This is much better than the need to rewrite them again and again ( here is the material on this topic).
- Improving the ability to apply the TDD (Better TDD) methodology. During the development of modular components, it is much easier than using other approaches to implement unit tests aimed at verifying the narrow functionality of a component. As a result, it turns out that it is easier to test large systems assembled from components. The fact is that when using a modular approach, it is easier for a developer to understand what exactly this or that part of the system is responsible for.
- Shortening learning curves (Shorter learning curves). When a developer has to deal with a new project for him, it turns out that it is much easier to understand the essence and structure of individual components than to delve into the intricacies of the entire project.
- Improving the capabilities of system modeling (Better modeling of the system). When the system is created from modular components, it becomes easier for the developer to understand the general device of the system, understand it and learn how to influence it.
CDD Tools
If the development is based on components, this means that the programmer needs specialized tools. Such tools are aimed at creating components, testing them, organizing general access to them and supporting collaboration on them.
In particular, it is important to design and test components in isolation. This allows them to work in the form of independent units that can be used in the application. In addition, support for the reuse of components and the ability to share them are important. This allows one who works as part of a team on a major project not to reinvent the wheel, which, in the form of a component, has already been invented by one of the team members.
Here are some useful tools to help you organize your work on CDD style projects. In one of the following sections, we will talk about project architectures recommended for practical implementation of CDD principles.
â–ŤBit: individual and team development of components
Bit is an open source tool designed essentially to support the practical application of the CDD methodology. Here is a video about Bit. This tool helps you develop components, collaborate on them, and create web projects using them.
The thing is that with Bit means you can isolate components that are developed as part of a project. Say - within an application or library. Bit supports command line tools, it helps organize the encapsulation of components with all their files and dependencies. Bit allows you to develop and test virtual representations of encapsulated components in isolation.
This means that the component created within the application can be equipped with all its dependencies, encapsulated and turned into an entity that can be used and tested outside the application.
Further, Bit allows you to pack stand-alone, encapsulated components and organize their sharing using cloud tools . This allows teams working on projects to use all the components that are shared. The Bit community has about 50 thousand developers. Their efforts created thousands of open source components available to everyone.
Project development using encapsulated components
Thanks to the capabilities of the cloud platform, development teams can install open source components in their applications. Team members can also offer component authors ideas for improving components by doing so directly from their work environment. Bit extends Git's ability to track and synchronize component source code changes across projects. This gives developers the ability to manage component changes and updates.
Bit stores a complete tree of component dependencies. This gives the developer the opportunity to learn about how updating a component can affect dependent components, about what might be “broken” in a project when changes are made to a component. This means that thanks to Bit, the programmer has at his disposal a full-blown environment for organizing development based on components, allowing you to create components, test them and organize joint work on them and their joint use.
Cloud capabilities in CDD
Another useful feature of Bit is that this platform allows development teams not only to work with their components using a single interface, but also to use other components shared in the public domain and to interact with the authors of these components.
Interface designers, representatives of project customers, as well as programmers can, in the course of joint work on projects, use common visual tools. This bridges the gap between designers and programmers. Moreover, it should be noted that in this situation not only designers and programmers benefit, but also end users of applications that encounter fewer heterogeneities and errors. Here , here and here - a few materials on various aspects of using Bit.
â–ŤDevelopment and research of UI components: StoryBook and Styleguidist
StoryBook and Styleguidist are environments for quickly developing user interface elements using React. Both of these projects are great tools to accelerate component development.
Storybook
StoryBook is an environment for the rapid development of UI components. It allows you to work with the library of components, view the various states of components, engage in interactive development and testing of components.
Work at StoryBook
StoryBook helps design components in isolation from the application. This helps improve the reusability of components and improves the testability of components.
Using StoryBook, you can view the components stored in the library, experiment with their properties online. Changes made to the component immediately, without reloading the page, are visualized. Here are some examples of components created in the StoryBook.
There are various plugins that can speed up the development of components using StoryBook. This allows you to reduce the time elapsed between changing the component code and the formation of its visual representation. It should be noted that StoryBook, in addition to React, also supports React Native and Vue.js.
React styleguidist
React Styleguidist is a component development environment. This environment contains a development server that supports a hot boot. It also has an interactive style management system that displays
propTypes components and provides the developer with editable examples of the use of components based on .md files.React styleguidist
This platform supports JavaScript ES6, Flow, and TypeScript. She can, without additional settings, work with the Create React App. Styleguidist has the ability to automatically create component documentation. This allows this system to play the role of a visual documentation portal for components that some team is working on.
If you are interested in projects like StoryBook and Styleguidist, then you might want to look at the React Live project, which is being developed by Formidable.
Difference between StoryBook and Styleguidist
When working with a StoryBook, a programmer writes “stories” in JavaScript files. When working with Stuleguidist, he writes “examples” in Markdown files. While the StoryBook shows only one variation of a component at a time, Styleguidist can display several variations of different components. StoryBook is great for analyzing the various states of components, and Styleguidist is great for generating component documentation and demonstrating component capabilities.
Architectural Decisions Used Using the CDD Methodology
Work in the style of CDD means that when developing applications, they primarily create components. Moreover, such components should be as independent of each other as possible. This means that the developer does not just create a “set of components”. He also implements the so-called design system of user interface components.
Components can be created both within the framework of the application itself (that is, in the same project, repositories), and in the format of a separate project (repository) - as a library of components.
Tools like Bit allow you to isolate and encapsulate components. This gives the developer ample opportunity to create, test, reuse components, and allows them to be finalized anywhere - no matter where they were created.
If we say that the use of CDD provides for the development of components in the form of the first step of working on a project, then this also implies that the components tend to make them suitable for repeated use. This allows you to apply them when creating various applications. Therefore, the developer needs to find out exactly how he needs to do in order to create such components. There is nothing worse than spending six months to create a library , which, in the end, no one will use. Unfortunately, this happens with many teams.
Why create a component library?
I’ll be honest with you: Git repositories were not conceived taking into account the possibility of storing atomic components code in them, which are planned to be shared in various projects. To solve this problem, package managers are not suitable. Both were created, which is understandable, to support code repositories. Components are not repositories.
Component sharing in various projects
That is why, if you need to take a component from one application and use it in another application, you need to create a new repository. In order to save yourself from the unnecessary work of creating a separate repository for each such component, most teams create one shared repository designed to store 20-30 components.
When using a tool like Bit, the component library as such does not need to. Such tools allow you to download a component from the application to the cloud and implement this component in other projects. If we compare this scheme of work with traditional repositories, then we can say that this is something like comparing a music CD and Spotify. True, if you are close to the idea of ​​developing and using component libraries - the capabilities of platforms such as Bit and StoryBook will allow you to work with libraries.
When designing a library, you need to make several key decisions. Below will be considered some important principles that will help you with this. The main point of these principles is that your task is to create independent components. The remaining stages of work on the project resemble the assembly of the Lego constructor. If the principle of developing independent components is not respected, then one day you may run into trouble. Troubles will begin when someone needs something different from what is in the library. As a matter of fact, when this happens, the teams stop using component libraries.
Suppose you decide to create a component library. If so - we offer you some tips that will help you with this.
7 principles for developing quality CDD-oriented libraries
- Standards What development standards do you adhere to when creating your library? Where are the components located? Where are the tests located? What about the styles? What technology stack are you using? For example - do you plan to use TypeScript? How are the components divided? Does the “Table” component, for example, consist of “Rows” and “Cells”? Does the panel with tabs consist of separate tabs (can the same questions be asked in relation to other similar entities)? I suppose you already understood the meaning of this recommendation. It is also very important to include designers in the process of forming standards. This will ensure that the library is flexible enough and will meet the design requirements that may appear in the future.
- Stylization. How do you plan to style the components? Will you associate the corresponding CSS code with each component? If so, what happens when a designer needs to change something just for a separate application that uses a component? Is it possible to use libraries that implement CSS in JS technology to improve the separation of components from styles? Maybe it's worth looking for some other approach to styling? For example, using Bit, you can highlight topics as separate components. Such topics can be applied to components that implement some kind of logic. This allows you to create applications in which design and logic are combined exactly as the developer needs. Here is an example of the extreme flexibility of systems built using the principle of modularity.
- Testing. How are you going to test the components included in the library? Using Jest and Enzyme? The selection of a good combination of component testing tools must be approached with all responsibility. This will allow such tools to help you implement the CDD methodology. Bad choice of tools will interfere with the work. Unit tests are good. But they should check the functional APIs of the components, not the details of their implementation. Integration and end-to-end tests are just as important as unit tests. The TDD methodology works well when applied to projects that use CDD.
- Code assembly process. The code needs to be compiled. How are you going to organize the code building process for your library? How will the releases be implemented? Are you planning to simply copy the code from the application and paste it into the library (probably modifying it a bit)? Are you going to define assembly configurations for each component (Lerna) and apply the appropriate mechanisms to the code before publishing it? Do you plan to use, say, the already mentioned Bit more than once in order to customize the build processes that apply to all (or to individual) components? If you complicate the assembly process too much, it will become harder to develop, the modularity of the project will deteriorate. The learning curve required to participate in the development will become too steep.
- Code management. Who owns the library? In fairly large organizations, there are often teams of front-end developers and, sometimes, architects. They are creating a product called the "shared library." Other front-end development teams create applications using similar libraries. With this interaction scheme, it is very important to use a system that allows you to conveniently find the necessary components (Bit, Storybook). More importantly, perhaps, is the mechanism by which component users can propose component improvements. If there are no such mechanisms in the organization, then the component user teams will not want to associate their applications with the library and wait for their PR to be accepted, which they may well not wait for. No need to force programmers to do anything. It is necessary to establish healthy cooperation. If you do not strive for this, no one will use the library. Programmers will simply copy and paste the code, and no one will do anything about it. Moreover, this will be your mistake. If you work in a small team, clearly determine who is managing the code. Even if no one deals with the code base all the time, select a few specialists who will support this code. The rest will do PR - just like it does on GitHub.
- Finding components. The library will not bring much benefit if programmers cannot find the components they need, cannot learn how these components work, and cannot use them in their code. Bit has the built-in capabilities that help developers find components. In addition to this platform (or instead of it), you can use the capabilities of StoryBook or some kind of own solution. Codesandbox platform can provide some benefit in resolving issues related to selecting components and working with documentation for them.
- Organization of collaboration on components. What happens when a developer (possibly from another team, or even from another country) needs to change something related to a component from your library? Does he need to go deeper into creating a PR for your library, and, crossing his fingers, wait for the results. For many developers, this is too complicated, they will not do this even if you try to somehow influence them. It will be much better if you use a certain platform that simplifies collaboration on projects.
Remember that a library is just a repository that exists in order to facilitate the sharing of components in various projects. Libraries do not scale very well, the code in them becomes obsolete, they suffer from various problems. It might be better to simply provide direct access to the components intended for sharing, using some kind of cloud platform.
Benefits of the CDD Team
Teams that use the CDD principle benefit from accelerated development, increased reusability of the code, improved TDD and a consistent design system interface.
Programmers can write code with access to already written components and work together to make changes to the components. The development of new features or applications comes down to customizing and expanding the basic components. This, in addition, helps prevent errors that are found only in production.
Sharing code means, among other things, reducing the amount of code that needs to be supported. This allows programmers to focus on creating something new. When applications are developed based on components, this standardizes the work due to the fact that everyone uses a single base of building blocks of applications. The component approach also contributes to work flexibility.
Some teams report that their workflows are up to 60% faster thanks to the use of modular components based on design systems implemented as sets of React components. Some organizations have found that through the introduction of CDDs, they can remove approximately 30% of the code from their codebases.
Companies such as Uber, Airbnb, Shopify and others are introducing a component approach.
Summary
Personally, I am not surprised that the use of CDD improves the efficiency of software development. According to Brad Frost, author of the book on atomic design, modularity and composition are the most important concepts in biology, economics, and in many other areas. Modularity in application to software development gives speed, reliability, ease of development. It promotes reuse of entities, improves testability and extensibility of the code. Modularity gives the developer the ability to use composition when creating complex systems. All this very well affects the process and the results of application development.
Dear readers! Do you use the CDD methodology when working on your projects?
Source: https://habr.com/ru/post/461661/
All Articles