The front end early chat conference, the new starting point of the front end growth, held jointly with the Nuggets. Add wechat CodingDreamer into the exclusive inner push group, win in the new starting line.
The 14th | front-end growth promotion, 8-29 will be broadcast live, 9 lecturer (ant gold suit/tax friends, etc.), point I get on the bus 👉 (registration address) :
The text is as follows
This article is the seventh micro front end, front end early chat 42, from ant Financial service experience technology department Qiankun core contributor – Fang Huan share – brief presentation version (complete version including demonstration please see the video and PPT) :
First, self introduction
Hello, everyone. Today, I will bring you the last session of this micro front-end topic, “How to Design and Implement micro Front-end Framework – Qiankun”. First of all, I’d like to make a brief self-introduction.
To introduce myself
My name is Fang Huan. I use the head on the left on some platforms, such as The Zhihu and the Language Finch.
I am now a front-end engineer in the Experience Technology Department of Ant Financial, working with Youzhi to maintain and iterate Qiankun. We are also working on the next generation of ant’s internal front-end runtime platform, which is based on micro front-end technology.
Qiankun profile
Before we begin, I would like to give you a brief introduction to The foreground. You can see the introduction and documentation of Qiankun on the official website of < umijs.org>. As this screenshot shows, we define the foreground in one sentence: “Probably the most complete micro front end solution you’ve ever seen,” it has the following three features:
• simple. No matter what technology stack you are in, or what JS framework you are using, You can use Qiankun to connect your sub-applications to your framework application. The access is as simple as accessing an Iframe system.
• complete. We have encapsulated a lot of capabilities based on single-SPA. Some of the problems you have in building micro-front-end systems, such as style isolation, sandbox, preloading, etc., are all built into Qiankun, so it is a complete micro-front-end solution.
• Production available. So far, there are about 200+ apps using Qiankun to access their own micro front-end system. We have been tested with a large number of online systems in and out of ants, so it is a reliable production available solution.
Qiankun got his name
Many may wonder how the name Qiankun came to be. It actually comes from the saying, “Big things happen in small worlds.” We hope to make a big difference in the small world of the micro front with the framework of Qiankun.
The birth and design concept of QIANKUN
In the first section, I will talk to you about the birth of Qiankun and how he came to be. What does Qiankun think of the micro front end? What is the most important thing in the micro front end?
Origin: a unified shangyun campaign
The origin of Qiankun is actually a campaign to unify Shangyun, but it is not important what the campaign is. You can see in this picture the console that we created for this campaign, which is divided into several sections by red boxes, you can see the navigation head at the top, the menu on the left, the help guide on the right, and the access product in the middle, which is the main body of our sub-applications.
Console structure
So if I abstracted the console, this is what it looks like.
The navigation head at the top, the identity and the sidebar on the left, the novice guide, all add up to our main app, or frame app. And the box in the middle is the body of the application, the body of the application, which is the set of sub-applications that we’re accessing, which could be application A, application B, application C, and so on.
We’ve integrated all of these applications into one big console application, and that’s what we’ve done. This is a typical application scenario for micro front-end technology, so Qiankun took its first steps on this project.
We need a “friendly” micro front end solution
For this project, the micro front-end solution we need can be summarized as a “friendly” micro front-end solution, so what is a friendly micro front-end solution? We distilled two requirements:
- Technology stack independent. That is, our micro front-end solution should not restrict the technology stack, we should not require that our child applications be React technology stack, Vue technology stack, or Angular technology stack. Besides technology stack should be limited, we need to terminate the application between some implicit data, because sometimes even though we have no limit application technology stack, but is likely to have some coupling between our applications, these coupling occurs in many ways, we need to eliminate the coupling, can achieve technology stack.
- It’s easy to access and works just like an iframe. As you know, iframe use is very simple, I just create an iframe tag and embed my page in it. If our micro front end solution can be as simple as iframe, we can avoid old app retrofit as much as possible. As you can see, in our previous campaign, which was our cause, we had to plug a lot of applications into the framework, into the console, and that involved a lot of application remodeling, and we wanted to minimize the amount of application remodeling, otherwise we would be very tired.
Technology stack independence
This is what Qiankun sees as the core value of the micro front end. Many of the technology choices facing Qiankun, and the eventual implementation, are stack independent. When we think: “in a lot of solutions, which one was chosen by The Last Qiankun”, we will think which one is the most technology stack irrelevant, the most technology stack irrelevant scheme, is often the final choice of the scheme.
Why is “stack independence” important
As an example, if we want to make A unified console, let’s call it ABC, and then the console needs to be plugged into three different projects: Project A was created A month ago and is still in active iteration. Project B was probably built a year ago and is now lacking in maintenance. Of course the most difficult project is probably Project C, which is probably a three year old project that is no longer maintained.
I listed the technology stacks of these projects, and you can see that there are big differences between them. Maybe project A is using the latest React version, using the latest technology stack, and even using Webpack5 as the packaging tool ahead of time. At the same time, project B is probably the mainstream technology selection you had a year ago, and Project C is already a very old technology stack. In this case, if our micro front end solution is related to the technology stack, it will be necessary to upgrade Project B and transform Project C, and such costs are often unacceptable when we are working on the ABC project. In addition, over time, project B will become unmaintained and the Project A technology stack will become obsolete.
Therefore, only by making the technology stack irrelevant can we ensure that after a long time, our unified console ABC can continue to maintain steadily, or can be securely connected to new projects.
Yu Bo has a comment on the micro front: the premise of micro front or main application, and then there are micro components or micro applications, to solve the controllable system under the front-end collaborative development problem. There are two parts to the development problem here: one is the collaboration that comes with space separation, and the other is the upkeep that comes with time. The collaboration that comes with separation of space requires that micro-front-end solutions can provide independently developed, independently deployed features to address the collaboration problem. And time brings the continuation of the need for us to do technology stack irrelevant, as time goes by, when our technology stack is old, or normal access to our framework applications.
The value of “stack independence.
Perhaps everyone is familiar with the mission of Ali: to make the world no difficult business. And technology stack irrelevant value, also is qiankun slogan: let the world no short-lived console.
- We do not limit access to the front-end technology stack, to achieve a wide range of access.
- We’re going to be able to do backwards compatibility, and we’re going to be able to do it with older applications.
- We can also achieve forward compatibility with this stack independent architecture, which is stable and future-oriented.
Technology implementation and selection of QIANKUN
After a brief talk about what Qiankun stands for, let’s talk a little bit about the specific technology implementation and what we chose to use to implement the micro front end.
Two common problems faced by micro front end frames
Virtually all micro front-end frameworks face these two common problems. Once you have solved these two problems, your micro front-end framework will be almost ready to run.
- The first problem is application loading and switching. Including route processing, application loading processing and application entry selection.
- The second problem is application isolation and communication. These are the problems that the application faces once it has been loaded. They include JS isolation (that is, side effects isolation), style isolation, and communication between parent and child applications.
Apply routing and Future State
First let’s look at the problem of application routing. In a micro front end architecture, routing is often divided like this, which is also a relatively simple solution.
Our main application loads app A and app B. At this point for the main application, I have two routes /a/* and /b/*. I’m going to load application A under route A, and application B under the other route B.
What happens when I redirect the page under routing /b/list? I actually need to load my main app first, and my main app detects that this is a route that starts with /b/, so it knows that I should load application B, so it loads application B. At this point, application B takes over the route, and it finds that the next route is /list, so it displays the correct page for /list, and that’s the whole process.
If you don’t do something about it, you’ll end up with a 404 and a routing error when you first load the main application, because the routing system for application B hasn’t been loaded and you don’t know what the /list needs to display. This is actually the problem with lazy loading. Early on the Angular community called this problem Future State. The easy way to solve this problem is to hijack the routing system and do some reworking. Also, by using a routing library like React-Router, you can also use its dynamic routing scheme.
Established programs in the community
In The case of Qiankun, we have directly chosen the mature solution of single-SPA in the community. Single-spa has hijacked the route, helping us with the loading thing, and helping us with the routing switching thing, so we don’t have to build our own wheels.
Application access: protocol access
And since we’re using single-SPA, it helps us solve another problem: application access.
What kind of application can be a sub-application that plugs into our framework? Since we need technology stack independence, we want the access to be a protocol access. As long as your application implements three lifecycle hooks: bootstrap, mount, and unmount, our framework application will know how to load the child application with these three functions exported
These three hooks also happen to be lifecycle hooks for the child application. When the child application is mounted for the first time, we will do some initialization by bootstrap and then mount it. If you are a child application of the React stack, you might write ReactDOM. Render inside the mount to mount your ReactNode to the real node and render the application. When you switch off the application, we will unmount the application and when it comes back (typical scenario: You jump from app A to app B and then back to app A after A while. At this point, we don’t need to re-execute all the lifecycle hooks. We don’t need to start with bootstrap.
App Entry choices
In this regard, Qiankun is faced with some other choices. One of them is App Entry, which is how to design the loading Entry for sub-apps. There are two choices we have to makeWhen to assembleThe other isWhat is the entrance to the loader application.
Combination timing
We have two options when it comes to timing the combination. The first is to package the master and child applications together at build time, which is essentially a multi-package solution. The advantage of this approach is that we can do common dependency extraction at build time, but the disadvantage of this approach is that we are coupling the master application build solution and the tool together, which is very inflexibly, and thus does not allow dynamic loading. So in most cases, we choose to combine at runtime, which is when we dynamically load the child application, load it, and render it into the framework application.
Application Entry: HTML Entry
Then how to choose the entrance of our sub-application? Qiankun chose HTML as the entry point.
When loading a child application, we actually need to provide a list of resources. In this resource list, we may list which JS and CSS the child application uses.
But Qiankun’s first choice is actually an HTML portal, which provides an HTML file. Because this HTML actually contains all the information for the child application. It contains the structure of the web page and contains some meta information. So you can see that in this HTML we have CSS, WE have JS links, we have a DOM that has the root route that the application is going to mount to root. This information is very comprehensive, and much clearer and more complete than if you just put together a list of resources with JS and CSS as entry points. At the same time, the design of HTML Entry also makes it easier for us to access some old applications.
Application Entry selection
Here’s a simple comparison. Using HTML Entry allows you to decouple the child application from the main application. However, if you choose a resource list or JS as the entry point for the child application, the DOM node will need to have a convention with the main application when the child application is mounted, which creates a degree of coupling.
Apply isolation: JS sandbox
In fact, with those choices, especially with the single-SPA capability, we’ve basically solved the loading and switching of the application. The next piece of the puzzle is application isolation and communication.
The first one is the isolation of the application, and the first one is the isolation of JS. In this case, sometimes you can run without isolation, but if you use single-SPA without isolation, if there is a conflict between applications, your application is likely to die, so the JS sandbox is necessary in most cases.
In the implementation of the Sandbox qiankun, we will have two environments: one represents the external part, our Global Env, which refers to the Global environment in which your framework applications run. When a child app loads, it should actually run in an internal sandbox, the Render Env shown here.
There are two ways to implement sandboxes: one of the most classic practical ideas is actually snapshot sandbox.
Snapshot sandbox is used to record snapshots during sandbox mounting and unmounting, and restore the environment based on snapshots during application switchover.
When my child app loads and starts, the Environment is actually Render Environment, which is the internal sandbox Environment. At this time, I record the snapshot state at that time. When I finally applied unmount, I compared the current environment to the recorded snapshot to restore it to its original global state. What this means is that when I mount and uninstall my application, I go through the process and my entire Windows environment is restored to its original form. Any changes made in the application will be restored when it is uninstalled. This is the snapshot sandbox idea.
For example, if we append A global variable to A while application A is running, we say window. A = 123. In this case, window. A becomes 123, but after application A is uninstalled, the snapshot is restored and window. A is deleted again. You don’t see the a variable any more in the global environment
How to create a snapshot? There are actually two ways of thinking about it:
One is to use Windows Diff directly. Compare the current environment to the original environment, we run two cycles, compare the two environments once, and then go back to the original environment in full.
Another way of thinking is to actually use ES6 proxy. By hijacking window, we can hijack some modifications to the global environment made by the child application. When the child app hangs things on the Window, modifies things, and deletes things, we can record what we do. When we get back to the outside global environment, we just need to reverse the previous operation. Let’s say we set a new variable inside the sandbox window.a = 123. So when we leave, we just delete the a variable.
Snapshot sandbox is the same idea used in Qiankun1.0, it is relatively perfect, but the disadvantage is that I can not support multiple instances, that is, I can not mount two sandboxes at the same time, otherwise the two sandboxes will fight, resulting in errors.
So we’re looking at another idea, which is to separate the environment inside the sub-app from the environment outside. As shown in the figure, our application A lives in the sandbox of APPLICATION A, and application B lives in the sandbox of application B, without interference between the two. In fact, the implementation of this sandbox is also realized through the proxy feature of ES6.
Apply isolation: Style isolation
Either the snapshot sandbox or another proxy sandbox can resolve side effects between JS. After resolving JS, the next step is to resolve CSS conflicts.
There are two types of style colliders in a micro front-end framework: one isMaster application style conflict, your main application and your child application will have a style conflict, and the other isStyle conflicts between sub-applicationsWhen you mount application A and you mount application B, the two applications are flat and the styles clash.
Style isolation: Dynamic Stylesheet
The first thing That Qiankun did was actually a dynamic style sheet. When you switch from child A to child B, you need to remove the style sheet from child A and mount the style sheet from child B. This avoids the need for both the style of subapplication A and the style of subapplication B to exist in the project at the same time, thus achieving the most basic isolation. When you switch from application A to application B, your styles will naturally switch from application A to application B, and we will automatically remove and load the styles for you. Of course, the only way to do this is to ensure that you don’t have conflicting styles between sub-applications in single application mode (that is, when only one application is active at the same time).
Of course, after the implementation of dynamic stylesheets, we still haven’t resolved the style conflicts between the master and master applications. In fact, the best way to solve this problem is to use some engineering method, such as BEM, which means that if you apply A style, you will use A prefix of A -, if you apply B style, you will use A prefix of B -, and your framework application will use A prefix of A. Using conventions (such as the convention that everyone prefixes the application name) to avoid conflicts is a very effective solution. Especially in the case of conflicts between master applications, most of the time you just have to make sure that the style of the master application is modified, that the style of the master application is very concrete, that it doesn’t conflict with the child application, and then the conflict between the master application is actually resolved. However, such schemes rely on conventions and can easily slip up.
Style isolation: an engineering approach
The current CSS module is very mature in that it is compiled to generate non-conflicting selector names. You can simply take the application you want to avoid conflicts and do so with the CSS Module (which is done by adding a CSS preprocessor to the build tool). Once a CSS module is built and packaged, the names of selectors are different between applications, so they don’t conflict with each other.
Css-in-js is also a popular way to code styles without conflict. None of these schemes are complicated to implement, and all of them work very well. So in most cases, the problem of style isolation can be solved by using an engineering approach to address style conflicts between master and sub applications.
Style isolation: Shadow DOM
Of course, when we came to qiankun2.0, we added a new option called strict style isolation. I don’t know if you have used it.
In fact, strict sample isolation stands for Shadow DOM. Shadow DOM can truly achieve complete isolation between CSS. Under the Shadow Boundary barrier, the style of the main application and the style of the sub-application can be completely separated.
But for the most part, you can’t mindlessly turn on strict style isolation. For reasons that have already been mentioned, for example, when you use some popover component (which is often added to document.body by default), it skips the shadow boundary and goes into the main application, and the style is lost. Let’s say your child application is using the React stack, and the React event proxy is actually hung on the document. So in practice, when you turn on Shadow DOM, your child application may encounter some strange errors, which you need to manually fix one by one, which is a tiring process.
We provide Shadow DOM as a style isolation. But in practice, the engineering approach is the most reliable and simple. Of course, you can still try to turn on strict style isolation if you can, because this is the real isolation.
Style isolation RFC: Runtime CSS Transformer
Qiankun also received a proposal that would allow us to change CSS dynamically at runtime.
For example, if the style in the subapp is like this, we can add a restriction to it. We can only apply the. Main style in the subapp data-qiankun-app1 (this div is the outer container of the subapp). With such a runtime transformation, we can also achieve style isolation. The problem with this solution, of course, is that the transformation is not easy to do, first of all we add some runtime overhead, and second of all for some media queries, for some animations it is very possible to do some unexpected things. This RFC has not been merged so far. What do you think about it? Welcome to your opinion under PR.
In our JS sandbox to solve the side effects between JS; Once CSS conflicts have been resolved, either by engineering, dynamic styling, or by turning on Shadow DOM, it’s time to consider communication between applications.
Application communication: BASED on URL
In fact, one of the most naive communication solutions is based on URLS. There’s a front end design called URL-centric design, where your URL completely determines how your page looks.
If I have a list in my application, and I have a page, when you click the next page, does that generate a query parameter on the second page? You might want to sync this parameter to the route so that when you share the link with others, they will see the same page as you.
We can actually translate this route as a function call, for example, route b/function-log, query parameter data is aaa, we can interpret this route URL as I am calling the log function applied by b, which is like a function call. When we jump from application A to application B, and the corresponding route changes, it triggers A function call, it triggers A communication.
So routing actually has the ability to communicate. This communication mode is completely decoupled, but the disadvantage is that it is weak.
Application communication: publish/subscribe model
Another model for inter-application communication is that we can hook up an event bus. Instead of directly interacting with each other, I register and listen for events on the event bus, using a publish-subscribe model to communicate with each other.
Interestingly, we don’t need to introduce any framework, we don’t need to introduce any third-party libraries, we have a natural event bus here: Window’s CustomEvent. We can listen for a custom event on the window, and then send a custom event anywhere. We can naturally use custom events to communicate with each other.
Application communication: Props
The third option, which is actually props, is a familiar pattern.
If you’ve ever written React or Vue, you know that when we write an input, we give the props for value and onChange to the bottom input box. We can do the same here, our main application can pass props to children. We pass the state and onGlobalStateChange (which is the listener) and our onChange (which is setGlobalState) to the child application. We can also implement a simple communication between master and child applications based on props.
So when we have master and sub-application communication like this, what do we do with sub-application and sub-application communication? Just have everyone talk to the main app. Let’s not add another communication link between the sub-application and the sub-application. We can all communicate with the main application based on props, and that will solve the communication problem.
Application of communication
Qiankun itself provides the simplest API for props communication at 2.0.
Even before we provided the API, we had a lot of students asking us how should we communicate between applications? We didn’t have a specific solution, we didn’t have a specific API, we didn’t have a specific practice or guidance. In fact, depending on the requirements and complexity of your application, you should choose your own inter-application communication solution accordingly.
In the case of Qiankun, what matters is whether your application is stack independent, that is, whether the coupling between the application and the application is as weak as possible. From this point of view, if we communicate based on custom events, that’s a very weak coupling. I don’t rely on anything in particular, I just borrow the browser’s native API, technology implementation bus, and when I disconnect from it, my application is able to work on its own. If we specify a global variable on window, or if we make a global Redux, and everyone goes to this data source to consume data, then this might be a strongly coupled solution.
The specific communication scheme needs to be decided according to the actual situation and business scenarios faced by everyone.
Qiankun did not answer engineering and platform questions
As you can see, Qiankun does a lot of things for you, but it doesn’t help you complete all of them. It doesn’t mean that all the problems in the micro front are solved once and for all with the use of Qiankun. # Kejun mentioned the whole big picture of the micro front end in D2’s micro front end special session. He layered the whole micro front end system into a lot of modules. The piece solved by Qiankun is actually the runtime container of the micro front end, which is a part of the whole micro front end engineering.
In this sense, Qiankun is not a complete micro front-end solution, but a complete solution for micro front-end runtime containers. When you use Qiankun, you can solve almost all micro front-end runtime container problems, but more engineering and platform problems.
How you manage your version, configure your release, monitor your release, check your security, etc., is not something that qiankun as a library can answer. These problems still depend on your specific situation, to choose their own suitable solution. This also needs to do some infrastructure construction investment in the micro front end, in order to better answer the engineering problems and platform construction problems.
The development and future of QIANKUN
The last section will talk about the development of The qiankun, and what the future of the Qiankun will be like.
Qiankun journey review
Let’s start with a brief history review.
- Qiankun was released in June last year in version 1.0, and the official platform announcement at that time was probably the most complete micro front-end solution you’ve ever seen.
- In December of last year, at the D2 Technology forum, in the micro front end special session, you can find a talk, standard micro front end architecture in ants landing practice.
- In April of this year, we released version 2.0. In these two articles and speeches, you can have a more detailed understanding of the design of Qiankun and the landing practice of Qiankun.
- As of today, Qiankun has accumulated about 5.1K star. We have also been recognized by the single-SPA team, and we have been selected by many teams, such as the previous Flying Pig team, as a part of their micro front-end system.
Two forms of micro front
In fact, at the earliest release of Qiankun 1.0, we thought the micro front end would come in two shapes.
In the business scenario we solved, in the first appearance of Qiankun, it was actually a single instance scenario. We only have one application running on the console at the same time, so we’re going to switch from application A to application B, and from application B to application C, but we’re not going to have both application A and application B mounted on the page at the same time, so it’s A single-instance scenario.
We actually think there is a multi-instance scenario for the micro front end. You can mount more than one app on the same page. You can have app A, App B, app C, and App D all on the same page.
The question is, what’s the difference between an application and a component? It is also like before mentioned, some students weiget or micro module, because in the following application is often does not have its own routing, has nothing to do with the routing, it is like a component to a certain extent, this part of the page is a component or a micro application, show the gap is not big.
So how do you say you are a component, and how do you say you are a micro application? For us, we think we can develop independently, deploy independently, and we can complete some functions independently, which is actually a micro application. It’s similar to what Weiget or micro modules can do. There’s no clear line between the two. You can either upgrade a component to an application or make an application into a component, depending on your scenario and choice.
[email protected] shift
When we decided to support multi-application and multi-instance scenarios in Qiankun 2.0, in fact, the positioning of Qiankun was also quietly changed, which is why the API of Qiankun 2.0 is still largely compatible, but it is a major change.
What started out as a routing-based micro front-end framework is now actually a micro application loader. You can use [email protected] for more flexible loading of microapplications. We provide componentization loading capability to support more complex application arrangements and support more micro front-end application scenarios.
[email protected] microapplication
Let’s take a look at the code: how to load a micro application with the qiankun2.0.
We provide a new API loadMicroApp, through which you can load a microapp. We can simply encapsulate a MicroApp React component based on this API. Once I got the MicroApp component, we could use it very easily.
For example, with a routing library like react-Router, we can choose to mount components on a particular route. This scenario is very similar to the single instance scenario, which is a routing level scenario, just like [email protected]. Another way we can use it is we can use it as A component, we can mount application A and mount application B on the same page at the same time, we can mount multiple applications in the same scenario, so it’s A component level use.
So what’s the use of going from a single-instance scenario to a multi-instance scenario?
Microapplications: Mixed r&d
One scenario is hybrid R&D.
Now with the development of the front-end, actually a lot of people in thinking through the low effect question, code, we have some more mature low code platform, such as cloud swallowtail butterflies, you can rely on drag drag, make a good background in the page, there are some configuration platform, is that you rely on some json configuration, configuration, some data, You can generate the front page
But at the same time, there are some scenarios that can only be supported by ProCode that the low-code platform can’t support. Chances are you have two scenarios in one app, and you can treat them as two different microapps. LowCode microapplications and ProCode microapplications. You can put both in one project and load both with the Qiankun for a kind of hybrid R&D. This way you can enjoy the rapid development of NoCode or LowCode while enjoying the full capabilities of ProCode, and if you find that the LowCode doesn’t meet your needs, you can seamlessly switch to ProCode with a backdoor.
Welcome to join
Finally, Qiankun is very welcome to participate in the construction, you can come to Github if you have any problems. Please join our networking group in Qiankun and share your thoughts with us. In the future of qiankun3.0, we look forward to your participation and cooperation.
Books recommended
The last part is to recommend a book, and the book I recommend today is The World of Programming by Yukihiro Matsumoto. This book gives you an in-depth understanding of the story behind the programming.
QA
Our comments section was very hot, with lots of questions. Because of the time, we only have four opportunities, so you can care about whether your questions are answered.
Is the framework not concerned with dealing with possible co-dependence between micro-applications? How to solve the problem of public dependency?
The Qiankun itself is not helping to deal with public dependency. This can be done with built-time tools such as simple externals and libraries, or you can try Webpack5’s federated modules, or use features such as Import Maps to do this. Qiankun is also exploring this area, including we are also thinking about how to integrate with Webpack5’s federation module, we may have some practice on this in the future. If you have any good practices, please share them with us. But at the same time we have another point of view, do you really need to bring these dependencies up? A lot of times you have different versions of the dependency libraries between your applications, and these are different versions of the dependency libraries that you can think of as part of your application, and when you put them out there, you actually create some coupling between your applications.
Fang Huan: Is there a recommended disaster recovery mechanism for the primary application when the sub-application service is abnormal?
I think it depends on the specific scenario and business requirements. Because of subapplication exceptions: One possibility is that your code is wrong and the subapplication dies. In this case, your main application may only be aware of some unusual failure in the subapplication, so you know that the subapplication is down, and you can do some reporting, or you can try to do some recovery. Or maybe you want to do some monitoring practice, you want to catch some runtime errors in your subapplication, whether it’s reporting something less than a crash, and you want to record it. In fact, Qiankun itself is not concerned with this. You can implement the logic yourself.
Q: How was Qiankun introduced into the old project? For example, how do the main application routes connect? How should the styles now be isolated?
Your scenario should be that you already have an app A and you want to introduce app B into your app A through Qiankun as A child app. In this scenario, it’s actually A little easier if you’re in app A, which is your main app, and you assign A separate route to app B. Because Qiankun is actually checking to see if the matching sub-app is active after the main app is loaded. If the child application is active, we will mount the child application and then route to our own child application. So the easiest way in this scenario is to assign a route to your subapplication.
The problem of style isolation, we just talked about it. This can be done in two ways: one is to use some engineering means, whether it is convention prefixes, or using CSS modules to do some modifications to avoid style conflicts between master and child applications. You can also try to turn on strict style isolation and use the Shadow DOM approach to make the subapplication styles truly isolated, but your subapplication may encounter new problems that you need to solve.
The address of the image in the old project was a relative path. When loading the image, the domain name and port of the address changed to the address of the main application. How to solve this problem?
You can take a look at this by Posting issues on Github.
