The original address

It has been 11 months since qiankun was open source, and 8 months since the last official release.

Announcing [email protected]

In June 2019, the micro front-end framework Qiankun officially released version 1.0. In less than a year, we gained 4K + Star, received greetings from the single-SPA official team, and supported ali 200+ online application. It has also become a micro front end solution chosen by many teams in the community.

Today, Qiankun will officially release version 2.0.

With a few new capabilities and minor API changes, [email protected] will make it easy for 1.x users to migrate to 2.x. See the upgrade Guide section below for details.

Qiankun profile

Some friends may not know what the micro front and Qiankun are.

Micro front end is one of the most frequently mentioned keywords in the domestic front end field in recent years. While it is not a completely new field/technology, it is clear that in the context of more and more front end applications entering their third, fifth and even longer years, How to inject fresh technical blood into Stonehenge/legacy applications has become a problem we have to face, and the micro front is a very suitable solution to solve this problem.

Qiankun is a production-usable micro-front-end framework based on single-SPA with js sandbox, style isolation, HTML Loader, preloading and other capabilities required for micro-front-end systems. Qiankun can be used with any JS framework. Micro-application access is as simple as embedding an Iframe system.

More information can be found on our official website

Orientation change

The biggest change in Qiankun 2.0 is that it will be positioned as a micro app loader instead of a micro front end framework.

Previously, The typical application scenario of Qiankun was a Route-based console application, which was used as a micro-application aggregation framework.

In this scenario, as shown in the figure above, a single main app that aggregates and switches together with multiple separate microapps makes up a large micro front, and typically only one microapp is active on the page.

This is one of the scenarios of the micro front end. In other scenarios, you should be able to load multiple different microapplications on the same page, each of which is part of the main application or provides some enhancement. This scenario is called the componentization of the micro front end with the granularity of the micro application.

Therefore, [email protected] will jump out of the route-based micro front end scenario and provide more general micro-application loading capability, so that users can more freely combine micro-applications to build products.

What does this upgrade bring?

New features

  • Support multi-application parallel and multi-instance sandbox
  • Supports manual loading/unloading of microapplications
  • Support IE11 sandbox compatibility
  • The official minimalist microapplication communication solution
  • Support for style isolation based on Shadow DOM

And we also did

  • Upgrade single-SPA to version 5.x
  • More flexible prefetch customization policy
  • The webPack plug-in
  • Support for more user-friendly deployment scenarios, such as automatically injecting runtime publicPath into microapplications
  • A simpler API, and a lot of code refactoring to make it cleaner and more extensible
  • Fixed some bugs

In addition, we have upgraded the corresponding Umi Qiankun Plugin. In the Umi scenario, you can load a micro app like this:

import { MicroApp } from 'umi';

function MyPage() {
  return (
  	<div>
      <MicroApp name="qiankun"/>
    </div>
  );
}
Copy the code

Release the log

Multi-application support

At [email protected], our sandbox, style isolation and other mechanisms only work for a single microapplication scenario, and support for coexistence of multiple microapplications is not yet complete.

In version 2.0, we’ve finally improved this feature, and now you can activate multiple microapps at once, while the microapps are not interfering with each other.

** In multi-application scenarios, the sandbox of each microapplication is isolated from each other, which means that the global impact of each microapplication is limited to the scope of the microapplication. ** For example, if application A adds A new property to window, the property can only be accessed in the scope of application A using window.test.

Note, however, that you cannot display multiple router-dependent microapplications on the page at the same time, because the browser has only one URL. If multiple router-dependent microapplications are activated at the same time, there is a high probability that one of them will result in a 404.

To make it easier to load multiple microapps at the same time, we provide a new API loadMicroApp for manual control of microapps:

import { loadMicroApp } from 'qiankun';

/** Manually load a microapplication */
const microApp = loadMicroApp(
  {
    name: "microApp",
    entry: "https://localhost:7001/micro-app.html",
    container: "#microApp"})// Uninstall manually
microApp.mountPromise.then((a)= > microApp.unmount());
Copy the code

This is also how Qiankun is used as an application loader.

Based on this API, you can easily encapsulate your own microapplication container components, such as:

class MicroApp extends React.Component { microAppRef = null; componentDidMount() { const { name, entry } = this.props; this.microAppRef = loadMicroApp({ name, entry, container: '#container' }); } componentWillUnmount() { this.microAppRef.mountPromise.then(() => this.microAppRef.unmount()); } render() { return <div id="container"/>; }}Copy the code

Internet Explorer 11 compatible sandbox capability

In the Qiankun Issue area, the most popular voice is IE compatibility, there are a lot of friends are looking forward to Qiankun can be used in IE.

The main obstacle to the use of Qiankun 1.x in IE is that the sandbox of Qiankun uses ES6 Proxy, which cannot be remedied by ployfill or other methods. As a result, the Internet Explorer user Qiankun cannot enable the sandbox function in Qiankun. As a result, JS isolation and style isolation cannot be enabled.

