The most frustrating aspect of vue3 is the new Compostion API syntax. The difficulty is not the syntax, but the new way of thinking about organizing code.

When I first switched from Vue2 to Vue3, the code was written in strict compliance with the Compostion API, but found it less maintainable than the Option API.

The pit of tread

1. Divide code by technology type

In daily development, the front end will receive an interaction draft or design draft, start the layout, and then write the logical code. In Vue2, the usual practice is to put response data in Data and logical methods in Methods, which is very convenient and makes it easy to organize code. When using Vue3’s Compostion API, organizing code in Vue2 format does not improve code quality but reduces readability due to lack of constraints.

export default { setup () { const state = reactive({ message: '', msgList: [] }) const router = useRouter() let username = '' onMounted(() => { username = localStorage.getItem('username') if (! username) { router.push('/login') return } }) const onSendMessage = () => { const { message } = state if (! message.trim().length) return state.msgList.push({ id: new Date().getTime(), user: username, dateTime: new Date().getTime(), message: state.message }) state.message = '' } return { ... toRefs(state), onSendMessage } } }Copy the code

In fact, we’ve focused so much on syntactic changes that we’ve neglected to mention a word in the official documentation: logical concerns ！！！！！！ , logical concerns within the code refers to express the same business together, this is the single responsibility of guiding ideology, we cohesive type should not technology, but the business logic, because the trigger code changes are often the business requirements, so the same reason code change together, this will not lead to scatter type changes.

2. Too much focus on logic reuse

One of the features of the Compostion API is that it promotes logic reuse, which is true, but AT the time I made the mistake of thinking that only reusable logic should be packaged into hooks. Going back to the official Vue example, you’ll see that it splits the logic that was originally placed in a Vue file into a Composables directory that defines a file for each logical concern.

Emphasized this folder code reuse is not logic, but a logical separation of concerns, this also is the core to solve the problem of compostion API, because the application life cycle is 60% of the time in the maintenance, the maintenance is embodied in the code is in line with the single responsibility principle, the single responsibility is to make the same business code cohesion to a place.

So don’t worry too much about whether or not your code needs to be reused. Applying the right amount of redundancy will increase your application’s maintainability, as the Book The Path to Architectural Neatness states: For most applications, maintainability is more important than reusability.

If your code is really highly reusable, it can be promoted to the outer directory of the project and packaged into a separate hook file.

Rain Creek’s view

Compostion API in the proposal, there are a lot of people hold different opinions, there are opposition and support, in fact, there is no wrong, but we encounter different scenes resulting in different views. I read the RFC of the Compostion API and found the author’s answers to some of the questions and sorted out some key questions. The content is not fully translated and I suggest checking the original for the complete content. Original address [3]

Problem 1: The Compostion API doesn’t solve any problems at all, it’s just chasing new stuff

Yu: I don’t agree with that. Vue started small, but is now widely used in business domains with varying levels of complexity, some easily handled based on the Option API, others not. For example, the following scenario:

  1. Large components with lots of logic (hundreds of lines)
  2. Reusable logic in multiple components

For problem 1, you need to split each logic into different options. For example, a piece of logic requires some response data, a calculation property, some listener properties, and methods. To understand this logic, you need to keep moving up and down and reading, and although you know what type some properties are, you don’t know what they do. The situation is even worse when a component contains more than one logic. With the new API, you can combine data and logic together, and most importantly, you can cleanly extract that logic into a function, or even a single file.

Problem 2: Using a new API causes logic to be scattered in different places, violating the “separation of concerns”

Yu: The problem is similar to the problem of how project documents are organized. Many of us agree that organizing by file type (layout HTML, style CSS, logical JS) is not the right approach, because forcing related code to be split into three files creates the illusion of “separation of concerns.” The key here is that “concerns” are not defined by file types. Instead, most of us choose to organize files by functions or responsibilities, which is why people like Vue’s single-file component. SFC is a way of organizing code by function, but ironically it was also rejected by many when it was first introduced as a violation of separation of concerns.

Problem 3: The new syntax makes Vue less simple, leading to “spaghetti code” that reduces project maintainability.

Yu: On the contrary, the new API is designed to improve the long-term maintainability of projects.

If we look at any javascript project, we’ll start with the entry file, which is essentially the “main” function that your application implicitly calls when it starts. If there is only one function entry that results in spaghetti code, then all JS projects are spaghetti code. Obviously not, because developers organize code through modularity or smaller functions.

In addition, I agree that the new API theoretically lowers the minimum threshold for code quality. But we can mitigate this situation by using the same techniques we used to prevent code from becoming spaghetti. On the other hand, the new API can raise the upper limit of code quality, allowing you to refactor into higher-quality code than the Option API. Also, with the Option API you have to deal with issues like mixins.

Many people think that “Vue loses simplicity “when it really just loses the ability to type check code in components (that is, you don’t know whether a variable is data, method, or computed). But with the new API, implementing a type detector is also very easy to implement the old features. That said, you should not be limited by the Option API and focus more on logical cohesion.

conclusion

This is just a brief excerpt from the RFC discussion. If you have any questions about the new API, go to Github and read the original article, which covers so many issues that I won’t summarize them all.

But from what we’ve talked about and what I’ve learned in the field, with a new API, it’s very important to change the way you think about code organization, and remember the word “logical focus.”