preface

This article focuses on the conceptual issues related to the micro front end.

  • Current chapter: Multi-dimensional introduction and analysis of the micro front end from scratch, explore the micro front end technology solutions
  • Subsequent chapters: Build the micro front end from scratch based on Qiankun, and analyze the source code

This section describes the micro front end

1) background

With the development of the industry and the rise of system complexity, how to split the technology stack of large projects to further improve the development efficiency has become the exploration direction of the industry.

The market has proven the advantages of separating the front end from the front end, allowing for the most efficient development and the best experience in each language, since the front end was separated from the front end a decade ago. The front and back ends can focus more on exploring their own technical areas.

And then the system gets more and more complex. With the continuous expansion of the business, the demand continues to increase, the project slowly bloated up. Therefore, the need to bear the server pressure, the market slowly launched “micro services”.

The idea began to shift from the pursuit of large and complete, to small and beautiful.

Microservice individuals simply understand that the system is broken up into small services that can run independently and work together. It solves the problem of bloated projects, decoupling them into relatively small projects without affecting their “collaboration” with each other. At the same time, different technologies can serve a system, and the extensibility is also targeted at micro applications. The impact of extending a single service is smaller, so the probability of system error is lower.

Slowly, front-end engineering began to face the same problem:

Similar to Aliyun, its middle stage, according to an article, its middle stage is developed by 15 different teams merged.

At this time, if it is still completed in the form of a single project, the process must be very difficult, just unifying the norms of these 15 teams, it is enough to eat a pot. At this point, you need to re-plan how the front end is engineered.

Let’s take a look at the downsides of “single project” :

  • 1. The waiting time for packing a project is enough to make you wonder how time flies. You can pack your lunch several times a morning.

  • 2. Envy the new technology stack really sweet, but the original project is too much changed, and the risk after the change is also very big, hope and qupace.

  • 3. Integration of different team projects and incompatibility of different technology stacks. Which leads to a different technology stack first in the world debate: Why don’t you use X? X is the best language in the world.

  • 4. Secondary development of historical projects, the technology stack can understand the development history of the front-end for decades, looking for explanatory documents older than you. You can’t use the new language.

  • Welcome to add other jokes…

At this point, there is a god to help you solve these problems. There is a way of thinking called innovation, and a way of thinking called reference. And the front end to solve this kind of problem, began to learn from the “micro service” thinking.

The understanding of micro front-end personal identification enables its front-end projects to be transformed into multiple independently operated and developed projects, and at the same time brings solutions shared by different projects such as communication and caching. Modularized development of different technology stacks and different businesses is possible.

Its focus is a little different from micro services:

Microservices focus on decoupling, and the microfront-end on aggregation.

2) The significance of the existence of micro front end

The significance of the existence of the micro front end is briefly mentioned above, which will be analyzed in this section.

It was interesting to see an article commenting on the microfront end:

The micro front is the means of divide and conquer, making “what is God’s to God, and what is Caesar’s to Caesar.”

Details are as follows:

  • Application autonomy: as mentioned above, the micro front end of large projects is cut into different small projects. Each project can have dependencies or no dependencies at all. Thus to complete their respective application of their management purposes.

  • Single responsibility: According to the division, each application has the positioning of each application, please refer to the chapter question, how to divide the micro front end.

  • Off the tech stack: There is application autonomy, which means that each application allows its own characteristics, even if the framework is different, to fit into the same project.

  • Incremental upgrades: A lot of times, we reboot the entire system because of minor updates. The micro front end, however, allows you to just update your projects with less risk and less cost.

  • Solving the problem of too big projects: The waiting time mentioned above for packaging projects is enough to make you wonder how time flies. If a micro front end is introduced, the size of the project can be freed up.

These are the meaning of the existence of the micro front end, welcome to supplement.

3) Scenarios suitable for the micro front end

