Vue3 is a great new feature

  • Combined API setup
  • The global API instead acts on vue instances
  • Remove on, off, and $once instance methods (internal event-bus, confusing code organization and event flow)
  • The render function parameters are imported instead of being passed in automatically
  • Life cycle change (this article summarizes it better than the official one)

These are the features of VUE3 that I think are important and awesome. Of course, there are a lot of new features in VuE3 that don’t need to be listed, just read the official website for yourself.

The real power of VUE3 — functional programming

Let’s take a look at the common code form for vue2. X

That’s fine, but one day you need to reuse a piece of logic, and you start to get a headache, because you find a whole piece of logic scattered all over data, methods, Watch, computed… In, have to be carefully extracted one by one.

Then there’s the bigger problem of hindering you — this, this is everywhere in vue2. X (because Vue exposes property in this context). Therefore, under 2, our components are usually complete self-closing components. Reuse is usually for a complete component or some completely stateless util functions, and the logic inside the component is difficult to reuse.

If you have to reuse a piece of logic, and you don’t want to copy a new component, then the nasty thing is that you have to inject parameters into the component to control it.

Then we found that there were a lot of requirements for communication and shared state between components, and it was impossible to meet the complex requirements only by vUE’s parent-child component transmission. We started to introduce vuEX state management library, but we only solved the problem of data and state confusion superficially. It doesn’t solve the root of the problem (reuse of logic, easier use of VUE, purer components).

Let’s think about the code in VUe2, if there is a feeling that VUE is not flexible (if not, think about how to write an advanced component in VUe2).

Vue3 era

This is a piece of Botton component code that I took from the business. I carefully observe whether there is any difference. Yes, the whole component is stateless, and the core code setStep has been extracted and reused

Other components subscribe to STEP to complete logical communication. What is the significance of extracting and reusing internal logic of components? Let’s look at a piece of code that looks like this

The red box shows the logic that is being reused. We have encapsulated the business logic in three functions, so you don’t have to get into the details of the logic. This is a bit like react hooks, which I wrote specifically, including the init function below, which can be reused as wrapper functions.

Under VUe3, we can maintain related code together, the code space distance is lower, and the readability is higher.

Vue3 exposes a lot of core capabilities, such as computed, onMounted and Watch, in the form of functions, which brings me strong thoughts on the design of my current editor plug-in system.

Many people will think vue3 is like hooks, especially if you read my example above, I wrote it in the style of hooks on purpose, vue3 does not require or suggest that we use it, it just seems intuitive to me.

I heard that vuEX is no longer needed under VUE3. At present, I feel that VUEX is really not needed because we can easily extract component logic and drive business through reactive variables, and cross component communication is completed. Of course, vuEX is useful for complex models.

This is the business logic I extracted, which is roughly equivalent to store in Vuex mode.

Vue3 features not recommended

teleport

Teleport allows developers to the component from the component of normal flow, and then insert a particular location, a document of js. Body. The appendChild (). Referring to the Goto (Java) syntax that has been abandoned by many languages, I think it should be possible to restore the component tree structure through the DOM structure (where you reference a component, it should appear in its place, if you need to reference a component inside a div, insert it under the body, That means the component should not be referenced in div.) Using teleport in projects makes code less readable and creates confusion. Teleport can do this with higher-order components or good component splitting and reuse.

One of its typical applications has a popover, which is not recommended and is not completely useless, but should not be used in most scenarios.

The thinking triggered by VUE3

If you search for “benefits and benefits of Vue3 features”, the overwhelming majority of responses are performance improvement, composition API, proxy responsiveness, DIff optimization, smaller size, better TS support…

These changes are great, but will never be enough for most users to replace VuE3, nor is it the author’s ultimate goal, as they are “too small”.

I think what VUE3 brings is a change in the way you program — in a functional way.

I’ve been involved in refactoring on a number of old projects, and the most painful part was not the code’s lack of comments, poor readability, or historical baggage, but the dependencies that pulled it all together like Indian wires.

Refactoring meant I had to read the entire dependency graph, which was almost impossible to do. But just think, if buy a module only focus on their own field, just like the assembly line workshop, make iron nail workshop only accept standard iron, always output iron nails, and nothing else. After many years, I understand that this is functional programming thinking.

Without understanding this idea, it may be difficult to understand why VUe3 provides lifecycle capabilities in the form of functions, or even why VUe3 exists at all

As if object oriented has not understood, and now what is the function, in fact, no matter which mode, is the abstraction of some social form of the real world, the purpose is to reduce the cost of understanding programming thinking. Because the underlying code is imperative and hard to understand, people keep providing higher-level abstractions, so the comparisons don’t make much sense.

There are so many articles about functional programming that I just want to introduce you to a new way of thinking.

The limitations of the developer’s thinking

Let’s think about a question. Why are there a lot of technical analysis on VUE3 on the Internet? Why are there few thoughts on the purpose and origin of vuE3?

This is a common fault of technical personnel, I believe that the students who have stayed in the business line should be all leaders said such a sentence: technology is important (do not immerse yourself in technology), but also good at digging the value of demand (also want to dig the root of thinking), in fact, want you to see the essence through the phenomenon.

From a large product to a small function, many people can analyze its principle and execution mechanism, but few people can understand why it exists (assuming that it exists is reasonable), and what problems it solves in the society.

One day

Here are my own vuE3 best practices. I read a lot of Element-UI Plus code and summarized some writing habits of React (hooks I extracted have obvious react traces). In addition, we implemented and promoted the projects in the company.

If you are careful, you may find that there is only one return logic code extracted from my setup. The purpose of this is not to write a huge setup. It is from the point of view of code readability, so I will not put it in the setup.

Element-ui Plus is all about maintaining code in setup (see their input component), and I don’t like maintaining a huge function.

The last

So far, I have only used VUE3 for less than 2 months. As my experience increases, I will continue to rebuild my opinion on it. Welcome to discuss with you