1.0.0: Planned changes

[endel]

Hi guys, I've been tinkering on the changes necessary to improve the overall usage of @colyseus/schema (a.k.a. state serializer) and here's the list of open issues I'm planning to close on the 1.0.0 update:

• MapSchema onRemove issue #71
• 1.0.0 Proposal: Officially supported data filters #66 / @filter: how to approach it? #61
• 1.0.0: Implement a Set structure #63
• 1.0.0: Use Map internally for MapSchema #62 / Fix autocompletion for items inside Maps #3
• onAdd should be called when replacing items #58
• Re-using the same instance on multiple fields / .clone() automatically? #54

This is going to require restructuring and rewriting some parts of the encoder and decoder across all languages, the plan is to be able to release it next month.

Another big change is the client-side callbacks. They are currently triggered one by one, before the full patch is applied on the client's state. It would be better if the callbacks are triggered after the client received and updated its local state.

If you have any suggestions or feedback to give regarding how the @colyseus/schema works, or could work differently - this is the right moment. Decisions made during next month will live probably for the next year or so.

Thanks!

[dclipca]

@endel, one thing with a high value and relatively low development effort would be directly supporting objects in the Schema without having to store them serialized.

[endel]

Hi @virtumonde, not sure if I understand what do you mean, you mind providing an example of how this could look like?

[dclipca]

@endel, that was not a very good description. What I mean is being able to store objects in the Schema. As of now, the only way I was able to do so is by using JSON.stringify() and then retrieving using JSON.parse(). I know that you can store instances of classes provided that you specify what class is the given instance but I didn't find ways to store objects directly without any dancing around the serialization.

[dclipca]

If I am right and there is no way to directly introduce untyped objects (not class instances) into Schema without JSON.stringify() then it would be extremely helpful if Colyseus would do the JSON.stringify()/JSON.parse() thing automatically somehow (I think this makes sense to do from the side of the client).

[Zielak]

From what I gather, serializing exists to compress your objects, so less bytes are transferred. Just doing JSON.stringify() on one end means you're transferring everything "uncompressed" as a huge string.
Whats your use case? Why do you want to store whole object literal directly, without serialization? Maybe there's another way of solving the problem for you.

Edit: also, with serialization Colyseus is able to tell which exact properties changed and send an update only for that single property (less bytes to send!). With non-serialized object, there's no way of precisely telling which part of it changed and when, so I imagine we would need to dump that whole object down the pipe.

[endel]

I was going to say exactly what @Zielak mentioned. The major problem would be detecting changes inside an untyped structure, and adding more dependencies to the decoder.

The built-in JSON decoder from Unity is quite limited, and wouldn't support decoding without having some extra types in the client-side for the particular structure. Msgpack could be used for this instead of JSON - but this would make the decoder coupled to a dependency, right now the @colyseus/schema has zero dependencies, which makes it easier to maintain. I'd prefer not adding any extra dependency here.

[dclipca]

What I need is storing objects in the state in a way that is compatible with serialization, then. I cannot do this with a Map because the Shema accepts only one type, I cannot use the type | type | type syntax as in Typescript.