Open eharkins opened 6 years ago
If we literally do this one based on all the sequences that we have, as its done here, there will be considerable scalability considerations without making the client/server request layer more complicated in order to slice up all the data.
Because the data won't be able to be loaded immediately on brush select, and because just in general we know we have to be careful about rendering too much on brush select (see #2), it's probably better that these not go in the table, as I was thinking initially.
If we do violin plots like this, it's probably best that its done as part of a more detailed view that unfolds when you click on a tree.
Another way to go here is to try and use the minadcl tree as a downsampling mechanism for summarizing the entire cluster of sequences (see #36).
We discussed limiting the scope of this to be able to have one violin plot for the selected family. This still requires loading per sequence metadata.
Is this v1 or v1-bonus?
I think we should save this for when we're scaling up and messing around with all the other data-in issues, and have moved this issue into the Scaling Up board.
Use per sequence metadata to create violin plots: