Skip to content

Add the ability to serialize an object in a way that its deserialization isn't fully done at the same time #61

@marchant

Description

@marchant

This is important for performance reasons, to avoid deserializing objects that are only used in certain conditions. A good example is a tab view, where an horizontal control with multiple segments allow a user to switch the UI underneath when a different segment of that control is used.

It's not great to load the full UI of all segments upfront, which is what happens now, instead of doing it only when a user choose one of the other segments, lazily, which is much more efficient.

However, from an authoring usability stand point, it is very convenient and easy to have everything in one place today.

So the proposed compromise when deserializing is to instantiate every top-level objects as we do today, so bindings / assignments work as expected, a property would still get the same object, therefore not changing the nature of what is deserialized, but it would be on the object pointing to one desired to be lazy, to specify it as such, and would therefore be in charge of triggering the completion of the deserialization of that object.

A proposal would be to introduce:

"someObject": {
"prototype": "...",
"values": {
"myProperty": {"~": "aComponentDeserializedLazily"}
}
},
"aComponentDeserializedLazily": {
"prototype": "...",
"values": {
...
}
}

where {"@": "anObjectDeserializedLazily"} does it all in one shot today.

Finishing Deserializing an object

Based on a first test, it looks like this should work without major surgery to the serialization logic, however we need to finalize what "someObject " would have to do on its myProperty's value to finish the deserialization of that value.

The phase of the serialization involving loading assets (code or serialization) needed to instantiate an object is async, but that is over when someObject would need to trigger finishing the deserialization of its myProperty's value before it can fully use it. However, if the object to finish deserializing is a components

A transparent way to hide the fact that an object needs to have its deserialization completed would be to associate it with a "catch-all" proxy. For someObject, its myProperty would contain the type of object expected, as Proxy are transparent, but any usage it myProperty - method call, getter or setter, would be intercepted by the proxy handler where we could seamlessly invoke the logic to finish the proxy's target deserialization.

This would add the overhead of a proxy object, but feels worth it for the easy of use it would bring. To be experimented with to make sure it would work!

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions