Plugins helpers #4274
Plugins helpers #4274
Conversation
|
Thanks for the PR! 🎉 We've deployed an automatic preview for this PR - you can see your changes here:
Note The build needs to finish before your changes are deployed. |
| if (!pluginSet) { | ||
| pluginSet = { plugins: [], requiresSorting: false }; | ||
| pluginSets.set(setKey, pluginSet); | ||
| } |
There was a problem hiding this comment.
Nit: not sure if this is better or not, but another option that's 1 less line!
if (!pluginSets.has(setKey)) {
pluginSets.set({ plugins: [], requiresSorting: false });
}
const pluginSet = pluginSets.get(setKey);There was a problem hiding this comment.
Oh yeah... I think I might had that initially, but then switched it to only do the single look-up. The difference is probably negligible for the number of plugin sets we'll have though.
There was a problem hiding this comment.
Should be O(1) lookup on the Map anyway.
Co-authored-by: Dave Lockhart <dlockhart@users.noreply.github.com>
… dbatiste/plugins
Co-authored-by: Dave Lockhart <dlockhart@users.noreply.github.com>
helpers/plugins.js
Outdated
|
|
||
| export function getPlugins(setKey) { | ||
| if (!pluginsRequested.has(setKey)) pluginsRequested.add(setKey); |
There was a problem hiding this comment.
Another option would be to set something like a requested = true on the set, similar to requiresSorting.
There was a problem hiding this comment.
Yeah, I originally considered that but felt wrong because getPlugins would need to add to the pluginSets for the case where there are no registrations. But now that I think about it more, tracking the bit separately isn't really saving anything, whether the plugin Set key is valid or not. I think I will switch it.
|
🎉 This PR is included in version 2.162.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
US160427
This PR adds plugins helpers -
registerPlugin,getPlugins, andgetPluginto enable implementors to define plugins without consumers of those plugins being required to import them directly. BSI or a higher level module is responsible for importing the registrations.Other options were considered, including deferring the registrations or by accepting an async provider method for the plugin, however we do not want plugin implementors assuming that if the registration is deferred, that it would be safe to synchronously import dependencies within the registration module. Typically, we expect projects registrations to be aggregated into a single public export, which means that unrelated plugins could be registered (and synchronous imports loaded) as soon as the registration module is requested. The implementor mindset should be geared towards deferring its dependencies until needed, as shown in the readme.
Required for: https://github.com/BrightspaceUI/lms-core/pull/61