MapStore modular plugins with faster loading time

[tdipisa]

Description

The goal of this improvement is to allow the MapStore runtime load of plugins and their side-effects, to reduce the size of the initial JS downloaded and to allow to create extensions with a better plugins isolation system that do not affect the other pages of the application when the plugin is not used/present in the viewer.

A more technical proposal explains the aim and the boundaries of this work in details.

What kind of improvement you want to add? (check one with "x", remove the others)

• Minor changes to existing features
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• CI related changes
• Other... Please describe:

Other useful information

[alexander-fedorenko]

@tdipisa @allyoucanmap
Summarizing what we discussed in a call:

There are two strategies for further optimization:

1. Verify that it's possible to reduce amount of bundles being loaded for module plugins by altering webpack configuration. As we seen in the call - there are around 150 requests for module plugin bundles on the map viewer page, while actual count of plugins on the page is about 60.
2. Use prioritized load for several module plugins. Load few plugins that are the core ones (like map and page header/footer/tabs etc) at first and then continue with the rest of plugins. This way core part of the app will be loaded 1-2-3 seconds faster, depending on the connection speed and latency.

[offtherailz]

Just one thing about "mute" stream. Epics of redux-observable already define a 3rd argument, as an arbitrary object to pass (typically to pass APIs that can be wrapped for testing, instead of static imports).
I suggest to pass the mute stream as a part of the 3rd argument object instead of the pass the plain stream.

For the general idea of epics, but some of them (most of them in our case) are part of plugins.
For this reason, I suggest structure better this stuff passed and choose a better naming for mute stream.

This is litterally the first idea I have in mind, feel free to make it better:

(action$, store, {pluginAPI}) => {
const $pluginRenderEvents = pluginAPI.getCurrentPluginRenderStream();
}

'pluginAPI.getCurrentPluginRenderStream()` returns the stream of rendering, that can be used to mute (or do whatever you want).

pluginRenderEvents in my suggested opposite of mute$ (is better to to affermative variables then negative), so it is clear also it's usage.

I don't remember if I missed something, so I did some error forgive me and elaborate on your own my suggestions.

[allyoucanmap]

@offtherailz please take a look if this could work for you

https://github.com/geosolutions-it/MapStore2/pull/8495/files#diff-369602db306c1996a0dba22949eef963604ef54b344d9678d36240b94dd2da5aR222

[allyoucanmap]

@tdipisa we included additional improvement to the main bundle on this PR #8531. Related to this performance improvement issue #6735

[tdipisa]

Ok @allyoucanmap moving to test.