I’ve tried implementing the display as a <table>, as a grid of <div>s, and as a bunch of characters in a <pre>.
I’m working on it here: https://codesandbox.io/s/mzY6GYXr
The text-only mode works wonderfully. I get 100fps easily. It looks like an old terminal, which is kinda ok, but not really what I wanted. And it’s not clickable.
When using a table or a bunch of divs (for better styling and clickability) it gets super slow and consumes insane amounts of memory.
If you click the demo, there is a “Text/Table” button that lets you toggle between text-only vs divs (about same performance as table). Then you’ll see what I’m talking about. The speed difference is huge.
Is React not reusing the DOM elements? Is it recreating the whole thing instead of just changing the attributes? How do I find out?
I’m positive that the problem is in the rendering, not neighbor-checking or anything else in the logic. I’ve built three interchangeable components, <Table>, <TextTable>, and <DivTable> to test this and TextTable performs great.
I would appreciate any help tracking down this problem. Thanks!
I thought somehow the performance issue was that I was keeping all the state in the root component and sending it down to stateless cells in props.
(I’ve seen someone keep the alive state in the individual cells, so I thought that’s what I was missing.)
But this example is doing exactly that (keeping state in the root component) and it runs smoothly.
The difference is at least partially due to the fact that the demo you show is using window.requestAnimationFrame for the animation, which allows the browser to perform some important optimizations. Other than that, there’s too much code to debug here, so I can’t say anything for sure.
1 Like
I tried requestAnimationFrame in a different iteration, didn’t make a noticeable difference.
The text-only mode went even faster and more in sync with the display refresh rate (oscillators became almost still), but the table/div implementations remained very slow.
I saw a comment elsewhere (by you I think :)) saying that it’s normal for the React Way™ to be slower in this scenario, and that the official demo is fast due to a lot of non-declarative “cheating”.
There aren’t performance-related user stories, so I guess I’ll take it as an opportunity to learn React (which I think I did well; my code is reasonably well-structured), lower the number of grid cells to get better performance, and move on.
Thanks for stopping by!