You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
// enable the plugin globallyScrollbar.use(OverscrollPlugin);// turn it onconsts1=Scrollbar.init(elem,{plugins: {overscroll: {effect: 'bounce',// add scrolling listeneronScroll(position){// do something},},},});// turn it off on another scrollbarconsts2=Scrollbar.init(anotherElem,{plugins: {overscroll: false,},});// switch the overscroll effect on the first scrollbars1.updatePluginOptions('overscroll',{effect: 'glow',});
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.
// turn of the plugin? ❌s1.updatePluginOptions('overscroll',false);// add more listeners? ❌s1.updatePluginOptions('overscroll',{onScroll(){// ...},});
Besides, the current plugin system requires you to add a static member pluginName to identify the plugin, otherwise you can not change the plugin options later:
classMyPluginextendsScrollbarPlugin{// why should I do this stupid stuff???staticpluginName='myPlugin';}
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 new operator to construct plugins, for example:
// init the pluginconstoverscrollPlugin=newOverscrollPlugin({effect: 'bounce',});// init the scrollbar (we may also remove the unnecessary `Scrollbar.init()` method in the next version)constscrollbar=newScrollbar(elem,{plugins: [overscrollPlugin,/* others... */]});// attach listenersoverscrollPlugin.addListener((position)=>{// do something});// switch overscroll effectoverscrollPlugin.setEffect('glow');// disable the plugin...overscrollPlugin.disable();// ...and re-enable itoverscrollPlugin.enable();
Interface
classScrollbarPlugin{enabled=true;
#scrollbar: Scrollbar;// will be called when scrollbar initializesinit(s: Scrollbar){this.#scrollbar =s;}enable(){this.enabled=true;}disable(){this.enabled=false;}onInit(){}onDestroy(){}onUpdate(){}onRender(remainMomentum: Vec2){}transformDelta(delta: Vec2,evt: Event): Vec2{return{ ...delta};}}
The text was updated successfully, but these errors were encountered:
Discussed in #393
Originally posted by idiotWu October 19, 2021
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
pluginName
to 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
new
operator to construct plugins, for example:Interface
The text was updated successfully, but these errors were encountered: