MFE Loader is a tool to support an indirection layer between HTML files and his JavaScript and CSS dependencies, allowing us to deploy new versions of our micro-frontends without modifying the HTML files where they are used.
In the HTML files, this loader is included and then used to load the entry points referenced in some asset-manifest files, for example:
<!-- https://app.fromdoppler.com/editors/ -->
<!doctype html>
<html>
<head>
<!-- . . . -->
<script src="https://cdn.fromdoppler.com/mfe-loader/loader-v1.1.0.js"></script>
<script type="text/javascript">
assetServices.load({
manifestURL:
"https://cdn.fromdoppler.com/doppler-style-guide/asset-manifest-v1.json",
});
assetServices.load({
manifestURL:
"https://cdn.fromdoppler.com/editors-webapp/asset-manifest-v1.json",
});
</script>
<!-- . . . -->
</head>
</html>assetServices.load will download the asset-manifest JSON files and then update the DOM to load the javascript and css files referenced in those manifests.
See more details in these slides: https://andresmoschini.github.io/doppler-microfrontends/.
-
Add the reference to the last version of the loader:
<script src="https://cdn.fromdoppler.com/mfe-loader/loader-{version}.js"></script>
-
Load the dependencies
<script type="text/javascript"> // Optional configuration here assetServices.load({ manifestURL: "{asset-manifest-URL}", }); </script>
Some dependencies require configuration. In general, we are doing it using global variables defined by convention. For example:
<script type="text/javascript">
window["editors-webapp-configuration"] = {
basename: "editors-demo",
unlayerProjectId: 32092,
htmlEditorApiBaseUrl: "https://apis.fromdoppler.com/html-editor",
loginPageUrl: "https://app.fromdoppler.com/login"
};
assetServices.load({
// . . .
</script>interface IAssetServices {
load({
manifestURL,
sources,
}: {
manifestURL: string;
sources?: string[];
}): Promise<void>;
// . . .
}Parameters:
-
manifestURL: It is the URL of the asset-manifest. -
sources: A optional list of JavaScript or CSS resources that will be loaded after the files referenced in the asset-manifest. -
referenceNode(missing documentation) -
options(missing documentation)
Result:
It returns a promise. The promise is fulfilled when the asset-manifest is loaded and the DOM updated. It does not warrant that the files referenced in the asset-manifest have been loaded yet.
Take into account that each time that we need to use a new version of the loader, we need to modify the places where it is being used. So, try to:
-
Keep it as backward-compatible as possible
-
Keep it stable, avoid risky changes and test it well
-
Keep options open for a graceful evolution of the API
See doppler-jenkins-ci.groovy for details about CI/CD process. For the moment, it is similar to our other frontend projects, see a more detailed explanation in Unlayer Editor repository.
But, the loader does not use the loader to be loaded 😛, for that reason the asset-manifest based versioning does not apply here.
The task DE-669 is to automate the related improvement in the continuous deployment process. But, in the meantime, this is the manual process to publish a new version:
-
Do and merge in the
mainbranch the desired changes. -
Generate a version creating the git tag, for example:
v1.2.3. -
The previous step fires the CD process and generates the asset-manifest file, for example:
https://cdn.fromdoppler.com/mfe-loader/asset-manifest-v1.2.3.json. -
Read the asset-manifest file, and identify the generated bundle file, for example:
https://cdn.fromdoppler.com/mfe-loader/static/js/main.a58832ef.js -
Using our SFTP, copy that file to the friendly version file, for example:
https://cdn.fromdoppler.com/mfe-loader/static/js/main.a58832ef.jstohttps://cdn.fromdoppler.com/mfe-loader/loader-v1.2.3.js