make-serializable

[rigid thunder]

I've run into the "serializable" limitation in Qwik enough times that I thought it would be valuable to make a sharable utility that makes it easier to work with non-serializable values. You pass in a function that tells it how to create the non-serializable value from a given state. It will return a hook and getter function that can be used to access the value, transparently recreating it if needed.
I've been using a pattern similar to this in my Tanstack Table and Virtual Scrolling POCs.
It's a little hacky, so any ideas on cleaning it up would be appreciated! If people like it, I might consider publishing this as an npm package.
https://stackblitz.com/edit/simple-qwik-starter-zux7yy?file=src/components/class-counter.tsx

[limber rain]

so this uses a task to do the deSer of the value? and if something uses the value before deSer ran, it breaks?
And you have to copy the internal state to external state on every change?

@lyric quest @scenic wyvern yet another datapoint why custom serializers would be awesome. Qwik can implement them way more efficiently with great DX. The needed code for deSer could be async loaded before a sync QRL is ran.

[scenic wyvern]

Yeah, agree... hard problem...

actually, I wonder if it could be solved with useComputed$() just make put your deserializer in useCompeted and just read that value. I think that should work.

[rigid thunder]

It's definitely messy, but it's the best way I've found that

1. Reuses the same instance of the non-serializable value when possible, or creates a new instance with appropriate state when necessary
2. Tricks the "change detection" into seeing updates of the non-serializable value
3. allows getting the non-serializable value accross $ boundaries (like in onClick$)
   I think because of number 3, hooks like useComputed$ wouldn't work

[limber rain]

Right, the idea of a custom serializer is that it will deserialize whenever needed (most likely a QRL event handler), and useComputed$ won't help with that.

to make it work with Qwik, the custom data object needs to provide .toJSON and the QRL for the parser. Then qwik-loader, while deserializing state, loads the parser and passes it the json object

since qwik-loader can load things async before calling them sync, that should work