feat: slot component for dynamic plugins

[johnvente]

Description

, we've created a reusable component that will dynamically import a module wherever it is called. The main idea is to be able to change the plugins with this mechanism, which means that instead of modifying the micro-frontend beforehand, we could change the plugin in isolation.

How does it work?

Any component can be wrapped with the pluggable component. For instance:

<PluggableComponent id="input-form" as="communications-app-card">
    <h1>Any component as default</h1>
</PluggableComponent>

The prop as indicates where is the plugin allocated. In this case, the component will be pointing to this route: node_modules/@openedx-plugins/communications-app-card.

If the plugin was installed as a dependency, it will render the component that you have pointing to that one.

If the plugin isn't installed, it will return its children. In this case, it's this:

<h1>Any component as default</h1>

Why are we doing this?

This means that the plugin doesn't have to be installed if I'm making a feature. It's something that we can improve in the future. That way, another developer can replace that component and make more changes. This approach allows us to wrap as many components as we can, making most of the features pluggable and adaptable to various use cases. The component can be rendered without children as well, which means it won't return anything if the plugin is not installed.

How to test it

Check it out this branch and follow these steps:

 cd plugins/communications-app/CheckBoxForm && npm link

 cd plugins/communications-app/InputForm && npm link

 nvm use && npm install

Then you can run the mfe with npm start

If you want to create another plugin you can do it in the folder plugins/communications-app/ with the structure of the other
plugins

[openedx-webhooks]

Thanks for the pull request, @johnvente! Please note that it may take us up to several weeks or months to complete a review and merge your PR.

Feel free to add as much of the following information to the ticket as you can:

• supporting documentation
• Open edX discussion forum threads
• timeline information ("this must be merged by XX date", and why that is)
• partner information ("this is a course on edx.org")
• any other information that can help Product understand the context for the PR

All technical communication about the code itself will be done via the GitHub pull request interface. As a reminder, our process documentation is here.

This is currently a draft pull request. When it is ready for our review and all tests are green, click "Ready for Review", or remove "WIP" from the title, as appropriate.

[openedx-webhooks]

@johnvente Even though your pull request wasn’t merged, please take a moment to answer a two question survey so we can improve your experience in the future.