Can I opt out of state in a zustand storage mapping?

[prideout]

I use the zustand middleware, and in my options I've selected a top-level object for storage:

{ ... storageMapping: { foo: true } }

If foo is an object, my understanding is that this not only tells liveblocks that I want foo to become a LiveObject, but also that its members should become live structures, recursively. For example if foo has a key called vector that is an array, then foo.vector will become a LiveList.

This recursive behavior is convenient but I would like to elect certain parts of state to be treated as atomic objects rather than live structures, both for performance and to avoid the known "ghosting" bug. For example, I have many pieces of state that are small fixed-size lists (3-dimensional coordinates), and I always update them atomically, so it's needless work to make then into CRDT's, since that would imply that each time I do a replacement, LiveBlocks is internally formulating 3 insert ops followed by 3 remove ops.

It would be great if the mapping keys could be more sophisticated to support "deep" parts of state. For example:

{ ... storageMapping: { "foo": true, "foo.coords.*.vector": false } }

Is something like this already supported?

[nvie]

Hi Philip, unfortunately electing specifically which parts of deep structures to sync as Live structures is currently not possible. The storageMapping is pretty simplistic configuration, which only supports top-level keys, and opting-in is all or nothing.

Possible ways around that are currently:

1. Structuring your application data differently somehow to avoid the automatic nested LiveList creations. For example, you can consider storing the 3d coordinates in a string encoding (e.g. store [1, 2, 3] as "1,2,3" instead).
2. Using the lower-level @liveblocks/client to more directly control your storage tree shape.

Perhaps there will be opportunities for us to support this better and more structurally in the longer term with schema validation. If the Zustand client would have knowledge about the room's schema somehow, for example, it could understand which arrays to treat as arrays and which to turn into LiveLists automatically.

We will realistically not get to work on this in the near term, given our other priorities. I hope the suggested workarounds at least offer you a way around this issue in the near term, but this is great feedback that will drive how we will evolve our APIs in the future.

Please let us know if we can be of any further help!

[prideout]

Thanks for the response, that makes sense Vincent.

One idea I had, which is a variation on your idea of using strings would be a typed array. For example, instead of a list of 3-tuples, we could just use a flat Float32Array, and LiveBlocks would treat it atomically. However I think my idea is bogus because typed arrays are an exotic type, and my understanding is that LiveBlocks only supports JSON-amenable types.

[nvie]

Yeah, I thought about that too while writing up the answer, but it would lead to some assymetrical reads/writes if we did that. Ultimately there is only JSON in our backend, so even if we'd accept Float32Array writes in the client, they would come back as regular arrays when read from our backend later, which would be too surprising I think.