From (www.yuque.com/kuitos/gky7… Personally, I think the answer is very good:

    1. The old system doesn’t work, and new requirements keep coming.

No commercial company would allow engineers to take a system with a certain number of users offline simply for the sake of a technical upgrade. And you probably can’t just use iframe as a “reliable” way to do that, because the product says you need to “bounce to the middle.”

    1. Your system needs to have a mechanism that supports dynamic plugging.

This mechanic can be a well-designed system of plugins, but in cases where an app is being added or the app is old enough to be too expensive to retrofit, there may be a transition to micro-front-end gameplay.

4) How to divide the micro front end

Every company has every company’s scene, every family has this difficult experience, and their different. The essence of introducing a micro front end is to solve these problems. So, what’s your problem? The micro front end is how to divide.

Here, the author analyzes some suitable scenarios of the micro front end:

  • Recommendation 1: Divide by organizational structure

Suitable for organizational structure adjustment of the enterprise, the introduction of new technology stack, etc. The old one needs maintenance, the new one wants new technology. Grouping by organizational structure is a feasible solution.

  • Recommendation 2: Divide services by subservices

A lot of front-end projects are not planned in the early stage, are a long-winded, all in mode. What you mean? Similar to some commercial companies, such as ERP, CRM, OA, TMS, OMS, MIS and so on, all businesses are mixed together.

Such a project, long-term maintenance, thousands of pages is very normal. It is also a good choice if it is divided by sub-business.

  • Recommendation 3: Divide by permission

There are N independent permissions in the system. In order to facilitate the integration and loading of resources, you can also divide resources by permissions to avoid introducing packages that should not be referenced.

  • Recommendation 4: Divide by change frequency

Some businesses for stability, some chicken hair details to update. In this case, it is also a good choice to divide by change frequency.

  • Scheme 5: Divide by following back-end services

Well, yes, that’s a good solution (although the front end doesn’t want to be tied down too much, but it follows the plan anyway).

There are other division schemes, welcome to supplement.

5) Currently popular micro-front-end frameworks

The following are the open source microfront-end frameworks of the market. I recommend Qiankun. After all, documents or forums are relatively mature and their APIS are relatively simple.

  • 1) single – spa
  • It’s official: javascript router for front-end microservices
  • Single-spa.js.org/

The microfront-end framework is the underlayer of many other microfront-end frameworks. Build co-existing microfronts that can (but don’t need to) be written using your own framework.

  • 2) qiankun
  • It’s official: Probably the most complete microfront-end solution you’ve ever seen
  • Official website: qiankun.umijs.org/zh/
  • Development team: Ant Financial
  • 3) microApp
  • It’s official: a minimalist solution for building micro-front-end applications
  • Official website: micro-zoe.github. IO /micro-app/
  • Development team: JINGdong
  • 4) garfish
  • Official introduction: Contains the basic capabilities needed to build a microfront-end system, which can be used by any front-end framework. Simple access, can easily combine multiple front-end applications into a cohesive single product.
  • Official website: Garfish.top /
  • Development team: Bytedance
  • 5) an emp
  • Official: an implementation of Micro Frontends, based on Webpack5 Module Federation, but ready for production
  • Official website: github.com/efoxTeam/em…
  • Development team: YY
  • 6) icestark
  • It’s official: Use ICestark to build your next micro-front-end application, or migrate your current mega-application painlessly. As simple as developing a SPA application, it not only solves the problem of multiple development teams collaborating, but also brings a safe sandbox and excellent performance experience.
  • Official website: icestark.giee. IO /
  • Development team: Alibaba

The solution of micro front end

How to implement a micro front end that splits an application into multiple applications,

The following is a personal summary of my opinions after reading some articles, books and practice.

1) Routing distribution

Simple understanding: Distribute routes from the primary application to the route distribution application.

Each project is a separate project, and we can use HTTP reverse proxy technology to route the request to the corresponding application page.

The following legend:

This solution is the “simplest” and “best understood” microfront-end solution. But using this solution alone is just the “aggregation” of the front page, which seems to merge different projects into one project deployment.

