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 ?

[gabrielgrant]

AFAICT there is still no Qwik-sanctioned path to Zag support unfortunately

I had started down the path of @mhevery 's suggested approach to refactor the Zag components' event handlers into a sync and async portion. But unfortunately the qwik team subsequently made some design decisions that rendered that approach unworkable.

Specifically: the very narrow API to allow imperative control of preventDefault() with sync() (implemented by @mhevery here: QwikDev/qwik#5545 ) is incompatible with Zag, because it doesn't allow preventDefault() to be called from an imported function -- this makes it impossible to extract the component event handling functionality into a common library, which is basically the whole premise of Zag

There's another approach to making preventDefault() work that I discussed with @wmertens here: eagerly resolve the relevant QRLs on page load. That could work with basically no changes on the Zag side for an initial implementation. For perf, it would still be better to do the sync-vs-async event handler splitting refactor that @mhevery suggested (though would be curious to benchmark and see how much of a difference it actually makes)

One downside of that approach would be a brief delay before components' event handlers were attached, while the QRLs loaded (similar to the rehydration delay seen with most other frameworks' SSR today, though likely significantly shorter). This could be mitigated if Qwik were to officially support including certain QRLs in the initial bundle. That seemed to me like a more straightforward approach than how sync() got implemented. But IIUC @mhevery felt that officially supporting fully-synchronous QRLs without restrictions opened up too much risk/temptation for users to abuse the API and degrade their apps' performance.

It's possible this QRL-preloading approach may still be doable somehow in a kinda hacky way without framework support, but I haven't yet figured out how to eagerly force initial QRL resolution without actually running the handler function (hope to look into this more when I have time, but would be great if someone else can determine if/how this is possible). Even if that is possible, though, I still don't love that would basically have us relying on an internal implementation detail [1] without any indication this is officially supported behavior/some assurance from the team that it wouldn't just change without notice in a future release

[1]: that the Promise from re-loading an already-loaded QRLs actually resolves synchronously

[gabrielgrant]

there's also still a bit of an open question about how the Zag state machine would be serialized, but this seems like it should be doable using @mhevery 's proposal to just put the state into DOM attributes

The short version off all this is that things haven't really changed since my status update above