scenario

  1. A technology company that provides services to operators in the x industry
    • Firstly, an operation system (machine Center) will be developed on various functions of the machine.
    • Next, to provide the supplier with the data analysis system (data center)
    • Next, provides various promotional activities for operators (marketing center)
    • … (More business, need a lot of management system)

    In a short period of time all with a front-end project development, no problem. But as the volume of business grows, there is a variety of impacts from development to users (of course, multiple projects are fine, but users need to remember N links).

That’s where the problem comes in

Development:

  • Large amount of code, slow packaging, package size, longer time
  • The UI theme of the entire system is difficult to manage
  • Each iteration goes online and has a large impact
  • Code coupling chaos, dare not move, pull a restless body

Users: access will be slower and slower, easily affected by the development of live their own features, themes remain unchanged, etc.

thinking

How to combine aThe rockManagement system transformation split (each center of the module below there are dozens of menus)

What the micro front end is

Break the front-end application down into smaller, simpler pieces that can be developed, tested, and deployed independently, yet remain cohesive to the user. The three elements of the micro front end are: independent operation, independent development (independent of the technology stack, there should be no direct or indirect technology stack, dependencies, and implementation coupling between applications), and independent deployment

advantage

  1. Complexity control: Each UI business module can be developed by an independent front-end team, avoiding big code, facilitating maintenance and development efficiency.
  2. Independent deployment: Each module can be deployed independently
  3. Flexible technology selection: the same project can use all the front-end technology stacks on the market today, including future front-end technology stacks.
  4. Fault tolerance: When an error occurs in a module, it does not affect the whole system.
  5. Scaling: Each service can scale independently to meet business scalability and unnecessary consumption of resources;

I want it to look like this

Externally, it looks like a system. Internally can be divided into multiple Web projects

Common implementations

  1. Traditional iframe
  • Advantages: Built-in sandbox isolation between applications
  • Disadvantages: Repetitive loading of scripts and styles
  • Problems to be solved:
    • Layout problem: Iframe must be given a specified height or it will collapse
    • Pop-ups and mask layer issues: can only be vertically and horizontally centered within the iframe range, not vertically and horizontally centered throughout the page (global pop-ups can be used)
    • Browser forward/Back issue: Iframe page refresh resets (e.g. jumping from the list page to the details page, and then refreshing, returns to the list page) because the browser’s address bar has not changed (push base for route redirection)
    • Each child application entry is a process of browser context reconstruction and resource reloading.
  1. Runtime combination (each sub-application is built independently, and the main application is responsible for application management, loading, starting, unloading, and communication mechanism at runtime)
  • Pros: Good experience, truly independent development, independent deployment
  • Disadvantages: complex, need design loading, communication mechanism, cannot achieve complete isolation (style isolation can be achieved with style based shadow DOM, such as Qiankun.js), need to solve dependency conflicts, style conflicts

  1. Web Components

    Browser native components. Compared to third-party frameworks, native components are straightforward, intuitive, do not load any external modules, and have a small amount of code (popular React and Vue are component frameworks).

    Each subapplication needs to be written using Web Components technology or generated using a framework

    • Pros: Future-oriented technology
    • Cons: Refactoring is expensive and all code needs to be rewritten using Web Components
/ / MDN address
https://developer.mozilla.org/zh-CN/docs/Web/Web_Components
Copy the code

At present, domestic attention is relatively high technology

The most commonly used solution is the run-time composite. The most popular and mature one is probably Single-SPA. There is also the framework qiankun of Ant Financial, which attracts high domestic attention

Qiankun is a productionable micro-front-end framework based on Single-SPA, with JS sandbox, style isolation, HTML Loader, preloading and other capabilities required by micro-front-end systems. Qiankun can be used with any JS framework, and microapplication access is as simple as embedding an IFrame system.

With all that said, here’s the point

A project is currently running into the following bottlenecks

  • Jquery, React, Vue, Angular
  • Most of them are jquery code, which is very large and difficult to read
  • There’s a lot of business, like a hundred pages
  • And so on…

(Admittedly, it was a well-structured project at the time.)

The optimization goal

Optimize the project with minimal changes without affecting the original project foundation, so that it can inherit the original capabilities and conform to the current development practices and technology direction (infused with the idea of microservices)

The solution

Iframe is the cheapest access option for this project and also supports parent-child communication via possMassage. Moreover, as for the old Jquery multi-page project, Qiankun has no good solution for multi-page application. It is expensive and cumbersome to modify every page, but using iframe to embed these old projects is convenient. (Create two sub-projects, one for vUE/React, under the original architecture, development access)

Problems to be solved:

  1. Use an iframe that starts with #/iframe to access and hide other content. Separate the iframe from the original content and switch by showing and hiding
  2. Solve the access relationship, that is, local development and online access (online access to packaged content, offline access to local hot update code) Local access address (automatically intercept the URL behind iframe and access)
/ / local
http://localhost:8080/main/index.html/#/iframe/http://localhost:3001
// set localhost to IP address:
http://localhost:8080/main/index.html/#/iframe/test/dist/index.html
Copy the code

  1. Configure proxy to resolve local access across domains

  2. Since the original project is a direct access file, the package of the subproject needs to configure the relative path

    Since the DIST file needs to be run on the server, the resources are placed in the root directory by default. If you open index.html, you can see that references to CSS and JS files use absolute paths. For local disks, however, / points to the disk root, so the referenced file will not be found. Change the publicPath of the project to ‘./’ (depending on the specific project)

  3. Pass the menu from the base to the sub-project (depending on the status of the project or can be controlled separately)

  4. API request

Local request to start proxy (need to pay attention to cookies)

  1. Due to the defects of iframe, the use of popovers and mask layer problems (base provides a full-screen solution, i.e. the sub-project calls the base’s full-screen popovers)

  2. Data exchange between the base architecture and subprojects

In order to be able to use both online and offline (there is homology problem offline), postMessage is used for implementation, and then public bus is used inside the project to spread messages from the grassroots (according to the technical situation of the project).

One caveat: In react projects, you can wait for the base to prepare all the information and pass it to the subprojects before rendering the main content. However, delayed mounting app.mount(‘#app’) in vue will cause an error. So use the public bus to spread grassroots information to subprojects

Operation mode

Local development runs two projects, one grassroots and one standalone

The last

Finally, there was a discussion with some big guy that iframe is not good as a micro front end. Because of the article why Not Ifram. But personally, which one to use depends on the actual situation, for this project optimization, what is your goal. Qiankun. Js on cattle? Yes, but just because Iframe is old doesn’t mean he hates… Peace and love ~

Give me a thumbs up 👍👍👍👍