Fix #1106. Hydrate blocks on sync. #1107
Conversation
chenilim
requested review from
wiggin77,
sbishel and
jespino
and removed request for
a team
|
@chenilim shouldn't this happen on the server so that non-webapp clients also get fully formed blocks? |
|
@wiggin77, agree this could be refactored. The gray area here is that a missing property is technically valid JSON, it's just that parts of our webapp code assumes that all objects have non-undefined properties. I'll defer to you guys on the relative priority, but I can see moving the |
I think that valid JSON may not be a valid block based on whatever constraints/schema are expected. Someone using the REST API may expect valid blocks. I agree we should discuss how best to keep this in sync between webapp and server. I'll add it to dev meeting agenda. That said, I guess it doesn't hurt to merge this, provided we revisit. |
This calls HydrateBlock on synched blocks via the websocket. HydrateBlock calls the appropriate constructor, which ensures that all required properties are set. This fixes the general problem of client code dealing with blocks with incomplete or outdated schemas, such as after a server upgrade.
Previously, HydrateBlocks was called by the handler of wsClient, but was refactored out. Calling this at the wsClient layer will ensure that downstream code has complete objects.
This parallels the call to HydrateBlocks in OctoClient (for REST APIs).