Write an article summarizing the conclusion of the project for some time. When I first entered the project team, I saw 3000 lines of VUE files and almost held them out. But the last programmer had left, so I had to fill in the holes by myself. In the process of reconstructing the project, I also found some other problems, which were summarized and shared in the group sharing meeting. This time, the summary was recorded in an article.

Building vUE components in the same way as building blocks builds our project

In a project, we generally divide components into business components and functional components, which can also be called view components and container components. Also known as stateless components and UI components in React. Component division is clear, for code maintainability and readability has certain convenience. The division is as follows:

Component design considerations, divide and conquer

World affairs, long separated must be united, united must be divided. Components, too, have gone from being written together to being clearly divided. The idea of divide and conquer also allows us to focus more on the main feature implementation for easy extension and reuse. In the design of components, consider the following:

Strong scalability

Extensibility is the first thing to consider. Failure to extend means that your code is dead and you lose your flexibility

The method function in the component is separated, easy to reuse, high applicability.

Use method definitions whenever possible and avoid template expressions, which are not reusable

Documentation is clear and detailed

After all, written components are for people to use, incomplete documentation for others to use, certainly can not teach others how to use it, so a detailed use of a component is a must.

Appropriate granularity, moderate abstraction

This is a question of experience, how to measure whether the granularity is appropriate is actually a question of degree, everyone has their own opinion, but try to ensure that a component to complete the function is a single, rather than a combination of multiple functions.

Keep functions as simple as possible and lines of code moderate

This point is similar to the above granularity, and can also be measured by the number of lines of code. If the general component is removed properly, it will never exceed 1000 lines. If the code is too much, it indicates that the component is not properly divided, and the removal is not perfect, and it needs to be redesigned.

Use the UI when necessary (design is not just about looking good, it’s about using. — Steve Jobs

Some components are designed too ugly, programmer’s vision and the vision of a professional designer there is a certain gap, so if you can ask a professional designer to design the following UI interface, to a certain extent can attract others.

Component design reference points

Atomization of props between components

When the parent component passes values through the props property, it specifies the data type as much as possible and uses the raw type of data. Try to use only JavaScript primitive types (strings, numbers, booleans) and functions. Try to avoid complex objects.

The following points should be noted:

  • Ensure that component apis are clear and intuitive

  • Better understand the meaning and function of each prop

  • Passing overly complex objects makes it unclear which properties or methods are used by custom components, making code difficult to refactor and maintain.

  • Make components usable (defensive programming)

Example:

Smart use of slot extension components

A lot of good components can be designed with slot.

Reuse mixins properly

Mixins encapsulate reusable code and avoid duplication. Mixins can be used if multiple components share the same functionality. Mixins allow you to focus on individual component tasks and abstract generic code. This helps maintain the application better.

Just-in-time modularization

Before deciding to split into components, ask yourself the following questions:

  • Is there enough page structure/logic to warrant it?

  • Code duplication (or possible duplication)?

  • Will it reduce the number of templates to write on?

  • Will performance be affected?

  • Do you have problems testing all parts of your code?

  • Do you have a specific reason?

  • Do the benefits outweigh the costs? After you have identified the above questions, decide whether to remove the components and believe that you have a clear answer.

How do you design components? When are components removed? How to pull out a suitable component? Are some design principles plus practical experience under the interaction of judgment, theoretical guidance, practical judgment.

End with a chicken soup passage:

At the end of the day, while your immediate responsibility may be to “write code,” you shouldn’t lose sight of your ultimate goal, which is to build something. Create the product. Always remember to find a balance in order to produce something you can be proud of and help others, even if it’s not technically perfect. Unfortunately, staring at the code in front of you for 8 hours a day for a week can lead to a narrower perspective, when you need to step back and make sure you don’t lose the forest for one tree.

Thank you for your reading, hope to give a thumbs-up after reading oh, thank you! 🙏 🙏 🙏