Hi Helo, I’m Peryl. Today, I would like to introduce a micro-front-end framework developed by myself: Plain-Micro-Application; I’m still in a demo state, I haven’t figured out how to write the documentation, how to quickly let the developers build a micro front-end project, and I may need to set up a scaffolding to assist the implementation. You can first understand the features;

  • It is strongly recommended that understanding the details while you’re watching video: www.bilibili.com/video/BV14q…
  • Martsforever-demo.gize. IO /template-pl…
  • Account password: admin / 888888
  • All second-level menus under “Sub-Application” of the first-level menu are embedded pages realized by loading sub-applications.

features

At present, the microfront-end framework is quite different from the known microfront-end frameworks, such as SingleSpa, Qiankun.js and so on. The following are the main features:

  1. With multi-tab form of contracted page routing, can automatically manage the realization of page instance cache destruction; Supports traditional history or hash routes for sub-applications.
  2. Several micro front-end applications are independently developed and deployed. The sub-application “can” implement local development and debugging by loading the main application, and use the main application’s ability without installing any dependencies, such as login, main menu page, etc.;
  3. Zero coupling; The child application can put all runtime dependencies in the main application. The child only needs the address of the main application to use the basic dependencies (Vue, React, ReactDOM) and basic functions (login, home page, main menu page).
  4. Easy maintenance; The master application only needs to configure the address of the child application, and the child application only needs to configure the address of the master application.
  5. Support current popular build tools Webpack and Vite; Whether it is Webpack or Vite, whether it is local debugging or packaged deployment, it has a perfect development experience; Old projects based on JSP, Jquery, etc. without the use of building tools can also load child applications through iframe, and there will be no iframe destruction problem;
  6. Support any technology stack; Child applications can be Vue, React, Angular, or any other front-end stack;
  7. Fast compilation and packaging; The main application only has the public dependencies required by the landing page, the main menu front page, and the child application. The main application manages these public dependencies through static files, so the compilation, debugging, and packaging events of the main application are not very long, and the child application depends on the number of pages and the building tool.
  8. Zero-cost access to new technologies; Subapplications can use any new technology without affecting overall system loading speed, compilation time, code structure, etc.
  9. Zero cost access to old projects; Existing projects based on Webpack and Vite can be plugged into a micro front-end system with minimal configuration. Older projects can be accessed through IFrame without any changes.

Detailed instructions

One, multi-tab form of contracted page routing

  • In the system, the routing information of the page will be stored in localStorage in the form of a two-dimensional array, so when the page is reopened and refreshed, no matter what the current URL value is, the last accessed page will be opened.
  • The forward path of the page is based on the file path of the page. Each child application has its own page path prefix;
  • Automatically manages page instance initialization and destruction, and even DOM nodes are not destroyed when the page is switched, just useddisplay:noneHidden; For example, when jumping from the list page to the details page, the scrolling height and filtering parameters of the list page will be automatically retained without additional intervention.
  • In this routing mode, a history route or hash route is also supported. See the video for details.
  • In multi-tab mode, the history route or hash route also has some problems when implementing the page return. See the video description.

Second, independent development and deployment

  • When the sub-application is debuggable locally, it can use the functions of the main application (login, main menu) by loading the remote deployment address of the main application, without additional dependency coupling;
  • The main application can add, overwrite, and remove child applications at run time.
  • Even if the remote application is not cross-domain, the remote application can be loaded by proxy during local debugging.

Zero coupling between applications

  • The child application itself can put all runtime dependencies in the main application, such as basic Vue, React, ReactDOM, and so on. You don’t need to install these dependencies when debugging locally. If you’re developing in typescript, you just need to install the corresponding type declarations. No longer need to worry about different versions and unified dependencies on upgrades;
  • The master application only needs to know the access address of the child application, and the child application only needs to know the access address of the master application. No additional code or package dependencies are required;
  • It is convenient to realize the code permission control. For example, the front-end developer responsible for the commodity module only needs to allocate the permission of the sub-application project of the commodity module, and does not need to allocate the permission of other sub-applications and the main application project.
  • Syndication between multiple sub-applications is also simple;

