QwikJs Framework Support

[elilabes]

With Qwik JS fast gaining support it'd be great to use Zag with it.

I believe that it meets both requirements for prop spreading + strongly typed.

[anubra266]

@elilabes I looked into this. And preventDefault handling in qwik, is a deal breaker.

[elilabes]

Understood! Yeah it is a bit of a different way than usual.

Out of curiosity, is it possible that the props that zag returns for the different elements where needed simply include preventdefault:click in the framework abstraction?

[kee-oth]

I'd really like to use Zag.js with Qwik as well. @anubra266, does @elilabes's idea make sense? Can Zag props just return preventdefault:click and then that issue is squared away?

[anubra266]

No...it's not possible. The prevent default has to be an attribute on the jsx element in qwik. So it can't be part of the various conditional logic that happens in the other event handlers.

[LazyClicks]

@anubra266 bit late to this but doesn't this help do it?
QwikDev/qwik#4496 (comment)

[gabrielgrant]

seems there's a proposal to fix this in qwik that is now being actively implemented: QwikDev/qwik#4496 (comment)

curious if this would be sufficient for qwik support in Zag?

[gabrielgrant]

Started looking into this more, but seems it's blocked by QwikDev/qwik#5540

[gabrielgrant]

nvm, seems this is able to work fine: QwikDev/qwik#5540 (comment)

[LazyClicks]

@anubra266 there an upcoming fix for this issue in qwik's upcoming version
feat(qwik): Experimental support for synchronous QRLs #5508

[gabrielgrant]

I've been looking into this a bit more now that there's an experimental implementation of Qwik's synchronous QRLs (ie event handlers that support preventDefault)

sync QRL restrictions mean they can't be used directly with Zag

At a glance, the API seems like it should work with Zag: Qwik already supported spreading props and event handlers; the new preventDefault solution just requires wrapping the handlers with sync(), which seems like something that could be done in normalizeProps

Unfortunately, though, there are very tight restrictions around what can be done in a synchronous handler that make them not directly usable with Zag. Specifically, the functions cannot be imported (ie they must be directly written in-line), and they can't access any component state.

I think the no-import restriction makes them even more limited than the workaround of putting code in useVisibleTask(). This workaround was mentioned by @LazyClicks above, but not sure if anyone really looked into exactly how this could work with Zag? It's not immediately obvious how to make this work with the Zag prop-spreading API, but going to continue investigating

Zag state machine needs to be serialized

The other (bigger?) issue, is Qwik's need to pause/serialize/resume component state. I'm currently poking around how to best make Zag's state machine play nice with Qwik's (de)serialization and resumability.

Qwik does not currently support serializing custom types. In the case of the Zag state machine, though, there dosn't seem to be a lot of internal state in the object:

• current state value
• some "context" (this is only briefly mentioned in the docs, so not yet sure what this is or how it is used)

From a high level, it seems plausible that this state could perhaps be exposed to Qwik's existing scope capture/serialization infrastructure and resumed within the component. I'm still learning about how Zag's state machine works internally to see if that is really possible.

Of course, even getting Qwik to work with the state machine still has the issue that sync events can't access Qwik-ified state anyway. One possible path forward may be to somehow just persist state machine state to the DOM directly (then the sync handler could access it, and wouldn't need to get Qwik's (de)serialization involved), but haven't fully worked through how that could function exactly.

All in all, still some issues to overcome before Qwik can be natively supported.

Qwik's support for embedding React components

The other entirely different option is using Qwik's React integration to just wrap the React version of Zag/Ark/Park components as islands within a Qwik app. It seems this should work, but is likely not ideal -- the recommendation is to use "wide islands", rather than wrapping many small, individual "leaf node" UI components (because each wrapped React component becomes it's own entire React app in the page, with no shared styling etc between)

[mhevery]

See my comment QwikDev/qwik#4496 (comment) as how it could be achieved.

[kattsushi]

Some update on this one ?

[wmertens]

Loading QRLs is easy: call qrl.resolve(). So if you have a bunch of handlers that need to be synchronous, you can add a visible task that loads them, and they will be called synchronously on events by qwikloader.

Also, nowadays QRLs have gained .resolved which allows synchronous access to the contents once they have been loaded. So you can also manually call qrls synchronously with qrl.resolved?.(...args).

Note that QRLs require the framework to load, so while we could optimize which js chunks to prefetch, they still need to be executed before qrls can be called, and I can't think of a way to do that synchronously.

So, complex sync handlers are already possible, for the price of waking up the container early.

1. given <div onClick$={() => stuff()} />
2. replace it with const handler = $(() => stuff()); useVisibleTask$(() => {handler.resolve()}); return <div onClick$={handler}/>

You can preload a bunch of handlers in the visible task of course.

[plandem]

@anubra266 any directions how to create POC or something? I really would like to see Ark-UI in Qwik, especially since it has no decent UI library right now. Ofc, I could go vanilla-extract or pandacss, but one day when it will require something more complex, it can be a blocker :(

So with these recently ideas that @wmertens posted here, what would be the best starting point for POC? grab vanilla-js example and make it work with qwik?

[segunadebayo]

Thanks for the ideas in this thread. I managed to create a PoC for the Qwik integration.

https://github.com/chakra-ui/zag/blob/feat/qwik/examples/qwik-ts/src/routes/index.tsx
https://github.com/chakra-ui/zag/blob/feat/qwik/examples/qwik-ts/src/hooks/use-machine.tsx

There are still a lot of things to improve on here. Don't have time to dedicate to completing this

[anubra266]

@plandem The controlled context is the only issue in that PoC

[gabrielgrant]

quick correction - the second link in @segunadebayo 's comment should be https://github.com/chakra-ui/zag/blob/feat/qwik/examples/qwik-ts/src/hooks/use-machine.ts (not .tsx)

[anubra266]

@wmertens @plandem This is what I have for now: #1868

Full qwik context on feat/qwik branch

Improving the final API is what I'm trying to achieve now. E.g. would be nice to not need to have initialState key just for providing initial state

[osdiab]

looking forward for this to be ready to use! It would immediately make Qwik much more viable of a framework to build on by having a well-tested and fleshed out UI toolkit (while Qwik UI exists, it's got a long way to go, and Zag/Ark/Panda are the jam).

[gabrielgrant]

yes, any updates on the status of this and what would be needed to move it toward being mergeable?

[anubra266]

@gabrielgrant mostly this. #1876
Current code may not be reliable. But we basically need to trasform into qrls where neccessary. PRs are welcome. Not much of a qwik expert myself