This paper mainly provides two basic mode (Tao) type (Lu) practices based on the Qiankun microfront landing.

At the beginning of general technical articles, in order to fill up the number of words, they will introduce what Qiankun and micro front-end are, what advantages they have and what problems they have solved.

You don’t have to. Let’s just expand it.

First, you need to define some terms, otherwise you won’t be able to speak clearly.

  • The main application

It refers to applications that act as portals in a micro-front-end architecture.

It is also responsible for loading sub-applications, identifying front-end routes, and distributing routing information to sub-applications. Individual scenarios also manage state, inter-application communication and so on.

  • The child application

It refers to the business specific application, which can be interpreted as the main thing you are currently developing. Under Qiankun, a system has a master application that can be distributed to N sub-applications according to routing information.

1. Base model

The base model is designed to reduce development tasks by encapsulating commonalities into a sound master application as a system base, and then integrating the feature parts as sub-applications. More suitable for some management background projects.

The picture describes the relationship between applications under the base model well. At the same time, it is clear that the function development of sub-applications can only focus on their own business needs, and there is no need to repeatedly implement “login registration”, “permission management” and other common requirements.

🚀 🚀 🚀

For common management back-end projects, the pedestal model is a natural fit. Because the management background almost all have a lot of common parts, but the specific “management” things are different.

So, if you have a lot of management background development needs, you can put as much commonality as possible under a main application, when a new management background project is launched, only a small amount of development (sub application), through simple integration, can present a complete system.

Matters needing attention

Because most of the basic functionality is implemented in the dock, it is important to consider the transfer of information from the dock to the business application.

For example, user information, permission information, etc. can be passed to the child application as props, and of course, you can pass functions to pass data in the reverse.

The base model also has its drawbacks, mainly manifested in the weak UI customization capability.

The base is ready-made, and the base determines the overall appearance level of the final system. (Probably not too sensitive for most management backends)

As a result, we need another practical model for systems where the desire to manipulate interfaces is stronger.

2. Mosaic model

In the game, a good piece of equipment can be inlaid with various gems in addition to its basic stats.

The idea of the Mosaic model is just the opposite of the base model. We implement some independent functions as sub-applications and the business system as the main application.

In addition to developing their own systems, if the business team needs to reuse existing capabilities, it simply needs to access the required sub-applications.

Under this model, business development has complete control over the appearance level of the system.

In terms of energy efficiency, a lot of development investment can be saved to a great extent through combinatorial sub-applications.

The characteristics of this model are suitable for OEM custom systems:

  • Customer requirements for interface uniqueness;
  • At the same time, “on demand” integration of the capabilities that Party B can provide.

Of course, with more power comes more things

The interface customization capability is strong, which determines that you need to worry about the implementation of routing, menu and so on. After all, under the Mosaic model, sub-applications will only provide sub-page level reuse, how to integrate them into the current project, different frameworks have different requirements.

My side only practice ANTD-Pro is not too much trouble.

conclusion

Either model is an abstract understanding of the Qiankun microfront-end architecture.

The purpose is to reuse capacity and improve efficiency. Patients can choose flexibly according to their own team and sales strategies.