Add react compiler and its eslint plugin #132
Conversation
This also requires switching from @vitejs/react-plugin-swc to the standard @vitejs/react-plugin.
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
|
This pull request has been ignored for the connected project Preview Branches by Supabase. |
|
Upon profiling this seems to give us some real benefits mostly on the review interface, where there's a lot of rendering and where we're dealing with localStorage a lot so rerenders may be a little more expensive because of the scripting going on. Check the data here. This alone might be enough reason to go ahead and merge the compiler work. The Review interface is the main user journey in the app. If that's not delightful to use, the app will feel like a slog. You can also really SEE the difference here as we step through the cards no the Review page, noting the little orange hills in the profiler, with each one being another card navigation and render (of components that are already mounted, data already loaded): With the compiler
Without compiler
Pay special attention to the spacing of the clicks in this graphic. I'm going "click click click" at about 100 BPM here, not super fast, but a realistic speed for trying to quickly navigate from card 5 back to where you left off at card 15 or so (there is no button for "resume from my most advanced position so far"!) where you pause a brief second to see if it's a card that's been answered or not, and then click again. The key here is the subjective experience of clicking; if it feels laggy you're going to have a degraded experience, and the un-compiled review interface definitely feels laggy. There is a stutter and then it proceeds. Compare the width of those columns, which represents the length of time between the click and the updated interface. In most cases it appears to be (and feelds like) around 1/3 or 1/4 of the entire interval. I also notice that the JS Heap is a good bit smaller (uses less RAM) with the compiler on; nothing dramatic, but around 22MB while navigating the library page, compared to 18MB when compiled. I should note though that the other biggest slowdown in the app is clicking the filters in the library (which will become a huge pain when libraries are populated!). This screenshot from the profiler confirms that there is an issue with performance that scales with the number of cards being displayed in this moment. Not the number of cards being loaded, but being rendered right now!
These little red things are "forced reflows" where something tries to read the height of the window while the dom is being updated so it can't work in parallel. We can see that the red spots are split up across all these little slivers -- each of those represents a different phrase being displayed in the results. This can be fixed by changing the way we handle hiding/showing components, using the We might also put that section into its own scroll area so the window size isn't actually changing, or we may decide this is all the fault of the intersection observer that we use for our sticky navbar (here), and that without it the rest of the app is free to handle things in parallel. And finally, the biggest single delay of any loader in the entire app is without question whatever occurs when you load your review session -- even from another page where the required server data was already loaded. Start from the review page, set up review, then leave (go to library), and come back (click the "review" link in the nav, to use client side routing full), and you'll be greeted with something like 5 seconds of loading screen. The profiler's readout on this particular 4-7 seconds looks like a bloodbath whether the compiler is enabled or not. (This is with the compiler, but without it, it looks about the same.)
Note the JS Heap is topping out around 32MB, not actually huge for modern web, but the largest of any screen in the app by about 25%. Something in the main thread is doing thousands of operations. I think this is new behavior, perhaps after adding some of the localStorage operations for persisting review state (but I don't think it was doing this when we were just mounting and then grabbing localStorage non-reactively. Other work on #129 should address this particular delay, but it looks like the react compiler is not a fix. |
fixes #130