brief introduction : Micro front end brings obvious benefits at the same time , Also facing the pain point . For existing sites , How to access a micro front end based on the old technology stack ? What kind of communication do you need
Microfront , This concept has been on various hot topics in China more than once , The problems it solves are also obvious , The pain points mentioned by these micro front ends are also very prominent in the projects that our team maintains .
But I always think , A new technology 、 wave , The most popular thing to be discussed is the outstanding thinking behind him .
" Micro front end is ...xx frame ,xx technology "
This kind of words is a little limited to this outstanding idea , I can only think of him as a layman , To rub the heat of the word .
In my projects and teams , There is already a very large stock of technology stacks and pages that are already running online , Any iterative upgrade must be careful , Be on the safe side .
so to speak , To a certain extent , These benefits of micro front end are from user experience and technical maintenance , The value to the business cannot be quantified , The implementation of this technology is guided by both the need and the need .
We must be in awe of the stock technology stack , Isolation , Several basic elements of controllable influence range , Then consider the implementation of micro front-end solution .
therefore , Under this basic element and guideline , To implement this new technology , We must fully understand the existing technical solutions of the current transformation site 、 The proportion and the capability difference provided by the current mature micro front-end framework , Don't copy and copy .
The projects that my team maintains are PC Operation background (Workstation), These platforms will exist in different countries , Different time zones , Different partners and so on .
If you need to develop a new page requirement , It's likely that the developers involved are from different teams , At this time, we need to ensure that the style of multiple management pages is unified while completing the existing requirements , Unified design standards , Component unification , It's very difficult to unify interactions .
When the business needs to be migrated to another workbench , Although it needs to be logical , But the navigation bar 、 The theme is different .
The current stock plan is to adopt Java Go straight ahead Template Render HTML, After the iterations of previous generations , There are already several pages produced by different technology stacks in different systems .
Although it's all React To achieve , But the predecessors are very able to toss , None of them are conventional React Developed in the form of components .
such as :
Facing such a technical background , Except for smiling and shouting MMP, Tearfully speaking words that I can't understand ( Existence is reason , It's not hard for you to do ?), We have to come up with such a landing plan .
First , Need a clear analysis of all pages of the site , General features that need to be loaded :
These are some of the common features that have been streamlined , Here is a brief introduction :
In addition, there may be the following page expansion capabilities :
Later, we looked at the general classification , The general loading process of the page should be like this :
Based on the above loading idea , The first thing to do is to close the page loading path , It is necessary to ensure that the loading entry of all pages is in a uniform Loader Next , Then we can process the loading life cycle of all pages systematically .
At the same time of convergence , It also needs to be open , Keep plug-in and open to the core loading path , Support different expansion capabilities at any time , Rendering technology stack access .
1 、 Plug-in mechanism
therefore , On the main path , adopt Loader Load the configuration for processing , This configuration provides context in the main path , And then it's for plug-ins to consume , As shown in the figure :
for instance , Take an independent JS Bundle For sub applications of type :
<div id="root"></div>
<script src="https://cdn.address/schema-resolver/index.js"></script>
<script src="https://cdn.address/schema-resolver/plugin/layout.js"></script>
<script src="https://cdn.address/schema-resolver/plugin/source-code.js"></script>
<script src="https://cdn.address/schema-resolver/plugin/micro-loader.js"></script>
<script src="https://cdn.address/schema-resolver/plugin/i18n.js"></script>
<script>
SchemaResolver.render(
{
micro: true,
host: "dev.address",
hfType: "layout1",
externals: ["//{HOST}/theme1/index.css"],
// host is cdn prefix, the resource maybe in different env & country
resource: {
js: "/index.js",
css: "/index.css",
},
},
{ container: document.querySelector("#root") }
);
</script>
Through the above Plugin introduce , You can open and consume different configurations .
Here's the introduction of Layout Plugin, The plug-in will consume hfType Field and then load the for Layout Resource provision Container Give it to the next link .
According to the configuration , The current page has opened the micro front end , that Micro Loader Will consume what is provided Container, And then set up the sandbox ( Here is based on qiankun), Provide again Container come out .
Finally, it's up to SourceCode Plugin Conduct Bundle Load run and render . If this is another rendering protocol or technology stack , It can be consumed by different plug-ins according to different configurations Container.
In the process , The plug-ins in each link are independent , pluggable .
such as :
If you don't load Layout Plugin Will not consume hfType Field , It's not going to Layout Plug in logic is injected into getContainer In the method , Then you'll get directly from the outermost layer Container Rendering , There will be no menu related information .
If you don't load Micro Plugin There will also be no logic injection into the micro front end , You don't build sandboxes , Then the page rendering process will continue in normal mode .
2 、 Secure migration
For projects that my team is responsible for , We can't do a one size fits all plan , So for the existing stock page , A complete analysis of the current stock of technology stacks is needed :
For the above stock page , We need to implement page level control online deployment from left to right in batches , Only after the left side of the project can be deployed can we make some modifications .
This kind of migration test needs to deal with a set of Automation e2e Testing process , At the same time, through batch migration, comb out Micro front end registry .
With these two process assurance and scope control , The online content of the current scheme is completely controllable , Most of the rest to deal with is more repetitive physical work , Coverage can also be quantified .
3、 Micro front end form
Move according to the above plan , So the expected micro front end shape will be :
stay SchemaResolver The registration and call paths in are as follows :
Look at the essence through technology , The outstanding thinking represented by the micro front end , That's the key to solving specific problems , Only by solving specific business problems , It's the technology that has the value to transform .
Don't do micro front end for micro front end , Don't do applets for applets .
At present , adopt SchemaResolver, Different open capabilities can be provided for different roles :
author : Developer Assistant _LS
This article is the original content of Alibaba cloud , No reprint without permission
author : Developer Assistant _LS
This article is the original content of Alibaba cloud , No reprint without permission