Page Comparison

...

• index.jsx the main entry point requires refactoring. Previously MFE’s were responsible for initializing and responding to events from frontend-platform. In the new paradigm, the Shell manages interactions with the platform while MFE’s must implement the Pilet lifecycle method setup(piralApi). Instead of setting up routing and routes to components, Pilets register their components directly with the Shell via the registerPage(), and registerExtension() apis. This API can be extended to offer support for additional components (for example paragon components extensively used by existing MFE so that MFE’s can share a single definition of this important library, or alternative ones as the need arises).

• frontend-platform exported functions and objects now need to be wrapped and exposed from the Shell (where it is initialized) via the piral API. All uses of stateful methods previously imported from frontend-platform must be refactored in order to access the methods as exposed by the API. In the Learning MFE, we implement a simple helper object that is created during the setup() lifecycle method. (frontend-app-learning/src/data/api.js)

• redux store is now created centrally by the Shell. Instead of being responsible for their own stored, Pilets now simply wrap their rendered components in the DynamicModuleLoader HOC available in the redux-dynamic-modules library.

• The build process for MFE’s differs when bundling for Pilets. This prototype includes two new webpack configurations - one to bundle the shell itself and one to bundle MFEs. The second one in particular is very similar to existing Open edX development configurations but it removes the HTTP server as that is now handled by Piral. In addition, the make targets for these MFE’s have been deprecated in favor of the npm run build target which includes the Pilet packaging features to ensure compliance with the specification.

• Package depedencies: Piral ability to share dependencies will lead to substantial refactoring of existing package.json files. This prototype demonstrates how dependencies can be shared, but it does not make an attempt at addressing what should be shared. Piral documentation includes thoughts that should be discussion starters as we explore what should be shared centrally.

An important consideration to highlight and explore is the size of the Pilet packages. Piral suggests MFE’s should remain under 1Mb, but the Learning MFE alone sits at 25.3Mb when bundled. A combination of tighter dependency management and/or refactoring of features into smaller Pilets during the conversion process can help allay some of the concern around package size.