Split <App> component to move away from shouldComponentUpdate hacks

UPDATE: this was temporarily fixed in #593, but long-term fix is to probably split <App/> into UI and canvas components.

What’s the problem? We don’t want certain state updates to rerender the UI, only the canvas. Currently, we achieve this by preventing the <App/> component update in shouldComponentUpdate, but manually invoking this.componentDidUpdate (for side effects — scene re-render etc.), which would still have access to previous state if we didn’t manually set this.state = nextState before invoking it. This is a hack, and we should move away from this because it may have unintended consequences in the long term.

---

OLD:

#574 prevents component update even when internal state (appState) did in fact change (such as during scrolling), while at the same time we manually invoke componentDidUpdate for side effects. But this means that the componentDidUpdate still has access to previous state, which results in at least one bug: the scroll is not updated on the same state update.

https://github.com/excalidraw/excalidraw/blob/a862d12ac14c85177a3c78b9e4a0068bebc88179/src/index.tsx#L229-L233

We could add another hack to that, and that is to invoke this.componentDidUpdate in a setTimeout, but I’m not sure if that’s foolproof (I’m not sure when exactly the state is updated. Immediately after shouldComponentUpdate?).

Probably a better way is to separate <App/> component into two compos. One for UI, one for canvas, and prevent the update only for the UI compo.

[dwelle]

Yea, but if we keep both compos in index.tsx, we don’t need even that.

[vjeux]

Feel free to do it after you land the multi arrow 😃