AngularLoader: Support 'settingsFactory' callbacks in angular modules.

[colemanw]

Overview

This allows Angular modules with complex/expensive data to provide it with a callback, which will only be invoked if the module is actively loaded on the page.

Docs updated at https://lab.civicrm.org/documentation/docs/dev/-/merge_requests/862

Before

Angular modules can declare settings which are calculated on every AngularLoader->load() and then discarded if the module isn't needed on the current page. This can get expensive.

After

Angular modules can declare settingsFactory which is only invoked when a module is needed on the current page.

Comments

Currently (and I was a bit surprised by this) the full list of Angular modules is not cached anywhere. So hook_civicrm_angularModules runs on every page, and each module's settings is loaded every time. That's a good thing from the POV of permissions (if say a module's settings are different for different users) but it's terrible for performance.

Switching modules to use settingsFactory can save cycles in the short-term, and be even better in the long-term when we get around to caching the list of modules, as only the name of the callback will be cached, not the array of settings. This will also keep the per-user settings a possibility even with global caching of the modules.

[civibot]

(Standard links)

• If this is your first pull-request for CiviCRM, please browse CONTRIBUTING.md for information about the development and testing processes.
• If you are reviewing this pull-request, you may wish to consult the test sites and the Review Standards (long template, short template).

[totten]

This is a good idea. The test looks sensible (though I added a suggestion above for more assertions).

Currently (and I was a bit surprised by this) the full list of Angular modules is not cached anywhere. So hook_civicrm_angularModules runs on every page, and each module's settings is loaded every time. That's a good thing from the POV of permissions (if say a module's settings are different for different users) but it's terrible for performance.

Switching modules to use settingsFactory can save cycles in the short-term, and be even better in the long-term when we get around to caching the list of modules, as only the name of the callback will be cached, not the array of settings. This will also keep the per-user settings a possibility even with global caching of the modules.

Yup, in a world where modules are loaded conditionally (e.g. conditioned on the server-route; e.g. conditioned onfindActiveModules() and resolveDependencies()), putting all settings in the metadata is not ideal. It makes much more sense for the metadata to have a callback (settingsFactory).

From a DX POV, it's nice for the module metadata to be always-fresh/live. But then again...

• afforms module list is cached. (Though, IMHO, this works out for a different reason -- afform docs are usually created/deleted via API, so we can affirmatively clear the cache when needed. Regular modules don't have that.)
• For an overall Angular module cache, we could probably use a setting for developers to enable/disable it (e.g. probably assetCache but maybe debug_enabled).

In any case, regardless of when/how/if caching is added to the module list, we should probably phase-out the use of $angularModules['...']['settings'] and favor settingsFactory...

[colemanw]

Thanks @totten. I updated the test with half of your suggestion. Resources->getSettings() doesn't actually fetch all settings, only the ones loaded via a factory.

[colemanw]

@totten actually nevermind the settings do all come back, I just needed to fix the logic. So now I've implemented your full suggestion to improve the test.

[totten]

@colemanw Glad to hear all settings come back.

I did some r-run by writing+testing a patch that relies on this -- #18749 (update crmMailing). This worked in my testing. One possible snag to note -- CRM_Mailing_Info::getAngularModules() calls addPermissions(). This function also populates settings-data that's only needed conditionally, but I don't think a settingsFactory could handle it.

TBH, I sort of feel that the angularModules should be more like a Bundle or Collection (eg building on CollectionTrait / CollectionAdderTrait), but I don't have a clear enough thought on how transition it. (The tricky bits are that (1) angular modules have dependencies, which aren't in the bundle model (2) angular modules existing contract is presented as a different array/data-structure.) So I think it's OK to punt that for a bit.

Marking this "merge ready". @colemanw , if the example (#18749) is OK, and if you're OK punting the other bits, then let's merge.