Qwik support

[thejackshelton]

Is your feature request related to a problem? Please describe.

In Qwik UI we currently do a decent bit of hackery to get scroll working correctly. In other headless libraries we see a "scroll area" component, although this tends to be very complex, and often unmaintained and hacky scroll behavior.

Overlay Scrollbars seems like a good fit to use for Qwik UI, if there's a way we can allow people to easily integrate the overlay scrollbars library into their qwik ui components.

---

Describe the solution you'd like

I'd like to be able to integrate overlay scrollbars with Qwik UI in a way that does not execute code until the scroll interaction. Making the components we use for select, combobox, etc. to play nicely with their own custom scrollbars.

---

Describe alternatives you've considered

A clear and concise description of any alternative solutions or features you've considered.

We've considered creating our own scroll area component, and alternative scrollbar libraries

---

Additional context

I can dedicate some time in the future to trying to figure this out 😅 . Thought I'd bring the idea ahead of time so that the development process would be more straightforward.

[KingSora]

Good day @thejackshelton

I've already played around with qwik and tried to make a overlayscrollbars-qwik wrapper like I've done it with all the other frameworks.

Unfortunately there were some roadblocks, mainly:

• [🐞] Qwik removes elements generated by 3rd party plugin QwikDev/qwik#6464
• [🐞] Polymorphic component with applied ref wont update properties QwikDev/qwik#6465

The first one is unfortunately a deal breaker and leads to unexpected behavior. I'm not sure whether you have a bit more insight into this topic, possibly having a workaround or idea of how to improve qwik in that area.

You can find my attempt in porting the library to qwik in the feat-overlayscrollbars-qwik branch. Please note that this is unfinished sample code where I just played with how qwik works.

That being said I would gladly collaborate with qwik-ui by creating a port / integration of the library :)

[thejackshelton]

Hey @KingSora! I think this month I'll be able to tackle it, or at the very least spend a bit of time on it.

Hard to balance with Qwik and the other projects I work on and maintain, but I think it's important that this project has a Qwik integration.

As for a workaround, you can use the Qwik UI popover while Qwik is still in v1, or see the workaround we did under the hood to achieve it which should work similar to portals and the ability to move other content around the DOM.

In Qwik V2, which an alpha coming up very soon soon, there is the concept of vNodes or "markers" that communicate with the JSX in a very lazy way. This would solve the deal breaker blocker.

Could you guide me on where I could start? Or is there an effort that was started on this somewhere already?

[KingSora]

Hey @thejackshelton and sorry for the late answer.. I'm kind of busy at the moment.

Thats great news regarding Qwik v2! :) As soon as there is any usable public version I could also take a look at an implementation. For the time being you could check out the feat-overlayscrollbars-qwik branch.. There is my past attempt at porting the library to qwik. You can also create your own version from scratch, the only thing I would like to have is a similar API to the present framework wrappers.

[KingSora]

@thejackshelton I had some spare this weeking and took a look at v2 of qwik.. I belive I've successfuly implemented a qwik integration without any major problems.

If you find time please give me feedback.. I've tried to follow any best practices I could find but since I'm fairly new to qwik I would love to hear what you think.

The things I'm unsure about are:

• Naming of the properties in particular when to use the $ sign. Since the OverlayScrollbars options can be serializable (e.g. if you don't use any options that require functions) I've not used the $ sign in the names.
• useOverlayScrollbars returns two functions which help with initialization was well as returning the overlayscrollbars instance.. I was unsure whether to make them noSerializable or whether to use QRLs. Since both function only make sense on the client side and I would prefer them not to be async I've now settled on the noSerialize solution
• Whether my usage of useTask$ and useVisibleTask$ is correct

The example code of the app can be found here. The most interesting bits should be the OverlayScrollbarsComponent as well as the useOverlayScrollbars hook.

You can checkout the repo or directly the ./examples/qwik folder and run the app with npm run dev.

[thejackshelton]

Hey @KingSora! I'll take a look this week for sure. Appreciate the awesome work on this 💪

[KingSora]

@thejackshelton looking forward to it :)

[KingSora]

@thejackshelton just wanna make a small checkup whether this topic is still on your roadmap? :)