search

simularium / simularium-website

Front end website for the Simularium project, includes the Simularium viewer
https://simularium.allencell.org
Apache License 2.0
6 stars 3 forks source link

Fix/debug time slider #529

Open ascibisz opened 1 month ago

ascibisz commented 1 month ago

Time estimate or Size

small

Problem

There are a variety of issues with the time slider in Simularium right now, so here's my stab at trying to fix it!

Some of the issues are described in this ticket, which links to this spreadsheet from the octopus bug bash.

Solution

So I did two changes to address some of the issues we're seeing on the time slider, but I'm open to suggestion if there are other ways to better solve it.

  1. I removed setBuffering(true); when we skip to a new time. In the current state, when you slide the time slider, it is continuously switching between the buttons showing as spinners and the buttons showing normally, because every time the slider moves to a new frame, we set buffering to true until the frame is received and it gets set as false, which is a weird user experience. While this eliminates that weirdness when you're sliding the slider, it could be an issue if a frame we just jumped to is actually taking a while to load, in which case the loading state where the buttons are spinners wouldn't show up. I couldn't actually get this case to occur through manual testing, but I'm sure it'd be possible if the octopus cluster was really overrun and it was in the process of starting up a new container to handle the increased traffic. If we're worried about this, maybe I could add some logic so we only show the spinners if buffering has held as true for some non-trivial amount of time?
  2. I removed the antd Slider's onAfterChange functionality and simplified the onChange functionality. We were having issues with having the right frame actually get displayed when jumping / sliding around a lot on the slider, and sometimes we would end up in a state where everything was stuck loading. As part of my debugging process, I removed various pieces of functionality to see how they were impacting the performance, and a lot of our problems seemed to be solved when we just directly called onTimeChange from the sliders onChange? I also poked around in some of our other repos that use this component, and none of them were using onAfterChange. This code has been this way for a couple years, maybe the reason we needed this extra functionality originally (either because of antd or some of our own code) is no longer relevant?

Type of change

github-actions[bot] commented 1 month ago

Coverage report

St.:grey_question:
 Category Percentage Covered / Total
🟡 Statements 66.32% 644/971
🟡 Branches 65.73% 94/143
🔴 Functions 35.1% 86/245
🟡 Lines 64.72% 576/890

Test suite run success

104 tests passing in 7 suites.

Report generated by 🧪jest coverage report action from 2a1ba9ff47058fecff2198d9e457defa2a56218d