Small knowledge, big challenge! This article is participating in the creation of “Essential Tips for Programmers” ~ 🥳🥳🥳P.S. 🥳🥳🥳 If there are shortcomings, welcome to correct oh ~

Since I started to contact Vue, I learned the concept of “everything in Vue is a component”. Adhering to this principle, IN the process of writing code, I can extract components from components, and maintain components as dimensions, logic reuse and UI reuse. However, with the expansion of the project and the iteration of the requirements, I found that many components could no longer be reused. I was afraid of the problems that would affect the whole body if I moved one part, or the unreasonable exaggeration of the scope of influence, and I was even afraid of not knowing where to start to solve them. Once the problem occurs, the simplest method is to create a new component that fits the current business scenario. Paste the logic of the original component into the paste, which is also left to paste, right to paste, and finally finished. But once this is done, the project is one step closer to refactoring.

It’s not that there’s anything wrong with maintaining code at the component level, but rather not understanding what logic needs to be implemented in components and what logic needs to be dependency injected. In other words, you start development without knowing how to achieve high cohesion and low coupling of components. Understanding how components are packaged is the key to “everything is a component”, so that you can better write and maintain Vue projects.

In the components I have written, I might as well have the following situation, and it is because of these situations that my components are becoming more and more difficult to reuse, and more and more painful to maintain

  • The component contains API requests
  • Component to retrieve data directly from the request
  • Components depend on a global state or on a shared state
  • Components depend on the data of a service scenario
  • The component is loaded with too much logic and up to 300+ code
  • Components are a mix of UI logic and business logic
  • .

Here, I summarize some methods and tips for decoupling components. These methods have advantages and disadvantages, and need to balance according to the actual situation

Divide the container components

Not all components are a level, some components are divided into three levels, respectively is container component, business component, the UI components/stateless component, and some simple divided into intelligent components and a fool, or packaging components and components, type or bloated components and simple components, or container type components and display components, etc., But no matter how you slice it up, the purpose is the same, for better reuse, for separation of concerns, for separation of UI logic from business logic.

Then try to divide components into container components and presentation components, and separate API requests, data formatting, and data manipulation into container components, so that the presentation components are independent and single. To put it plainly, it is necessary to clarify what the input and output of a component are, and consider how the intermediate state is transformed and maintained, and then divide the different component levels, as shown in the figure below:

References: ngte – web. Gitbook. IO/I/react/she… Juejin. Cn/post / 684490…

Use v – slot

Slot supports dynamic composition and replacement of components. Scoped Slot provides access to data in child components. With both slots, you can reuse component UI logic to create reusable, flexible components. At ordinary times, for example, a list of common scenarios, including the list head, list and page area, the three components together, can realize the list filter, display of the list, a list of loading, the list of pages, and other functions, the status and function of each part has its own independent, if one day to the demand, the requirements for layout/style is consistent, But the requested interface is different, or the request interface is still the same, but the style is a little different, how to implement reuse?

Reference:Markus.oberlehner.net/blog/depend…

Above, the generic ListingLayout component is responsible for the basic style and layout of the list. NavFilter, EntityList, and NavPagination components can be easily reused because they are completely separate from any data acquisition logic.

provide/inject

This API mainly implements dependency injection and state sharing. In Vue2, provide/inject does not provide reactive data, but it does not affect how we use it for dependency injection, which is similar to how a component retrieves data from a context, such as injecting a request API for common component use. Provide/Inject can be used to systematically transfer data across hierarchies, provide to provide dependencies, inject to use dependencies, and to some extent, components can be programmed for the provide/ Inject interface. P.S. author previously wrote an article provide/inject, welcome to read oh ~

Continue to list above example, although you can reuse the layout and NavFilter, EntityList, NavPagination components, but the container component package these components ProductListingContainer. Vue is reuse, because of the API request is different, Follow-up may create a postListingContainer vue, create a commentListingContainer. Vue, that is so much more logic in the same container components, that how to optimize it? ———— uses provide/inject, as shown in the following figure:

Since inject is used, there must be some place to provide fetch method as follows:Reference:Markus.oberlehner.net/blog/depend…

That’s dependency injection, and the component is interface oriented, which means you just give me an interface called FETCH, and I don’t care how the logic in fetch is implemented, I just call fetch. That can register different provides for the lower layer to use, depending on the situation, but expose the same interface.

vuex

It is suitable for extracting general logic, business logic unrelated to UI logic, or formatting data logic from VUEX. In this way, some business logic can be extracted moderately and reused.

  • It has nothing to do with the UI data of the page
  • Itself is related to data logic
  • It has nothing to do with UI changes
  • Itself is relevant to business logic
  • The inability to retrieve vm instances and manipulate methods and properties on the VM itself means decoupling from the current component tree

There is a concept of Module in VUEX. If a component depends on a vuex Module, it will form a strong dependence relationship with Store. If you want to reuse UI without reuse logic in VUEX, it will be troublesome. Or consider partitioning container components, which is simpler and more scalable than dependency injection.

plugins

This is similar to VuEX in that it is tightly coupled to components that ideally should not be strongly coupled to aN API, nor should they be coupled to functionality that causes side effects. However, unlike Vuex, with vue’s plugin system, the VM can be accessed, meaning that apis such as Lifecycle Hook can be used for components. Plugins are best used in situations such as VUe-Router and Vuex, which provide global advanced functionality for VUE.

Mixin & Higher-order Components & Renderless Components

Here I will not say these three, there Are a lot of information on the Internet, I think it is easy to understand the list, you can refer to ~ Why Are Mixins Considered Harmful? HOC Renderless Components in Vue. Js

Vue3 composition API

It sets off a heat wave, which can be called Vue component reuse, logical separation of concerns of the absolute child