preface

As a front-end attacker, component packaging should be something that every front-end ER has done, and component reuse is an integral part of team collaboration.

I work for three years can be said to read countless components (blowing 🐂), the last half year is also completed the whole team component library construction, on how to package a good component has certain experience, if the following places said wrong, I hope the audience grandpa actively correct ha.

Next, let’s get down to business: How do you package a good component?

The whole process

Without further ado, above:

I’ve divided component development into three phases: pre-coding, coding, and post-coding.

Stage 1: preparation before coding

The normal development process of front-end ER in a requirement iteration process: clearly understand the requirements given by the product manager -> divide the requirements into modules -> disassemble sub-tasks -> split components.

So what do you do after you split the components?

Business requirement analysis

I believe that some students who are not very rich in work experience have started coding directly, but they lack a very important step: business requirements analysis.

In fact, only by conducting a complete requirement analysis of the components to be written, can we have a deeper understanding of the application scenarios of the components and do a good job in advance of the possible changes in the future.

Although it is not entirely up to us to decide how the future will change, we believe that if we can make a good design in advance of the large probability of changes in the future, it will help us to better design components. I personally hate it when a component is written and changed back and forth, which greatly increases bug rates and refactoring risks.

Business abstract

So how do we verify that the requirements are clearly analyzed? Try a proper business abstraction of the component you’re writing, which could be a brain map with clear logic.

Business abstraction is a good test of the developer’s understanding of requirements. Which piece of logic should be removed for reuse, what is the core data flow of components, how to ensure the stratification and reuse of code, how to reduce the complexity of components and so on, are all problems that need to be considered.

In my opinion, the core premise of business abstraction is to have a thorough understanding of business requirements, and then follow certain development principles, such as single principle, open and closed principle, etc.

If you are developing some pure UI components, in the process of abstraction, you also need to combine your own company’s UI specifications, in line with the overall UI design.

Using API definitions

If you can understand the first two steps clearly, this step I believe you can easily.

Many new students in the process of developing components, often only after the completion of development to determine the component exposed API. This is the wrong approach. The right approach is to start at the end of the day, setting specific apis before actual coding so that goals are clear during development.

How is the API defined? This requires developers to put themselves in the shoes of their users. Your co-worker is the user, and in turn you are the first user.

How useful is this component for users? Is there a similar component on the market? Is the component passing too many parameters? How to ensure future expansibility, do you reserve some fields? And so on these issues, all need to be taken into account. Of course, there is a certain amount of experience involved, and I’m sure no one can develop a particularly perfect component right out of the box.

Stage two: coding

The process of coding was the happiest for me 😄, because after we sorted out the content of the first stage, coding was pure manual work ~.

Code design

Code design is a very important step for developing complex components, and it is also important for personal development.

I’ve seen a lot of people take a request, simple or complex, and do it like a tiger. Then, when I was reviewing the code, the readability of the code was very poor. I asked how the code was designed, but there was no design. I almost burst out blood.

I don’t want to go into too much detail on code design here. I recommend reading Javascript Design Patterns and Development Practices, or taking a look at my React Best Practices article.

coding

Coding is a chore, but I personally enjoy it.

If there are any difficulties in a component, I believe they can be identified during the code design phase. If it is not recognized in time, it is time to reflect on whether the code design is too granular, missing some key technologies. Or is it due to lack of knowledge in some aspects?

This time also need not panic, timely upward feedback exposure risk points (this is very important), Baidu is good.

The third stage: after coding

Coding doesn’t mean you’re done, and good self-testing habits will impress your testers.

Self test + test case

After the component coding is complete, we should try and output a self-test use case from the standpoint of testing. There is no conflict between self-test cases and test cases. Self-test cases developed can better help testers improve test cases.

Self-testing use cases can not only quickly help us find some defects, but also allow us to re-examine whether the written component conforms to the previous design. Are there any business scenarios that deviate from reality? Are there any missing points and so on.

For those of you who haven’t written self-test cases, I recommend reading this article: How to Write Good Test Cases.

If time permits, it is best to add some unit tests to ensure the quality of the code in the component.

Written document

Why document? Component documentation is a quick way to help others or improve your own productivity without having to read the code every time you reuse a component.

The documentation section can be customized according to the actual situation, and it can also be written in readme or component comments.

Here’s a handy component documentation library for amway: StoryBook. It’s basically out of the box, and I use it myself to document our team component library.

release

Finally, the component library NPM is published.

For document publishing, the component library needs to be packaged and published to the specified CDN.

conclusion

The whole component development process is explained, the core is the business abstraction and API definition. Business abstraction is a link that tests the developer’s understanding of requirements as well as a clear division of component logic. API definitions are more about taking the user’s point of view, looking at things from the user’s point of view, and managing the overall code rhythm by starting from the beginning.

Finally, I hope this article can help you 😁, if there is a mistake in the article, I hope we actively correct ~

Please give me a thumbs up, thanks