1. Why do you need a front-end framework?
Regarding the front-end framework, it has developed rapidly in recent years. The earliest front-end development is based on page html. HTML is used to display page elements, css is used to add some custom styles to elements, and js is used to add some pages to pages. For dynamic effects and operations, the front-end of this method cannot be regarded as a terminal in a strict sense, let alone an application, so at this time, only some static files are placed in the back-end project in the front-end. With the development of the Internet, the requirements for the front-end are becoming more and more complex, and it is difficult to carry our requirements through several static html pages, and the most critical problem is the problem of efficiency and performance, so the front-end appears The concept of engineering has transformed a page into an application. Obviously, the front-end method of placing all elements in a single html file is obviously no longer applicable. At this time, componentization and modularization appeared. Various frameworks have emerged to meet the requirements of encapsulation and so on.
2. Modular componentization method
Nowadays, the componentization method in front-end frameworks has gradually become the mainstream method. In these modular frameworks, the concept of component tree has emerged. For example, frameworks such as Vue and react have relatively complete componentization concepts. A component can be an abstraction of a functional module, an encapsulation of public operations, or even a function. For example, the concept of component function in react is more obvious.
Components can be classified in practical applications:
1. Pure display components: that is, the data is passed in to help you render the DOM
2. Access component: This component can be said to be in the upper layer of the display component. It will interact with the data layer and upload data down to the display component.
3. Interactive components: It is the encapsulation and enhancement of form components, such as the form components in elementUI, which are more complex and highly reusable.
4. Functional components: such as the router component in Vue, it does not render any DOM, but acts as an abstraction mechanism
3. Declarative rendering mechanism
The concept of templates in Vue allows less logic to be placed in the view, and templates with less logic can better reflect visual thinking. The most important rendering now is the declarative rendering method, which uses data as the driver to update the view. In this method, the data and the view are actually independent of each other. The two are more like establishing a mapping relationship and responding to changes in the data state. To put it bluntly, there is no need to manipulate the DOM. In the beginning, it was a named way to directly manipulate the DOM, that is, to obtain the DOM object through various js functions and then manipulate it. This way does not have an abstract way of thinking, what you see is what you get, you need Whichever operation is performed directly, this method is very simple and rude, giving people the feeling that it is very heavy and violent, and for some slightly larger applications, it will appear that the hierarchical structure is chaotic and difficult to maintain. And now the mainstream declarative rendering method is much lighter, clearer and easier to maintain.
4. Change Detection Mechanism
In Vue, the data is responsive. When the data is handed over to Vue, Vue will transform it. When the data changes, Vue will detect the change. This change detection method can be mainly divided into two types, pull and push. Pull is a coarse-grained dirty checking mechanism. Here, the system actually does not know which data has changed. It needs a signal to tell the system that the data may change. At this time, the system will violently compare all the data and check Find out which data has changed. Push, on the other hand, is a fine-grained checking mechanism, which is faster and more accurate in positioning. However, the fine-grained mechanism has relatively high system overhead. For example, the memory overhead is larger than that of pull. Therefore, when choosing this detection mechanism, there is no absolute good or bad. Different scenarios, different system environments and different business requirements may have different requirements for it. So in Vue, it chooses a compromise, that is, a mixed use, push is used in components, each component is a watcher, and virtual DOM is used internally for comparison.
5. Status management
State management was first proposed by Facebook. In state management, React was gradually merged into Redux, and VueX was actually influenced by Redux to a certain extent. The essence of state management is to map from meta events to state transitions and changes, and then map to changes in DOM UI, for example, the process from when a user clicks a button to when the click event is triggered. Here, the declarative rendering method mentioned above has actually helped us solve the change mapping problem from state to UI. State management is actually to solve how to manage the process of mapping event sources to state changes, and how to separate the mapping process from view components to improve maintainability. In Vue, it embodies a paradigmatic way of thinking, data is responsive, and the framework has made declarative side effects on the data. The difficulty of maintaining variable data is that when we manually operate the data side-effect operation, manual observation will bring a certain maintenance cost. Regarding the asynchronous problem in state management, Redux leaves it to MiddleWare to do it, and VueX does it in action. Looking at the current state management solutions, there are still pain points: how to distinguish the local state of a component from the global state? Personally, I don't think there are clear boundaries.
6. Routing
The problem of routing is a problem encountered only by large single-page applications. The traditional routing idea is an intrusive way. For example, when writing an application, you must start with routing. When React and Vue, a framework that focuses on the View layer, appear, it is not difficult to find that it is completely feasible to decouple components and routing, and it is more flexible and easy to maintain and migrate. In fact, thinking about routing from components is essentially a process of mapping a URL to a component tree structure. There are some small problems in the mapping from URL to component. Should it start from the URL or from the state? For example, the implementation of some routing libraries is based on the transition between states, but in fact, the URL can also be understood as a serialized state.
The simplest route is actually a dynamic component. In fact, there are still many problems here, such as redirection, aliasing, lazy loading, and how the hook jump of the route responds to the invalid situation that the user cancels the jump and so on. Now the mainstream routing schemes are almost the same, and the principles are basically similar. The latest scheme is to use the idea of routing the component itself, which is somewhat in line with the concept of the functional component mentioned above, which can be declarative in the parent component. Render other components.
Seven, CSS scheme
There are several mainstream schemes for CSS currently applied
1. CSS and JS are completely decoupled, and maintainability is maintained by preprocessors and certain specifications. This is a more traditional way.
2. CSS Modules, still CSS, but through compilation to avoid the global conflict of various CSS class names.
3. Various CSS-in-JS schemes are more radical.
4. Vue's single-file component CSS method is a compromise solution.
In fact, when choosing a CSS solution, the first thing to do is to clarify the problem of the scene. If the application logic has been componentized, and it is a relatively complex application development, then the traditional CSS method is the first one above, and the maintainability is relatively poor, then Synonymizing components and structures is one way to reduce the burden of thinking. Cross-platform reuse We can compile static CSS PASS into cross-platform JS.
Eight, build tools
In the traditional front-end development method, there is no construction or compilation process. In the current front-end development, many development tools need to be installed. The reason is that the current Web capabilities are getting stronger and stronger, and the external needs are getting higher and higher, so we need the assistance of these tools.
The build tool actually solves the following problems:
1. Task automation.
2. Development experience and efficiency (new language features, features, syntactic sugar, etc.).
3. Deployment related requirements.
4. Compile-time optimization.
Now the more mainstream construction method is npm script+Webpack. Front-end development actually has a limitation, that is, the final code will inevitably run in the browser. This problem must be considered when we use the new features of the technology, so the construction tool chain is gradually improved.
Webpack is actually complicated, because the problems it solves are complex. It seems to be just a code packaging tool. In fact, if you think about it carefully, you will find that there are many things to do in deployment optimization. For example, the inlining of static resources in JS, how to cache different resource refresh versions, and how to code segmentation, in fact, Webpack has done a lot of tedious "front-end operation and maintenance" work for me here. Rigorous front-end engineering must go through the process of compiling and building.
9. Cross-platform
From the perspective of the front-end framework, the essence of cross-platform rendering is to decouple the rendering mechanism of the framework from the DOM when designing the framework, and does not necessarily use the virtual DOM. In fact, in essence, you only need to encapsulate the node operations when the framework is updated to achieve cross-platform. For example, VueX essentially has an adaptive rendering engine for each platform at the bottom layer. As long as the API of the node operation exposed by the rendering engine is connected with the framework runtime, the code in the framework can be rendered to the native application. .
10. Summarize
In fact, no matter what framework or technology it is, it is actually the first to find the problem, and then to have the idea and idea to solve the problem. Of course, there must be balance and trade-offs in this process. For example, why the traditional front-end development method mentioned above is no longer suitable for today's application requirements, it is because the traditional method exposes various problems, which leads to the emergence of various solutions for various front-end frameworks. No matter what technical solution it is, it actually has its bright spots and pain points. When choosing to measure a technical solution, you should think about the problem behind the technology and what it can bring to you and what you do. Help and promotion, on the one hand, can help us better understand and use these technologies, and also lay a solid foundation for the future when we encounter special circumstances in the business and need to make our own plans.
When learning a technical framework, I personally think that the most important thing is to understand the design ideas expressed or realized behind the technology, because technology is actually limited, and ideas can be derived and diverged. In fact, many technical solutions are behind them. It can be said that the ideas of the two have the same goal, and they can all find similarities. On the front-end framework, we can't stop at the level of just using the framework to write code, we should focus on componentization, design patterns, modularization, data flow, rendering mechanism, routing mechanism, construction, and code standards. effort.