STCOR-635 load and cache handler modules during getModules #1673
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Static event handler functions are invoked synchronously during the render cycle to allow handler modules to either implement side-effects or return a component in order to interrupt the ordinary flow. Thus, handler modules must be pre-loaded and cached, which is accomplished here by leveraging the async `getModules()` call. NB: renaming of things inside `handlerService.js` has not changed the implementation at all; rather, the new names reflect what these functions have always done. Refs STCOR-635, STRIPES-999
Jest Unit Test Results 1 files ±0 83 suites +1 1m 42s ⏱️ +2s Results for commit 6f4b04a. ± Comparison against base commit 39726e7. This pull request removes 3 and adds 5 tests. Note that renamed tests count towards both.♻️ This comment has been updated with latest results. |
Bigtest Unit Test Results150 tests ±0 149 ✅ ±0 6s ⏱️ -3s Results for commit 6f4b04a. ± Comparison against base commit 39726e7. This pull request removes 5 and adds 3 tests. Note that renamed tests count towards both.♻️ This comment has been updated with latest results. |
When a bundle is constructed with `--lazy()`, the module-loader function will be `getDynamicModule()` implemented with `import()` instead of `getModule()` implemented with `require()`, i.e. the module-loader function will be async. That offers the opportunity to implement lazy-loading, but for FOLIO this has caveats: * event-handler modules provide static methods, meaning they must be accessible synchronously during render * plugin modules may need to be loaded synchronously due to how they are loaded in the UI IOW, module loading cannot always be handled with lazy. Here, we take the simple approach: pre-load everything, which may seem to fly in the face of implementing code-splitting to begin with, but the end-goal here is not, in fact code-splitting with separate webpack chunks, but code-splitting with independently constructed module-federated bundles. In that context, being able to load separate pieces is still a win. We may eventually choose a more elaborate process for loading modules, e.g. choosing to lazy-load applications but to pre-load other types, but we're starting with a simple approach: pre-load everything. Refs STCOR-635
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Static event handler functions are invoked synchronously during the render cycle to allow handler modules to either implement side-effects or return a component in order to interrupt the ordinary flow. Thus, handler modules must be pre-loaded and cached, which is accomplished here by leveraging the async
getModules()call.NB: renaming of things inside
handlerService.jshas not changed the implementation at all; rather, the new names reflect what these functions have always done.Refs STCOR-635, STRIPES-999