In this scenario, the page always exists in a single application, but can be switched to another application at any time. Less risk, less applicable scenarios, suitable for less interaction, and more independent functions of the mid-platform or application interaction.

Here’s an example that I think is more appropriate :(penguin doesn’t do this though, maybe each team needs its own kpi?)

Such as Tencent news: news.qq.com/

Inside embedded NBA section, Tencent Sports: sports.qq.com/nba/

The two are completely different styles, most likely from different teams. At this time, both need to log in twice, but from a user’s point of view, are your home enterprise’s website, in the same entrance. I just finished reading your news module and logged in. I want to check out the NBA module. I wonder if IT bothers me to log in again.

If we learn from the concept of the micro front end, the relationship between them can be seamless to the user, can bring the user no perception, even in the experience did not notice that these are two different applications. That’s the benefit of routing.

However, its disadvantages are also obvious:

  • Different projects jump, need to complete the re-download of new project resources, there will be a blank screen waiting and other obvious defects.

  • Different projects cannot communicate in real time, but can only communicate through static cache (such as cookies,localStorage, etc.). There is no concept of status controller (similar to VUEX). After assigning values, users have to swipe the corresponding page to take effect, which is very bad for users.

  • It can only exist at the page level, and multiple applications cannot coexist.

Personal summary of his more suitable scene:

  • Different technology stacks differ greatly, and are more difficult to compatibility, migration, etc

  • The old project was lame, but it was important, and you didn’t want to spend a lot of time reinventing the system

  • Ad-hoc decisions are made when different projects and applications need to be put together in parallel

2) Front-end microservitization

Let’s talk about coexistence of applications.

The routing distribution described above is a page-level completion microservice, where each page is an independent project. While front-end microservitization pays attention to the display of multiple applications that can be embedded in a page, to better understand the legend:

Embed different items (non-IFrame) on the same page. In this way, there will be two front-end applications running on the same page.

When we point to a route to an application, one or more applications are loaded and run, and the page can still save the running status. And these applications are not affected by the technology stack. For example, the page can coexist in React,Vue,Angular, JSP and other technology solutions.

  • The front-end microservice scheme has a very significant design significance. First, it separates from the technology itself and makes it possible to integrate different technologies into the same project. Second, it is a technological breakthrough to allow different applications to seamlessly exist on the same page.

The practice of the program mainly consists of two steps:

  • 1. The DOM is introduced or created in the appropriate place on the page.

  • 2. The user loads the application and unloads it when necessary.

However, there are still many problems to be solved in the design of Step 2. For example, different project plug-ins conflict, how to prevent the same page style from being globally polluted, how to prevent timer conflict, how to ensure that memory does not overflow and other issues. It’s a headache to solve.

3) Microapplication

Microapplication refers to the fact that applications are developed as a single project and merged into a new application at run time. But there is a characteristic, is the requirement of unified dependence. It’s kind of a utility pack concept. Let me illustrate it a little bit more clearly.

According to the legend, at this time, the application is divided into multiple sub-applications, with the help of common dependencies, and finally, through the way of software engineering, multiple independent applications are combined into a single application in the deployment and construction environment.

Microapplication is similar to the front-end microservitization mentioned above. It is independent application in development, and can be loaded separately according to independent business, independent module and independent demand in construction.

But there is one difference:

Front-end microservitization does not require a technology stack, decoupling multiple applications and displaying them together. However, microapplication emphasizes on consistency. At this time, it is certain that the technology stack is unified, which is more suitable for the same team and the concept of cutting projects into microapplications according to business.

4) Microcomponentization

Widgets are runnable code that can be embedded directly into an application, precompiled, and loaded for use.

The microfront end is microcomponentization, where each team writes its own business code, compiles it and deploys it on the server. When running, only the corresponding service modules need to be loaded.

If it is handled well, we only need to update the corresponding module for subsequent updates.

Still a little confused? I don’t need a legend to understand that.

In a single-page framework, when we load a component asynchronously, the browser will download a js file from the server, execute it, and embed it in the corresponding page. This is typical of microcomponentization.

