cutting edge:
Abstraction is a big question. In the front-end mv framework, the concept of componentization is the main concept. Often consider abstracting to the component level for reuse. Reasonable abstraction can improve efficiency and reduce the degree of coupling of business logic views. Unreasonable abstraction will increase the complexity of the code.
problems encountered
Reasonable abstraction is difficult, and it takes constant thinking to achieve the most suitable abstraction. In the b+ project, some problems were encountered.
1. Some components, ui and logic can be reused. The ui is abstract, and the corresponding logic is not drawn. In this way, it is suitable to reuse this component, and the code of the logic part is not reused, so you have to copy and paste another copy.
2. For some components, ui can be reused, but logic cannot be reused. Abstracted into a component, the ui is reused, but the business logic has to be configured with parameters, resulting in an infinite increase in switch cases.
Abstract thinking as I understand it:
1. Basic abstraction, applicable to all projects.
First, abstract from the functional latitude. Abstract some ui components with a specific function. For example, buttons, date pickers, lists, etc., these are modules with specific functions, which can be abstracted as a component module individually. The end result of this abstraction is that a whole set of ui libraries can be abstracted. For example elemntui, antd etc. This layer is
2. The abstraction of business modules is judged according to business logic.
In a specific project, in addition to abstracting the most basic layer from functional modules. It is also possible to abstract a layer of business modules from the latitude of business logic. The basis for judging abstraction is that the ui is consistent and the business logic is consistent (the main judgment condition). A negative example, if there are three modules, the list of each module is similar, but the business logic of the three modules is inconsistent, for example, the interface adjustment is different. In this case, although the UI is very similar, but the logic is different, it is not suitable for abstract components to be reused. A positive example, if there are multiple betting buttons, the UI is slightly different, but the logic implemented is all betting. Then it is suitable for abstraction.
Summarize:
Functional logic cases are limited, all are configurable and abstract. The situation of business logic may be infinite, and it is not suitable for configuration to achieve abstraction. Therefore, the necessary condition for abstraction in business is that business logic must be consistent. If the ui is also consistent, it can be abstracted into components. If the UI is inconsistent, abstract the logic part separately (minxins can be used to introduce common logic in vue).