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
initializePlugins
multiple times would end up loading/executing all plugins, but would wipe out theplugins
object 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
initializePlugins
after 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.names
to 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.plugins
could already exist, but not be in the format that Microplugin expects. I wouldn't expect this to be an issue in practice, however.