Updated initializePlugins to not wipe out previous plugins data
#2
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.
Hey Brian,
I noticed today that calling
initializePluginsmultiple times would end up loading/executing all plugins, but would wipe out thepluginsobject on each invocation.I was working on creating a plugin for Selectize that would add "singlePlugins" and "multiPlugins" settings, so that I could define default plugins more simply, when I ran into this issue. My custom "mode_plugins" plugin calls
initializePluginsafter Selectize has already initialized it and other plugins.The main issue this causes in Selectize is that CSS classes are only applied for the latter round of plugins (single/multi), and not for the original listing of plugins, because Selectize looks at
self.plugins.namesto generate the classes.This pull request includes a simple fix/test for Microplugin to ensure that all plugin data stays intact across multiple invocations of
initializePlugins. One thing this fix potentially leaves the door open for is thatself.pluginscould already exist, but not be in the format that Microplugin expects. I wouldn't expect this to be an issue in practice, however.