Redesign the plugin system #393
dolphin-wood
started this conversation in
Ideas
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Motivation
The plugin system in smooth-scrollbar@8 is great, but it lacks flexibility due to the declarative configurations. For example, the following code is quite common when using the overscroll plugin:
So far so good, huh? But what if we want to turn off the overscroll plugin on
s1? Or if we want to add more listeners to the plugin? The current design just doesn't allow you to do so.Besides, the current plugin system requires you to add a static member
pluginNameto identify the plugin, otherwise you can not change the plugin options later:Proposal
In the next major release, I'd like to redesign the plugin system so that we can use it more programmatically. Instead of passing a bunch of options, we can use the
newoperator to construct plugins, for example:Interface
Beta Was this translation helpful? Give feedback.
All reactions