Plans & Suggestions for v2.0.0

[KingSora]

Good day!

In this issue I want to start a discussion what you'd expect from v2.0.0 of this plugin and what my plans are. Please feel free to post any suggestions or wishes you have, I'm open for everything! Also if you think any of my ideas are bad or aren't making much sense, this is the right place to adress it.

Alright, lets start! My plans for v2.0.0:

Browser support

• I'll definitely drop IE8, ideally I would drop also IE9 and IE10 so IE 11 would be the "lowest standard". This change would make the library smaller since less compatibility code is required.

Breaking Changes

• Currently I don't like how the instances work. Destroyed instances are basically useless. This shall change in v2.0.0 as instances will be always of use, even if you decide to destroy it, it will only destroy the generated DOM, EventListeners, Observers and so on. The instance itself can still be managed and you can also still utilize the scroll function, so you don't always have to do a awkward check which scroll function (native or plugin) you should use.

• Instance management, this change can only be done if we support IE 11 as the lowest standard. Instad of applying a new property to a DOM element a WeakMap should be used for instance management.

• The scroll function. Currently the scroll function is relatively big and I don't really know how many users really needs it, so this change should definitely be discussed! The plan is to make it optional as a static method. So the standard lib comes without it but, you can always decide to download the extensions to use it. The usage would look something like this:

//scroll to coordinates or element
OverlayScrollbars.scroll(osInstance, coordinates [, duration] [, easing] [, complete])
OverlayScrollbars.scroll(osInstance, options)

//get scroll info
OverlayScrollbars.scroll(osInstance)

• The scrollStop function. If the scroll function changes the same would also apply to the scrollStop function. The scroll and scrollStop function would come in one extension, so you don't have to download two separate extensions since both are essential for scrolling animations.

OverlayScrollbars.scrollStop(osInstance)

Features

• Scrollbars management: Currently the scrollbars are applied inside the host element. Since this request was posted a few times in the past, it could be possible to pass a DOM element to which the scrollbars should be applied. (So scrollbars could be applied also outside of the generated DOM) This feature is also related to the Compatibility with other libraries feature since the DOM structure of such libraries sometimes requires a different parent element for the scrollbars.

• Compatibility with other libraries. Yeah, yeah, currently its hard to use OverlayScrollbars with other libraries for things like virtualization or Grids, thats because often these libraries weren't designed with optional custom scrollbars in mind.
  I don't know exactly how it will turn out, but I think its possible that OverlayScrollbars can offer the possibility that at least a viewport element can be passed somehow and then The library can adapt to that. The complex part is, that any library is designed differently and some libraries offer more elements than just a viewport and some don't. So I would also add the possibility to pass following elements: host, viewport and content, where viewport is required and the others are optional.

Thats it for now! Thanks for your attention and please submit your ideas or any feedback you have.

@Grsmto @MarcosRakesh @Windvis @hamed-ehtesham @parsisolution @Acccent
#55

[hamed-ehtesham]

Hi @KingSora ,
Good day

i suggest that you keep browser support but in a modular way or maybe have a separate version/release to support it but if all future features isn't feasible in older IEs and if current version 1 of library is stable or will be eventually in the future then dropping IE support is not that bad

Keep up the great work! 💪👌

[Media-Evil]

Hi. Please consider supporting css-modules. The desired API could look like this:

• '?' means 'optional'
• [value/?=value] points to the default value (if property is not specified)

<Scrollbar
  options={{
    <cssModules?>: true/[false], //if true, import theme stylesheet and use generated class-names, else use unscoped class-names
    <theme?>: ['dark']/'other themes...', //defines which built-in theme to require
    <classMap?=null>: {
      host: 'additionalClassName',
      //...
      viewport: 'additionalClassName'
    }
  }}
>

What is the gist of this:

• now user can avoid using !important, if user want's to increase the specificity or overwrite the defaults, he/she can achieve this via classMap property (useful not only for css-modules)
• customization will become a breathe

If you need any clarification or have any concerns, let's discuss them

[tryggvigy]

Hey @KingSora, This is a great project. Huge thanks to you for your efforts!
All the changes you have in mind sound good to me. The main expectations I have on a JS scrollbar library is that it get's out of your way, is performant, integrates with frameworks and does a best effort to support popular virtual scroll implementations. This project checks all those boxes and any improvements on these fronts would be impactful imo.