To this end, we implemented an Ie-specific snapshot sandbox for browsers that do not support Proxy; This does not need to be manually enabled by the user, and in environments where the agent sandbox is not supported, we will automatically demote to the snapshot sandbox.

Note that since snapshot sandboxes cannot be completely independent of each other, we do not support multiple application scenarios in IE and other environments, and singlur will be forced to true.

Style isolation based on shadow DOM

Style isolation is also an important issue facing the micro front. At [email protected], we support style isolation between microapplications (it only works when the sandbox is open). There are a few issues:

  1. Style isolation between master and child applications depends on manually configuring plug-in processing
  2. The style isolation between microapplications in multiple application scenarios needs to be addressed urgently

To do this, we’ve introduced a new option, the Sandbox: {strictStyleIsolation? : Boolean}.

With this option on, we will embed the microapplication in Shadow DOM to achieve true isolation of application styles:

import { loadMicroApp } from 'qiankun'

loadMicroApp({xxx}, { sandbox: { strictStyleIsolation: true}});Copy the code

Shadow DOM allows for true style isolation (rather than relying on isolation of assignment prefixes) in the following form:

Image from MDN

When strictStyleIsolation is enabled, we will insert the microapplication into the Shadow Tree created by Qiankun. All the microapplication styles (including the dynamically inserted styles) will be mounted under this Shadow Host node. Therefore, the microapplication styles will only be applied inside the Shadow Tree, thus achieving style isolation.

However, having Shadow DOM enabled causes other problems:

A typical problem is that some components may insert a node over the Shadow Boundary into the external Document Tree, and the style of that node will be lost. For example, antD’s Modal will render the node to ducument. Body, causing style loss; For just antd scenes you can through the ConfigProvider. They provide getPopupContainer API to the node at the specified within the Shadow Tree mount node, but also some other component library, or some of your code also encountered the same problem, I need you to pay extra attention.

In addition, in the Shadow DOM scenario, there will be some additional issues such as event handling and boundary handling. In the future, we will gradually update the official document to guide users to enable the Shadow DOM more smoothly.

Therefore, determine whether to enable shadow DOM style isolation based on the actual situation and perform appropriate checks and handling.

The official minimalist communication scheme

In the micro front end scenario, we believe that the most reasonable communication scheme is to handle through URL and CustomEvent. However, in some simple scenarios, the props solution is more straightforward and convenient, so we provide the User at Qiankun with a set of apis to communicate between applications:

The primary application creates a share:

import { initGloabalState } from 'qiankun';

initGloabalState({ user: 'kuitos' });
Copy the code

The microapplication uses props to get the shared status and listen:

export function mount(props) {
  props.onGlobalStateChange((state, prevState) = > {
    console.log(state, prevState);
  });
};
Copy the code

See the official documentation for a more detailed introduction to the API.

What will we continue to bring to you

In addition to the basic routine maintenance, bugfix, we will try to go further:

  1. Officially supported Qiankun WebPack plugin, which solves some problems due to improper configuration
  2. Custom sandbox rules
  3. Micro-application nesting support
  4. A friendlier debugging experience
  5. In conjunction with Webpack5 Module Federation, provides official instructions or plug-ins
  6. More experimental experiments, such as micro-application rendering based on native Portal tags, and a lighter style isolation scheme based on runtime.

Upgrade guide

Version 2.0 tweaks quite a few of the internal API names, but the external API everyone uses doesn’t change much (it’s basically fully 1.x compatible), and you can do it in about 10 minutes.

Render changes to Container

import { registerMicroApps } from 'qiankun'

registerMicroApps(
  [
    {
      name: 'react16',
      entry: '//localhost:7100',
- activeRule: location => location.pathname.startsWith('/react'),
+ activeRule: '/react',
- render: renderFn,
+ container: '#subapp-viewport',},])Copy the code

Now you can simply specify a mount node instead of writing the render function yourself. In simple scenarios activeRule configuration does not need to write functions (of course, it does support custom functions), just give a prefix rule string, and support dynamic rules of the React-Router class. Such as /react/:appId/name (from single-SPA 5.x support).

Also, the applications that receive props have a new Container property, which is the DOM of your mounted node. This is useful for dealing with dynamically added containers and situations where Shadow DOM is enabled.

Note that the old Render configuration is still available, we have made it compatible for users who do not want to upgrade; However, Container does not take effect when Render exists.

The configuration of start changes. Procedure

Because we have introduced some new capabilities, because the configuration of Start has also changed:

import { start } from 'qiankun'

start({
- jsSandbox: true,
+ sandbox: {
+ strictStyleIsolation: true
+}
})
Copy the code

The new APIloadMicroApp

This API is used to manually mount a micro application

/** loadMicroApp(app: LoadableApp, configuration? : FrameworkConfiguration)Copy the code

See the multi-application Support section above for details.