Looking at this, you might think that microwidgets are a little bit like application microservitization. It’s not:

Microcomponentization means that different front-end applications can use the same set of dependencies by hacking the build system. It improves the problem of reloading dependent files in the application of microservitization.

Currently commonly used forms of microcomponentization are:

  • Standalone code built by subcontracting, such as chunk files built by Webpack.
  • Components written using DSLS.

5) Front-end containerization (IFrame)

This part is the most familiar technology of all the front ends. Iframe is older than many front-end developers. This, “older” common technique, is still useful today.

You can quickly embed one website into another website. All resources are isolated from each other. If you do not write parent-child communication, the two sides of the code will not affect each other (but loading will still be affected).

In our front-end microservitization, iframe has helped us achieve the most difficult sandbox environment, which is equivalent to creating a new independent host environment.

There is a saying that iframe is the best microfront-end solution, regardless of the experience. Iframe is the lowest cost and least risky solution when other solutions are unreliable or incompatible.

But it is also because it is too independent, application to application, loading mechanism, communication mechanism is the place that needs breakthrough. Therefore, when adopting this scheme, we need to seriously consider:

  • Different application management mechanisms, how to load and uninstall corresponding applications.
  • Communication mechanism between applications. For all of this communication, using postMessage might complicate the program. Also need to understand iframee1.contentWindow and other knowledge points

The following soul torture module, why not use iframe, can help distinguish iframe from other schemes.

6) Web Components

Take a look at developer.mozilla.org/zh-CN/docs/… Web Components:

Web Components are a different set of technologies that allow you to create reusable custom elements whose functionality is encapsulated outside of your code and use them in your Web applications.

Web Components aims to solve these problems — it consists of three main techniques that can be used together to create custom elements that encapsulate functionality and can be reused anywhere you like without worrying about code conflicts.

  • Custom Elements: A set of JavaScript apis that allow you to define Custom elements and their behavior, and then use them as needed in your user interface.
  • Shadow DOM: A set of JavaScript apis for attaching a wrapped “Shadow” DOM tree to an element (rendered separately from the main document DOM) and controlling its associated functionality. This way, you can keep the functionality of elements private so that they can be scripted and styled without fear of running afoul of the rest of the document.
  • HTML Templates (HTML templates) : The

I’m currently writing a demo of Web Components and haven’t experienced any real advantages yet. It is also off the technology stack and is an important development discovery for future components. But with forum introduction, the current compatibility is still more general, only support Google and other browsers. The market is not popular yet.

7) summary

The above is the specific practice of the micro front end. They each have their own age, and each has its own use of the scene. In reality, the micro-front-end framework we use is a combination of them.

Here, with the help of the user’s legend, compare the differences between each scheme:

Figure from: www.pianshen.com/article/117…

The concrete technology realization scheme of micro front end is discussed

Understand the implementation pain points

Before studying how to realize the technology of the micro front end, we need to understand the pain point of the micro front end.

Personal views on the pain points of building a micro front end:

  • How to identify and locate routing items
  • How to unify the life cycle of different applications
  • How do JS and styles separate different items
  • How do parent and child applications communicate, and brother applications
  • How do I build a global state controller
  • How are common resources reused

So let’s go around these technical pain points and see what the solutions are.

1) How to identify routes of different projects

The cost to the user in the browser is huge if all the project routes are loaded at once.

1) First of all, assume that the function of each subapplication is independent, so if all routes of the subapplication are needed, the instance initialization of the subproject should be completed first. If there are more than a dozen subprojects, the browser may not be able to handle the load of resources and initialization of these subapplications, and even if it is able to handle the load, users will not be able to wait.

2) Suppose it is configured by a large project, or all traversed in main project mode. For large projects, thousands of routes are common. More importantly, being managed by a large project, on the one hand, is difficult to decouple from the sub-application, on the other hand, it also increases the complexity of the application.

How to deal with that? The community has been very friendly with its proposals:

Each subapplication defines a route prefix, traverses the route prefix identification items, loads the subapplication, and then resolves the internal routes of the subapplication.

Then the problem will become very simple, we first go to hijack the routing system, before entering the main route, a set of dynamic routing scheme can solve the problem.

Take a look at the legend:

2) How to unify the life cycle of different applications

The lifecycle of each framework is inconsistent. So how to unify?

Only one specification, or protocol, can be located by the host framework to synchronize the frameworks. Take single-SPA as an example, the bootstrap, mount, and unmount lifecycle hooks that represent the framework.

Which trace source can be queried to their implementation ideas:

If you are a child of the React stack, mount will correspond to reactdom.render. If you are a child of the Vue stack, mount will correspond to Mounted.

Therefore, when we use the third-party micro-front-end framework, we should determine in advance the corresponding framework of the sub-application, which framework does not support the problem. Like Vite, there are currently some frameworks that are incompatible or not supported.

3) How to isolate JS

That’s how to build a JS sandbox environment. In human terms, this means that your program runs in an isolated environment without affecting other programs.

This involves a sandbox environment issue to ensure that JS is not exposed to external influences.

Directly introduce the solutions that I know about:

  • iframe
  • diff
  • proxy

This section reference: blog.csdn.net/nhheajzhbjk…

  • iframe

With its own independent sandbox environment, iframe is not used in this solution, so iframe is not analyzed.

  • diff

It’s kind of like the Diff algorithm, but the reference is Window. In each child application, a windowSnapshot is created, and operations on the corresponding snapshot Windows objects are recorded in creating a windowSnapshot.

When the child application is invoked, the value of the operation is also recorded to create a windowSnapshot object and operate Windows.

When a child application is lost, save the windowSnapshot object, restore and operate Windows. This gives it a sandbox effect.

If you still don’t understand, directly look at the source code:

class WindowSnapshot { constructor(name) { this.name = name; this.windowSnapshot = {}; // Record the diff object this.modifyMap = {}; // Temporarily cache windowSnapshot objects while leaving} active() {this.windowSnapshot = {}; For (const item in window) {this.windowsnapshot [item] = window[item]; } Object.keys(this.modifyMap).forEach(p => { window[p] = this.modifyMap[p]; }) } inactive() { for (const item in window) { if (this.windowSnapshot[item] ! == window[item]) {this.modifyMap[item] = window[item]; // Restore window window[item] = this.windowsnapshot [item]; }}}} const windowSnapshot = new windowSnapshot (' apply A'); windowSnapshot.active(); // Activate sandbox window.remark = 'assignment succeeded' console.log(' open sandbox, note: ',window.remark); windowSnapshot.inactive(); // Deactivate sandbox console.log(' Leave sandbox, note: ', window.remark); windowSnapshot.active(); // reactivate console.log(' reactivate, note is ', window.remark);Copy the code

The log is as follows:

If the sandbox is opened, the remarks are: THE sandbox is left successfully. Undpay is activated again, and the remarks are: the sandbox is set successfullyCopy the code

At this point, the sandbox function is complete.

