Reference link: mp.weixin.qq.com/s/qOw0-u8w2…
In the microfront-end architecture, JavaScript sandboxes need to be solved
- Global methods/variables hanging on Windows (such as setTimeout, scrollglobal event listeners, etc.) are cleaned and restored when child applications switch
- Cookie, LocalStorage, and other read/write security policies
- Implementation of independent routing for each sub-application
- Independent implementation of multiple microapplications when they coexist
Implementation of JavaScript sandbox in architecture design of Qiankun
The core file
- Focus on the two entry files proxysandBox.ts and SnapshotSandbox.ts
Technical solution
- The proxy-based implementation proxies constants and methods commonly used on Windows, respectively
- When proxy degradation is not supported, snapshots are used for backup and restoration
Implementation approach
In the original version, the concept of snapshot sandbox was used to simulate proxy API of ES6, which hijacked Window by proxy. When the child application modifies or uses properties and methods on Window, the corresponding operation is recorded. Snapshots are generated every time the child application is mounted/unmounted. Later, in order to be compatible with the coexistence of multiple sub-applications, the constant and method interface to deal with all global problems was implemented based on Proxy, and an independent running environment was constructed for each sub-application.
Browser VM of Ali Cloud development platform
The core file
Context.js
Implementation approach
- Drawing on the implementation effect of with, wrap a layer of code for each sub-application code in the webPack compilation and packaging stage (see relevant files under its plug-in package, BREEzr-plugin-OS), and create a closure. Pass in your own simulated global objects like Window, document, location, history, etc. (see related files in the root directory)
- In the simulated Context, new an iframe object, providing an empty object for the host application (about: Blank) the domain URL to which the iframe is initially loaded (an empty URL will not load resources, but will cause the history associated with the iframe to not be operated, since route transformations only support hash mode). Then pull out the native browser object underneath it via contentWindow (because the iframe object is naturally isolated, you save yourself the cost of mocking all the apis)
- After fetching the native objects in the corresponding iframe, it continues to generate the corresponding Proxy for the objects that need to be isolated, and then for some specific implementation (for example, window.document needs to return the specific sandbox document instead of the current browser document, etc.)
- In order for the document content to be loaded in the same DOM tree, for document, most DOM manipulation properties and methods are still handled directly using the host browser’s Document properties and methods
Figma
History implementation scheme
- At first Figma also executed the plug-in code in iframe and communicated with the main thread via postMessage, but due to ease of use and the performance of postMessage serialization, Figma chose to execute the plug-in on the main thread.
Implementation scheme
- Figma’s approach is based on the Realm API, which is still in draft form, and compiles Duktape, a C++ implementation of the JavaScript interpreter, into WebAssembly and then empresses it into the Realm context. Realize the independent running of tripartite plug-ins under its products.