Switching between desktop and mobile layout causes you to leave chat

[ebroder]

This is of course because the CallSection component gets unmounted/remounted without carrying state across, but we should see if we can do better.

[zarvox]

Hmmm. Thinking about this, I think the two main options are:

• lift any relevant state/effects currently owned by ChatPeople all the way up to PuzzlePage, where the layout is determined, or
• figure out how to reconcile the two layouts to have the same component hierarchy, so React doesn't consider the two chat sections to have different identities, and thus won't unmount/remount when we switch rendered layouts.

The latter seems...super finicky and not very resilient.

I think the former is more viable but will probably mean a decent amount of prop/ref drilling and careful review of the lifecycle management of the call section. On the upside, it might make the layout effect hooks for scrolling chat flow more obviously.

[ebroder]

This might be a good opportunity to look into persisting call state across code pushes/reloads as well, since I remember that being a source of confusion. I had my eye on something like meteor/react-packages#333 for this, and plausibly it would give us an easier way to plumb that state through as well, although sadly it doesn't seem like that specific PR is ever going to land.

[zarvox]

So, that approach might work for some things, but I believe it will not work for anything in an actual production setting, because the mechanism that powers Meteor's reload package (which is used when you don't have hot-module-reload which only exists in developer mode) is https://github.com/meteor/meteor/blob/devel/packages/reload/reload.js#L217-L220 which relies on serializing all relevant data into localStorage, refreshing with the new code, and then deserializing the state back. That obviously doesn't work for a WebRTC connection object or things like that (which I think was the original focus of this ticket), but I suppose it could work for other bits like what form fields we're editing, collapse states, adjusted sidebar width, or chat input contents.

For developer tooling, I think the existing hot-module-reload can avoid unnecessary refreshes a good deal of the time?

As another point in design space for avoiding data loss during Meteor reload: Sandstorm had a scheme where if you had any grains open at the time, it'd inhibit reload from refreshing until you closed all of them or clicked on the "update available -- click here to reload" banner: https://github.com/sandstorm-io/sandstorm/blob/master/shell/imports/sandstorm-ui-topbar/topbar.js#L27-L55 . That approach makes it a bit more likely there are still old clients running around in the wild, though.