  • proxy

An ES6 proxy is a proxy. By hijacking the window, we can hijack some of the child application’s changes to the global environment.

Direct look at the source code:

Const updateWindowProp = (prop, value, isDel) => { if (value === undefined || isDel) { delete window[prop]; } else { window[prop] = value; }} class ProxySandbox {active () {/ / according to the record reduction sandbox enclosing currentUpdatedPropsValueMap. ForEach (= (v, p) > updateWindowProp (p, v)); } inactive () {/ / 1 will change during the period of the sandbox attribute reduction for the original attribute this. ModifiedPropsMap. ForEach (= (v, p) > updateWindowProp (p, v)); / / 2 will increase during the sandbox the global variables to eliminate this. AddedPropsMap. ForEach ((_, p) = > updateWindowProp (p, undefined, true)); } constructor(name) { this.name = name; this.proxy = null; This.addedpropsmap = new Map(); This.modifiedpropsmap = new Map(); / / there are new and modified global variables, the sandbox activated when using this. CurrentUpdatedPropsValueMap = new Map (); const { addedPropsMap, currentUpdatedPropsValueMap, modifiedPropsMap } = this; const fakeWindow = Object.create(null); const proxy = new Proxy(fakeWindow, { set(target, prop, value) { if (! Window.hasownproperty (prop)) {// If the window does not have a property, record it in the new property // debugger; addedPropsMap.set(prop, value); } else if (! Modifiedpropsmap. has(prop)) {// If the current window object has this property and has not been updated, record the initial value of the property on the window const originalValue = window[prop]; modifiedPropsMap.set(prop, originalValue); } / / record modify attributes, and the value of the modified currentUpdatedPropsValueMap. Set (prop, value); // Set the value to the global window updateWindowProp(prop, value); return true; }, get(target, prop) { return window[prop]; }}); this.proxy = proxy; }} const newSandBox = new ProxySandbox(' ProxySandbox '); const proxyWindow = newSandBox.proxy; Remark = '1' console.log(' sandbox: ', proxywindow.remark, window.remark); newSandBox.inactive(); // inactivate sandbox console.log(' inactivate sandbox: ', proxywindow.remark, window.remark); newSandBox.active(); // Deactivate sandbox console.log(' reactivate sandbox: ', proxywindow.remark, window.remark); // Deactivate sandbox console.log(' reactivate sandbox: ', proxywindow.remark, window.remark);Copy the code

4) How to isolate styles

Avoid styling problems between different applications. How to isolate styles between different applications is also an issue to consider.

The “uniform specification” case is not considered here. If different sub-applications unify the specification, use standards such as BEM, or even do not rename at all, then there is no need to solve the root cause. I’m just going to talk about the case where each child application has only its own child application, and it’s not affected by other applications.

Here are a few relatively mature solutions:

  • CSS Module (Recommended)
  • css-in-js
  • ShadowDOM

  • CSS Module the scheme, SPA framework friends are relatively familiar with. When using packaging, each application has a different selector name. As long as the child applies to the child element of the selector, only the style of the current child applies. None of the other subapplications match.

  • If you’ve written react, csS-in-js will look like this:

    <h1 style={style}>
     Hello, world!
  </h1>
Copy the code

React fontSize is a built-in conversion method that converts an application’s CSS style to a font size. There are many csS-in-JS solutions available today, and polished. Interested partners can go into depth.

  • ShadowDOM

    Take a look at ShadowDOM. ShadowDOM is a magic tool for writing components. The most important use of ShadowDOM is to isolate the external environment and encapsulate components. From www.cnblogs.com/coco1s/p/57… Shadow-dom is a node tree outside the DOM tree, but its creation is based on ordinary DOM elements (non-document), and the created shadow-DOM node can be seen intuitively from the interface. More importantly, shadow-DOM is very airtight. The downside is that there are compatibility issues. Also, some frames have nodes that go into global documents, such as popovers. ShadowDOM will then be deactivated.

5) How do applications communicate with each other

Get straight to the solution:

  • Url and the cords
  • Establish a global publish subscribe pattern
  • Pass through props

6) How to build a global state controller

Actually solved the above problem “how to communicate between applications “, this problem already has a solution. Simulate vuex or React-Redux to write a state central manager, and all that’s left is to notify each child of communication problems. The child application believes that the framework also has its own state manager. At this point, you have a central manager.

Answer micro front-end questions

1) What are the main problems to be solved in building a micro-front-end framework?

Consider this illustration from github, once the official qianku website:

As can be seen from the legend, a micro front-end framework needs help dealing with:

  • 1.JS sandbox environment, so that sub-applications do not affect each other
  • 2.CSS isolation, so that the child application style is not affected by other.
  • 3. Communication between different applications.
  • 4. Consider parallelism and nesting of applications.
  • 5. How to track the life cycle of all projects.
  • Legend and so on

Specific to do what, also have to source analysis, interested in the source code, can refer to:

  • www.sohu.com/a/388645157…
  • Blog.csdn.net/lunahaijiao…

2) What are the ways to build the micro front end?

The construction methods of the micro front end can be roughly classified into two types:

  • 1. Base mode

This mode, the base mode, basically undertakes the application foundation and core technology of the micro front end, which is a system constructed by a main application and a series of sub-applications. In addition, the master application manages other sub-applications, including life cycle and communication mechanism, which need to be initiated by the master application.

Basically, a lot of third-party frameworks are built around this model.

  • 2. Self-organization mode

Each has a small “base”, each subsystem of the system in accordance with a certain rule between the formation of a certain structure or function. The design of the scheme is far more complex than the pedestal.

3) Micro-front-end support for the framework?

Different third-party microfront-end frameworks do not support the usual framework. But basically can confirm, vuE-CLI 3.0 and UMI and other conventional frameworks, are supported. In addition, ordinary HTML and JSP pages, are also supported.

Type Vite, currently may need the help of unofficial toolkits. In addition, THE AUTHOR of SEO framework is also temporary verification, look at the forum is also feasible.

4) What are the disadvantages of the micro front end?

Personal opinion:

