Contents summary

  • background
  • Vue3 project development get knowledge
  • The vite that surprised me
  • Difficulties encountered in the project
  • conclusion
  • Project technology stack
  • Information recommendation

background

There is a new project launched, the mobile project is compatible with Android 6+, there is no historical burden, technology selection can be free to play. Considering the project cycle/team technology/learning cost, the final selection is relatively new VUE3.

But by the time I get to the end of this article, some things are not up to date, the beta version of Vue 3.1.0 has been released and I have to say that the front-end technology is changing so fast that I can’t learn it anymore.

Vue3 project development get knowledge

I missed vue2 when I first started using it. I never got the best of VuE3 and couldn’t understand how good the combined API was online. For VUE2, I am familiar with the road. For VUE3, I am document-oriented. When I choose vue3, I need to get its essence. I find it really fragrant when I use it. The project combining VUe3 and VitE2 surprised me.

What problems do composite apis solve?

When I started writing the project, I didn’t get the advantages of the composite API, and I was a little unhappy without the global this, but as the project got more and more complex and the pages got bigger and bigger, I found the composite API really fragrant. I like it very much.

Vue2 data is defined in data, methods in method, maybe watch, computed and other things in between. There is a huge difference between data definition and method processing logic. When the logic complexity reaches a certain length, tracking the change of a variable is a big headache. The mouse needs to scroll back and forth.

With the composition API, this problem is solved. All the relevant ones can be put together. That’s great. It brings a whole new approach to development. If you’re a React developer or are familiar with React, vue3 is fast. You can even use hooks on your page. Because of the small use of this project, hooks are not used in the project, they can be used later if needed. To learn more about composite apis please refer to the documentation what is a composite API?

The change of the API

Because the component instance has not yet been created when setup is executed, there is no this in the Setup option. This means that you will not be able to access any properties declared in the component — local state, computed properties, or methods — except props. The setup option should be a function that accepts props and context.

Because props are reactive, you can’t use ES6 deconstruction because it eliminates the responsiveness of prop. If you need to deconstruct, you need toRefs

When SETUP is executed, the component instance has not yet been created. Therefore, you can only access the following property:

props
attrs
slots
emit
Copy the code

In other words, you will not have access to the following component options:

data
computed
methods
Copy the code

The whole project down with vuE2 only grammar difference, thought what change is not big, not difficult. Document-oriented development is basically what you need.

A component of thinking

How to write a good component, component planning/use/maintenance, is always a problem worth thinking deeply. The Composition API brings a new approach to development, even using hooks. Each module has its own internal data, which is abstracted from common use functions or hooks. The whole module is very clean and more and more engineering.

I used to think that since I chose Vue, I should use the form of. Vue. However, in the development process of this project, I saw that my friend used native JS to create components, and it was a bright light in my eyes. What suits your actual needs is the best, and hybrid component development can learn from each other.

For example, in the process of interface request, the user suddenly breaks the network, the front end prompts the user to break the network page, this code is very simple.

There are also components created in JSX that can be customized

Proper separation of logic points: Separation of buried logic and business logic is more beneficial for later maintenance of the project (custom instructions to implement declarative buried points).

Processing of routing logic

There is a focus in the field of vision, so there is a blind spot. In the route logic processing area, I screwed myself up. I focused on the composite API, and in the composite API documentation I couldn’t find the lifecycle function for entering the route. As a result, part of my page logic was written in router.js.

// Routing file
{
  path: '/index'.component: HOME,
  beforeEnter: (to, from) = > {
  // Update the last read record when you return from the page
    if (from.path === "/read") {
      to.meta = {
        updateHistory: 'read',}}}},// page file
watch(() = > route.meta,(val) = > {
  if (val.updateHistory) {
    // Update the last read
    getHistoryHandler()
  }
})
Copy the code

This is a very, very bad writing method, page logic and routing logic coupled together, late maintenance brought great problems, later colleagues guidance, corrected the problem. I actually ignored its original grammar, to persist with his new grammar.

All pages need a unified dynamic prefix for level-1 routing. That is, level-1 domain names of routes are not controlled by the front end, but front-end routing rules are concerned with level-1 routing in actual development. Configure dynamic routes for all routes according to the consistent logic, namely path: ‘/:flag/index’, path: ‘/:flag/listen’…. As long as there is a route, it needs to add /:flag in front of it. In some cases, it also needs to be processed separately in the business logic. This logic is mixed in a lot, which is not conducive to the later maintenance.

Want to be lazy, thinking there is no simple solution, colleagues spent a lot of time, constantly trial and error study, and finally found that the routing above the article, a code to solve a lot of repeated labor. CreateWebHistory supports setting base file directories

createWebHistory(location.pathname.split('/')[1])

Original packaging time also can specify the routing mode dynamically, great.

The vite that surprised me

Development Experience Comparison

Project launch && Project package && Project volume.

Ps: Since vue-CLI and Vite environment variables are not read in the same way as some CSS import methods, IN vue-CLI I commented the relevant code. Make sure the project runs. Everything else is exactly the same

Data comparison shows that:

Projects created by Vite far outperform those created by VUE-CLI in terms of project startup and post-package size.

Vue-cli created projects, packaging speed is better than vite, but in our development process, often packaging frequency is not high, and the slow is not very exaggerated.

Personally, I prefer Vite to build projects.

What attracted me to Vite?

1. No boundaries => pure HTML project, react project can use newer syntax, compatibility to tools.

  1. Keep up with the grammatical trends of The Times.

The module form introduces JS scripts

In JS, CSS can be introduced in this form

Support CSS modular writing pure HTML projects can be updated in real time

I loved the experience of being able to focus on business development without having to worry about syntactic compatibility and packaging configuration.

Vite Demo code address

Difficulties encountered in the project

There are always more difficulties than solutions. No matter how many problems there are, they will be gradually solved and the project will be online as scheduled. The development of projects, bumps and bumps, growth, learning is meaningful.

By the component

Vue-awesome-swiper was initially used, but vue3 does not support it. Although there is an official vue3 demo, vue2 and VUe3 need to be used together.

Swiper, which supports VUE3 itself, saved my life by only supporting vue3

Swiper itself supports the current mainstream framework. This is a great experience. It is the documentation that needs to be refueled

Virtual rolling

When the page list is loaded with hundreds of thousands of data, the white screen time is long and the scrolling is slow. At the beginning, front-end page paging was considered. As long as there was enough data, there were still many DOM nodes on the page, and the lag still existed when it reached a certain amount. Later, VUe-virtual-Scroller was used to solve the problem, but I found most of them were VUE2 versions on the Internet, and VUE3 versions were found in issues

Encountered in the process of use, the lack of some methods can not meet the needs of the product, and finally source code to find a way to meet the needs. Vue3 itself is also poorly documented, and the experience would be better if more methods were exposed than source code

However, the star of this project on Github is very good, it should be reliable, but I haven’t had time to do it yet, haha

conclusion

As far as my personal experience of this project is concerned, when using a new API, I need to think about a problem, logical point aggregation, and also pay attention to changing the thinking of code organization. This is not just the difference between VUE2 and VUE3, it is always a question that we should think about, every development should think about, how to make this project/component sustainable over the long term. The update of the framework is not just about the update of the syntax, but also about the problems encountered in the development of the framework. How did he solve it? For the long-term, stable and sustainable development of our project, can we use their experience for reference?

Technical stacks and documentation used in the project

The configuration documentation for vite.config

Routing the router

vue3

Swiper

Virtual scroll vu3 version

Vue3 / Vite documents are recommended

I learned a lot from last night’s uVU live broadcast!!

Vite document

Preparation for 2021: Vite engineering practice, suggested collection

Hand lift Vite, uncover the mystery of Vite

Prepare for 2021: Vite2 best practices

ViteJS, the next generation of front-end building tools

ViteJS – Open Source Friday

Spent the night conquering the whims of product girls with the CompositionAPI

Five Lightning Whips: In-depth analysis of Composition API principles

Stop writing Vue 3 like Vue 2

Vue3 source code analysis