Talk about the core elements of frame design

The introduction

Nowadays, vue. js, React and other excellent open source frameworks have become popular in the field of Web front-end. Mastering a framework has become a necessary technical literacy for every practitioner in the field of Web front-end. In the process of learning the framework, did you ever think about how the framework was designed? Why is it designed this way? Think deeply rise, want to design an excellent frame to want to want to compare imagine medium complex a lot of, not be to say to complete relevant function completely development success, “be able to use” just be the most basic requirement, “be able to use” just have core competitiveness! This article mainly takes vue.js as an example, around the design of an excellent framework to talk about all aspects to be considered.

Improve user development experience

Having a good development experience is one of the important indicators to measure whether a framework is good enough, and it is also the cornerstone of whether a framework can be rapidly promoted and popularized. Just like in our daily life, there is no shortage of dun people for things that really work, and some anti-human designs tend to attract people’s uncontrollable malice.

Take vue.js for a quick example:

When we create a vue.js application instance and try to mount it to a non-existent DOM node not-exist, we get a warning message from vue.js like this:

This information clearly tells us that the mount failed and explains why so that we can quickly and clearly locate the problem and correct it. Imagine that if vue.js did nothing internally to handle error messages, we would probably get JavaScript level error messages like this:

What a maddening scenario this would be, especially devastating for novice programmers with little development experience, like downloading VScode and not allowing them to use plug-ins, I… Why download it??

In addition to providing necessary warnings, there are many ways to improve the user experience, such as visualizing the output of reactive data types such as RefImpl under certain conditions, which I won’t go into here. In short, the framework should be designed to minimize the cost of learning for beginners, and those anti-human designs are not necessary.

Controls the volume of framework code

The size of a framework is also one of the criteria for judging whether a framework is good or not. After all, the same functionality, of course, with less code and less volume, ends up taking less time for the browser to load resources.

So, how to reduce the project packaging volume? I think anyone who has actually developed a project should know that a project is divided into development and production, and that project dependencies are divided into development and production dependencies. This is a general way to minimize the size of the project code. In project development, for example, clear and accurate error message is indispensable, but by the project in the deployment of production, an error prompt relevant code can be out of the midst of the project to reduce the code package volume, after all, a project launched after the research and development of the most basic test, at least no one mistake the development of times to stop running the code also deployment of online?

In vue.js, the build tool used is rollup.js, see the following vue.js source code:

This is a vue.js error, in which the __DEV__ constant is actually predefined by the rollup.js plug-in: when the project is in development, the value is true, and an error message is printed; If the project is in production and the value is false, no error message is displayed. It is through these modest configurations that the framework reduces the size of the code when the project is formally packaged and deployed.

The framework should be goodTree-Shaking

Tree-shaking here means eliminating code that will never be executed, eliminating dead Code. There is no need to go into detail here as to which code will not be executed. Let me just say a special case: in Vue.js, everything that doesn’t have side effects is tree-shaking, vue.js doesn’t care what the code wants to do! (Side effects: A call to a function has side effects when it has external effects, such as modifying global variables)

The following code:

Although the function foo is imported and called in the input.js file, in the official package of vue.js, this part of the output is empty because foo has no side effects and is not included in the project code.

/*#__PURE__*/ What? This is essentially a tag that assures the packager rollup.js that calls to foo will not have side effects, so you can tree-shaking happily. Why is this “declaration” necessary? JavaScript is a dynamic language, so it’s hard to statically analyze what code is dead code, and if you know anything about vue.js responsiveness, you know that if OBj is a proxy object, Foo’s reading of obj triggers a get of the proxy object, and in get, there is a high possibility of side effects, such as firing track

What build artifacts should the framework produce

An excellent framework should choose the most suitable product form for output according to different usage scenarios, which can be roughly divided into the following categories according to the requirements

use<script>Tags are introduced and used directly

Example code is as follows:

In this case, vue.js outputs a resource in IIFE format. (The full name of IIFE is the Immediately Invoked Function Expression, which is also described in JavaScript You Didn’t Know, Volume 1) in fact, Vue,global.js is an IIFE resource, and the global variable vue is available when imported directly into the file using the

tag.

use<script type="module">Import ESM format resources directly

Example code is as follows:

It was not supported in the past, but as the technology has evolved and major browser versions have been updated, native ESM support is now fine. Of course, in order to output ESM resources properly, rollup.js output format needs to be set to: format: ‘ESM’.

Pass in Node.jsrequireStatement import resource

Example code is as follows:

This support for importing resources is necessary in server-side rendering. After all, in server-side rendering, the Vue. Js code is no longer running in the browser environment, but in the Node.js environment, where the resource module format is CommonJS, or CJS for short. In order to enter CJS module resources properly, change the rollup.js configuration to format: ‘CJS’.

Characteristics of the switch

The existence of characteristic switches brings flexibility to frame design. A feature switch allows users to turn off unwanted features in a project, reducing the size of the final code using a tree-shaking mechanism. You can also use property switches to arbitrarily add new features to the framework and choose whether to use them.

What I think is probably the most iconic of these is the fact that the option API in Vue.js 3 co-exists with the composite API. If you only want to use the composite API, you can turn off the option API with the feature switch, so that the part of the option API in Vue.js 3 is not included in the final code, and vice versa.

Error handling

Error handling is a very important part of the framework development process. The quality of this mechanism directly determines the robustness of the user application and the mental burden of handling errors during the development process.

Assuming that the framework does not have error handling, the user experience will be very bad. In this case, if the user-provided callback fails, the user needs to execute a try… Catch, one or two are fine, but if there are dozens or hundreds of similar functions that need to be handled, why add error handlers one by one? Well, I might as well go into fish farming. Why would I suffer this? (I am a biology major, last semester also in the field practice to catch dragonflies, catch crabs, feel that learning computer related knowledge is not enough time, tears)

Fortunately, frameworks such as vue.js provide error handling mechanisms, based on the following principles:

For more details on error handling, search for the callWithErrorHandling function in vue.js’s source code

Good TypreScript type support

Today, TypeScript stands on the shoulders of the giant JavaScript and is gaining popularity among developers and development teams with richer language features and functions. Many of the star projects developed in JavaScript at GitHub have joined the TypeScript rewrite wave. Support for TS types is becoming an important indicator of how good a framework is.

So how do you measure the level of support a framework has for TS types? If you think that just because you use the TS authoring framework means that you are friendly to type TS, you are wrong. When writing a large framework, it is not easy to achieve perfect TS type support, and TS takes a lot of effort to do type derivation compared to JS, which is the key to TS type support.

In my opinion, a TS file without type derivation is just a suffix for a JS file, please JS less touch porcelain TS, thank you!

The statement

• This article belongs to a class of reading notes, is the author read huo Chunyang’s new work “Vue. Js design and implementation” on the way, with the book content as the blueprint, supplemented by personal micro Taoist “fill in” to complete, recommend book reading, there will be harvest
• Welcome to The big man, Axe Zheng
• Day more