I'm considering OverlayScrollbars as a solution to a long standing problems we've had with Chromium scrollbars on Spotify. The most important features for us are performance and control over styling.

[KingSora]

@tryggvigy cool! I'll give my best to achieve the goals vor v2.0.0. I hope OverlayScrollbars fits your needs and will perform well, as my focus was exactly on performance, compatibility and styling in the current v1.x version.

[seleckis]

For React version, I would like to access ref to scrollable div, i.e. <div class="os-viewport"> to be able to save position of the scroll throughout browser history changes. This would be useful when the OverlayScrollbars are used for main div, but url is switching with ReactRouter.

I know that there is an option to access this element by instance.getElements("viewport"); but this is not React Ref Object. The React-way should return Ref Object, not the exact DOM element.

[tryggvigy]

It's fairly easy to do this today

<OverlayScrollbarsComponent
  ref={ref => {
      myScrollNodeRef.current = ref.osInstance().getElements().viewport;
  }}
>

[seleckis]

Thank you for your answer @tryggvigy, I do it in similar way now:

  const osInstance = scrollbarsRef.current?.osInstance()?.getElements("viewport");
  const scrollbarsViewportRef = osViewport ? { current: osViewport } : null;
  ...
  <OverlayScrollbarsComponent ref={scrollbarsRef}

but it looks like a workaround not the long-term react-way solution. I believe that API of any react component which renders any DOM node should have an ability to pass a ref of that node to an app. Unfortunately React team does not provide recommendations for developers how to create components to make them compatible to each other.

[KingSora]

@seleckis there are some issues I have with designing such a API.

I could simply use a forwardedRef to the viewport element, this would solve your particular case. But with this approach you can't get the osInstance anymore, because you need the ref / HTMLElement to the host element and not to the viewport element to get it. And since you can get every DOM element you need when you have the osInstance this would be more of a downgrade to me.

In react you have RefObjects and these objects have a current property which contains the corresponding HTMLElement. Does it really make so much difference to you when you get the viewport HTMLElement from the osInstance instead of the RefObject?

I'm aware that it would be "more beautiful" when the lib would behave like a "true" react lib, but since this isn't the case and I want to have the wrapper components as simple as possible for now (because of easier maintenance). This can change in the future obviously, but for now I have no plans to change the wrapper components since you can do everything with them once you have the osInstance.

[seleckis]

@KingSora I see, alright, thank you

[shuherco]

Hi @KingSora,
i really like OS, it's a great tool. I am using it with anular/kendo library and i did not find a way to add it in popup/modals(dropdown/combobox).
can you tell me please if it works ?
And also wich classnames i can add manually to make it work inside popups modals.
Thanks.
I added it with, but every time i close/open popup is gone(it's not part of DOM)
OverlayScrollbars(document.querySelector(".k-list-scroller"), this.osComponentOptions);
Thanks a lot!

[paulovieira]

Dropping support for IE8-10 seem absolutely natural. Nowadays the minimum reasonable expectation is IE11 (and only for government office whose computers, etc). And even IE11 is questionable (see: IE11 Mainstream End Of Life in Oct 2020 https://www.swyx.io/writing/ie11-eol )

A good compromise would be adopt a more plugin/extension architecture (optional support for the scroll method, IE11, etc), so that the core library is more focused and easier to maintain.

[NechiK]

Hi @KingSora
Overlayscrollbar is a great library. I used many such libraries before and they have a lot of unexpected issues.

Now I see that your library has angular 7 in peer dependencies. It looks like it works OK with Angular 9, however it would be better to update overlayscrollbars-ngx to use angular 9. At least in 2.0 version. What do you think?

I can try to help you with it :)
Also, I have some cool improvement for overlayscrollbars-ngx. It's about configuration. I almost done it in fork repository, but I have some questions. I'm going to add issue and describe them.

[KingSora]

@NechiK feel free to create a corresponding issue here in github where we can discuss such things :)

Short update for v2.0.0 development: I've decided to use TypeScript for the entire project and modularize it (as currently in v1.x everything is in one big file).

Thanks to the IE drop, I could get rid of many lines of fallback and compatibility code.
I'll also get rid of the "jQuery" like coding style since it brings a lot of issues in terms of event listeners etc.

[Nikey646]

Would it be out of scope to consider just adding virtualization capabilities into an optional dependency, rather than trying to support any virtual scroller?

I feel like it might be more effort to support virtual scrolling libraries, than just rolling your own.