For the most part, at least. If the edge cases where they differ still feel weird, I can iterate on this further.
The diff is unfortunately a bit impenetrable, because I had to change both the fillGaps and cycleTileSize core algorithms used by the big grid layout. But: the main change of significance is the addition of a function vacateArea, which clears out an area within the grid in a specific way that mirrors the motion performed by fillGaps.
So that it doesn't cause unnecessary renders, and interprets a series of three clicks as a double-click followed by a single click, rather than two overlapping double-clicks. (That behavior felt odd to me during testing of NewVideoGrid, which is why I picked up this small change.)
by fixing the cause rather than the symptom: this upgrades the code to use the new, recommended JSX transform mode of React 17+, which no longer requires you to import React manually just to write JSX.
In preparation for adding layouts other than big grid to the NewVideoGrid component, I've abstracted the grid layout system into an interface called Layout. For now, the only implementation of this interface is BigGrid, but this will allow us to easily plug in Spotlight, SplitGrid, and OneOnOne layout systems so we can get rid of the old VideoGrid component and have One Grid to Rule Them All™.
Please do shout if any of this seems obtuse or underdocumented, because I'm not super happy with how approachable the NewVideoGrid code looks right now…
Incidentally, this refactoring made it way easier to save the state of the grid while in fullscreen / another layout, so I went ahead and did that.
We're now using LiveKit's magic RoomAudioRenderer component to make sure everyone's audio is rendered regardless of whether they have a tile in the DOM.
Calls are an environment with high cognitive load, so it's important that we keep extra UI elements like these to a minimum and stick to what's been explicitly designed. I assume that this was here as a developer feature to diagnose reliability of the back end components, which is perfectly fine, so I've kept it behind a developer setting rather than fully removing it.
This is an attempt to address the feedback in https://github.com/vector-im/element-call/pull/1099#discussion_r1226863404 that the video grid and video tile components have become too tightly coupled. After this change, the only requirements that the video grid makes of its child components are:
- They accept ref, style, and item props
- They attach the ref and styles to a react-spring animated element
Note: I removed the video grid Storybook file, because I'm not aware of anyone using Storybook for development of Element Call beyond Robert, and it would take some effort to fix to work with these changes.
So that we can load SFU with the virtual participants and get them
displayed in the grid layout. Before that only participants who are part
of the Matrix were displayed (i.e. participants who have published
m.call.member event to declare their participation).
The new grid layout has been broken ever since upgrading react-spring, because it was apparently relying on a buggy behavior of react-spring that started transitions automatically even in imperative mode. react-spring 9.5.1 fixed that behavior, which means we now need to manually start the animations.