  • 1. Improve technical risk. Microservices have long been suspected of causing more problems than benefits when isolated incorrectly. The same goes for the micro front end.

  • 2. Technology becomes more expensive. The tracking of a problem may require a corresponding person who understands the micro front end, master application and sub-application, and each framework. Sometimes you need to dive into both VUE and React and the micro front end to solve the problem.

  • 3. Complexity of procedures. It is easy to start embedding, but difficult to maintain. May be desperate, write a framework; Later, “experts” came and withdrew from the framework of secondary transformation. However, not wanting to be constrained by the second framework, a third framework was introduced. Make the relationship of application more and more complicated.

5) Why not use iframe?

As mentioned above:

Regardless of the experience, iframe is the best microfront-end solution. Iframe is the lowest cost and least risky solution when other solutions are unreliable or incompatible.

However, if there is a better solution, we need to try to replace, after all, the disadvantages of iframe are very obvious.

Most of the micro front-end solutions have abandoned the IFrame solution for a reason, and it’s not for “show-off” or “maverick”. After all, this is the age when user experience is god.

Almost every micro front-end framework will say, Why Not Iframe?

For example, qiankun: www.yuque.com/kuitos/gky7…

The author summarized the following to learn that the micro front-end is not suitable for iframe only scenarios:

  • 1. If the browser refreshes the IFrame URL status, the back forward button is unavailable.
  • 2.DOM structures are not shared. Imagine a page that consists of different iframes, and the popover of the page is centered, only within the corresponding IFrame, not across the browser.
  • 3. There is no concept of state manager. Memory variables are not shared. Data needs to be transmitted, only through cookies, etc., and all iframes need to be refreshed to have the final effect.
  • 4. All resources need to be reloaded. There will be a lot of new requests.
  • 5. Information embedded in iframe cannot be captured by SEO.
  • 6. Multiple Iframes. When each iframe is exceeded, its own scroll bar will appear, leaving people confused.
  • 7. When waiting for interaction, you cannot add dynamic effect and can only wait in blank screen.
  • 8. Iframe blocks page loading and cannot be processed asynchronously.

other

conclusion

1) Recommendation of relevant articles

  • Micro front-end framework of single – spa from entry to master: https://juejin.cn/post/6862661545592111111
  • Micro front end, micro front end framework: www.sohu.com/a/388645157…
  • Hand write a micro front end frameBlog.csdn.net/lunahaijiao…
  • Early chat: juejin.cn/post/684668…

2) Actual combat prospect

We are building an actual battle case of Qiankun. At present, we have just built a simple interaction, but it is not perfect and in-depth.

In the future, sub-applications will include vue2.0, Vue3.0, Vite, UMI and other frameworks. It also includes custom global status managers, global keep-active controls, and more.

We will publish articles to share the whole building process, please look forward to it.

Project address: github.com/zhuangweizh…