mirror of
https://github.com/strapi/strapi.git
synced 2025-09-25 16:29:34 +00:00
Merge pull request #17470 from strapi/chore/route-loader-comment
Chore: Add code comment for plugin initializer
This commit is contained in:
commit
713cb1edf8
@ -18,6 +18,29 @@ const PluginsInitializer = () => {
|
||||
(plugin) => plugins[plugin].isReady === false
|
||||
);
|
||||
|
||||
/**
|
||||
*
|
||||
* I have spent some time trying to understand what is happening here, and wanted to
|
||||
* leave that knowledge for my future me:
|
||||
*
|
||||
* `initializer` is an undocumented property of the `registerPlugin` API. At the time
|
||||
* of writing it seems only to be used by the i18n plugin.
|
||||
*
|
||||
* How does it work?
|
||||
*
|
||||
* Every plugin that has an `initializer` component defined, receives the
|
||||
* `setPlugin` function as a component prop. In the case of i18n the plugin fetches locales
|
||||
* first and calls `setPlugin` with `pluginId` once they are loaded, which then triggers the
|
||||
* reducer of the admin app defined above.
|
||||
*
|
||||
* Once all plugins are set to `isReady: true` the app renders.
|
||||
*
|
||||
* This API is used to block rendering of the admin app. We should remove that in v5 completely
|
||||
* and make sure plugins can inject data into the global store before they are initialized, to avoid
|
||||
* having a new prop-callback based communication channel between plugins and the core admin app.
|
||||
*
|
||||
*/
|
||||
|
||||
if (hasApluginNotReady) {
|
||||
const initializers = Object.keys(plugins).reduce((acc, current) => {
|
||||
const InitializerComponent = plugins[current].initializer;
|
||||
|
Loading…
x
Reference in New Issue
Block a user