Four, easy maintenance

  • Applications can access each other only by knowing the address of each other, without NPM package management.
  • When the master application is deployed, if it is set to cross the domain, then the child application can achieve zero configuration to locally load the remote master application startup debugging; If the remote master application does not support cross-domain, you can also configure the local proxy to achieve cross-domain.

Support any build tools and projects without build tools

  • Support sub-applications as Webpack;
  • Support sub-application for Vite, with perfect development experience, debugging and packaging mode no difference;
  • If the child application is an old project that does not use the build tool, it can also be embedded through iframe. And there is no iframe frequent destruction problem;

Support any technology stack

  • There’s nothing to say about that;

Fast compilation and packaging

  • The main application manages child application common dependencies in static files, and the main application does not have many pages, so the packaging time is not very long.
  • Subapps depend on the number of pages, and with Vite, even hundreds of pages can be packaged very quickly;

Eight, zero cost access to new technology

  • The cost of creating a child application is low and can be implemented with minimal configuration.
  • Sub-applications can use any technology stack and any dependency package without affecting the loading and build performance of the main application. Even if the child app relies on a large plug-in, the wait time is only when the child app’s specific page is accessed.

Zero cost access to old projects

For Webpack, Vite type projects, only need a small amount of configuration can be connected to the micro front-end system, if you really do not want to make any changes to the old project, then you can also load through iframe;

The problem

No JS sandbox and CSS isolation

Because the DOM is not destroyed during page switching and the page is not necessarily destroyed, there is no JS sandbox and CSS isolation to ensure that the page works properly.

There are some problems integrating history or hash subapplications

  • Does not support browser forward and back page forward and back;
  • Sometimes there are some display issues when the page switches quickly;

Relevant warehouse address

The base application (base + main)

  • vuecli + react + plain-design-composition + plain-design
  • Gitee.com/martsforeve…

Vue child application

  • vuecli + vue3 + tab router
  • Gitee.com/martsforeve…

The React child application

  • vuecli + react + tab router
  • Gitee.com/martsforeve…

Vue Vite subapplication

  • vite + vue3 + tab router
  • Gitee.com/martsforeve…

React Vite sub-application

  • vite + react + tab router
  • Gitee.com/martsforeve…

Vue Router sub-application

  • vuecli + vue3 + vue-router
  • Gitee.com/martsforeve…

React Router sub-application

  • create-react-app + react + react-router
  • Gitee.com/martsforeve…

Umi child application

  • umi + react + react-router + iframe
  • Gitee.com/martsforeve…

At present, UMI applications can only be accessed through iframe, because to change the entrance of UMI, UMI plug-ins have to be written. Currently, I have no time and energy to do this.

The Main primary application

Gitee.com/martsforeve…

model

There are three microfront-end modes:

Application type:

  • Base application: store public static resources, login page, page loading, switching logic, etc.
  • Main application: define sub-applications, login page and Main menu home page content;
  • Sub-application: specific page implementation;

Mode:

  • The first mode is suitable for the early development of the project, when there are not many pages and the technology stack is unique. In this case, only one project can achieve all the functions;
  • The second mode is the one that has been explained in this article. There is only one main application (in fact, the main application contains the Base application), and when loading the page, the specific page logic is rendered by loading the child application. This pattern is distinct from the third pattern.
  • The third mode: there are multiple main applications. For example, the current project product has multiple systems. For example, there are two systems in the sample figure, ERP and CRM. The two systems use some common subapplications (subapplication 2), and others have their own unique subapplications; Then when the system initialization, load the Base application first, then initialize the landing page and the main menu page, and finally render the specific page by loading the sub-application to achieve;