[WIP] [Feature] Update SharePage when brew is edited

[G-Ambatte]

I was experimenting with the BroadcastChannel functionality and managed to create the following:

• When SharePage is loaded, subscribe to a BroadcastChannel with name shareId
• When EditPage is saved, post a new message in the shareId BroadcastChannel
• When SharePage receives an update message, confirm shareId and origin match; if so, perform a window.location.reload(), refreshing the brew and allowing effectively real time updates

Future improvements:

• a window reload loses the place in the brew, returning to the top; this can probably be resolved by instead sending the brew content and updating the brew state on the SharePage, causing only a re-render rather than a complete refresh.

Primarily, I see this as being useful for DMs who wish to present to their parties on a second screen - pull up EditPage on the hidden screen, and SharePage on the second monitor. Alter EditPage - for example, toggle an item's visibility from hidden to visible - and on saving, the changes will almost immediately appear on the SharePage.

[ericscheid]

This is very cool, btw.

[G-Ambatte]

I think this is pretty close to complete, actually. What else might we want from this functionality? What else is even possible?

[Gazook89]

I’m not advocating for it really, but maybe make it so that any update from the previous version is briefly highlighted before fading out? I don’t really know how this would work for anything besides just regular text changes, like changes to divs etc.

[calculuschild]

This is pretty cool.... It seems like one step behind actual live collaboration. I wonder how much more difficult it would be to just implement Codemirror's example for that?

[G-Ambatte]

It's not so much collaboration as it is a local subscription. I was thinking about CM6's atomic change model, which would as I understand it is essentially just sending the diff, which would be basically perfect for this kind of system.

One thing I did come up overnight is that if EditPage emitted a brewUpdate event on changing editors as well as on save, then EditPage would only ever need to send the content of the currentEditor (on save) or the editor just left (on Editor change). This would reduce the amount of data being transmitted via the BroadcastChannel. Once that's in place, a diff mechanism could be added to further reduce transmitted data.