Open simonbukin opened 12 months ago
Someone is attempting to deploy a commit to a Personal Account owned by @theosanderson on Vercel.
@theosanderson first needs to authorize it.
The latest updates on your projects. Learn more about Vercel for Git ↗︎
Name | Status | Preview | Comments | Updated (UTC) |
---|---|---|---|---|
cov2tree | ✅ Ready (Inspect) | Visit Preview | 💬 Add feedback | Jan 26, 2024 8:22pm |
Thank you for opening this! Adding comments piecemeal
@theosanderson Sorry for the delay here! Been a busy few months :)
I've looked more deeply into the minimap issues and I believe it has to do with the refactor I did for getting different views to update using setViewState
based on their respective viewId
s. The code was initially doing an empty return
instead of returning the currentViewState
, which was causing the viewState
on the next render to be undefined.
The above seems to have fixed the crash when dragging on the minimap. However, I believe the dragging behavior is still a little buggy, and I wanted to know if you had any input on the changes I made to fix the crash. I think we might be pretty close to a working minimap again, but I'm getting stumped by the current zoom code (mostly the role of mouseDownIsMinimap
, specialMinimap
and the old/new scaleX/Y values). Could you take a look at the refactor and see if you can spot a potential issue?
Again, really appreciate your help here!
Thanks for all your efforts @simonbukin. It's great that the crashing is fixed, but you're right that the behaviour is still buggy as compared to the intended behaviour.
The intended behaviour, as currently on Cov2Tree is:
I acknowledge that the view code is hard work to understand (for me). There has been a lot of trial and error to get it to behave in the intended way.
mouseDownIsMinimap
is intended to record that the user initially pressed down the mouse button within the minimap and so we should treat this action as a minimap drag, not as a pan. (And conversely, when this is false we should treat the action as a pan).
When mouseDownIsMinimap
is true, we in general stop the onViewStateChange
command from doing anything, in order to avoid the standard pan behaviour from happening: https://github.com/theosanderson/taxonium/blob/a8327427ef2f1ec8f623324c00418e21dbfae32b/taxonium_component/src/hooks/useView.jsx#L259
But we want to manually call onViewStateChange
in order to shift the zoom to the place that was clicked on in the minimap https://github.com/theosanderson/taxonium/blob/a8327427ef2f1ec8f623324c00418e21dbfae32b/taxonium_component/src/hooks/useView.jsx#L259. But if we have stopped onViewState doing anything when mouseDownIsMinimap is true, that won't work. So we define specialMinimap
which basically overrides the disabling in the case of mouseDownIsMinimap
and manually call it with specialMinimap
. The scale stuff is fundamentally about the fact that DeckGL doesn't support zooming in a single axis in a good way, and has been adjusted by trial and error to compensate for that.
(while we're on the minimap - I think it needs to either be overlaid over the tree rather than the map when the map is open, or just disabled in that case)
Also, if I enable treenome browser mode (not map) and zoom in on the tree, the preview crashes with https://legacy.reactjs.org/docs/error-decoder.html/?invariant=185
(closing/opening was just a hit-wrong-button thing!)
Thanks for the detail here! I'll take a crack at making it work to spec. I think emulating the empty return
using a setViewState
is going to solve most of the issues currently occurring with the buggy minimap, but I'll have to see how it goes.
I'll take a look at the Treenome crashing issue; I have a feeling I know what's breaking it.
I'm going to go ahead and disable the minimap when the map is open as a fix for now, but I believe it can be added back later and overlaid on the tree.
Thanks again!
This is a PR to add the WIP map view to Taxonium.
Next steps: