Framework: Refuse to persist any UI state

[aduth]

This pull request seeks to update the base state.ui reducer to always return an empty object on the DESERIALIZE and SERIALIZE action types, thereby preventing any state contained within from persisting or restoring persisted state.

Open questions:

Is this desirable? Effectively, this treats UI state as disposable to the extent that it should not be restored upon revisiting the application. This seems reasonable (arguably required) in the web client, but is more debatable in the context of the desktop application. We should ask ourselves whether it seems reasonable that UI state be persisted between sessions of using the desktop application.

/cc @gwwar , @mtias

[aduth]

Failing tests seem to be partly related to intermingling server state hydration with persisted state deserialization. We'd probably want to rethink this if we decide to move forward with these changes.

[gwwar]

It does seem our concerns are mixing a bit with regards to server initialization. Maybe we should be a bit more explicit about this. We could do an unbalanced serialize that only returns an object, and a deserialize method that still attempts to hydrate state. Alternatively there could be a separate hydration pipeline for server state.

cc @seear

[seear]

Alternatively there could be a separate hydration pipeline for server state.

This would be perfectly fine. The only reason for passing bootstrapped server state through the deserializer is to take advantage of the conversion to immutable data. That can be done elsewhere to keep bootstrapping separate from deserialization.

[gwwar]

This would be perfectly fine.

👍 Added a quick approach for this in #3343

[gwwar]

@aduth since #3343 landed, ping me when you rebase this branch, and I can help update the initial-state.js test to use a different subtree than ui.

[gwwar]

👍 I don't believe we have any blockers left. 🚢

[aduth]

Rebased to account for additional UI state added in #3430 .

Will plan to merge shortly.