Refactor and test legend code; show barplot legends #340
Conversation
(need to actually make this useful, but it's a start)
This rips out "node/tip/clade key" legend stuff. (The SVG exporting code might need updating, not sure.) This makes the code simpler, and should make doing biocore#299 easier
Closes biocore#331. this could still use some work, both in terms of cleaning up the code and in making long horizontal legend items cause the legend to scroll horizontally. i can tell it's the gradient-bar display which is breaking that -- either flex or grid seems to explode things
turns out inline block works. on reflection, using a <table> instead might be preferable -- that way the row structure is explicit, and we could freeze the color header column on horizontal scrolling.
allows frozen columns! todo prettify and abstract the code...
The UI is very unpolished, but this does close biocore#299.
Super messy and kinda ugly, but hardest part is over. here on will just be cleaning up the code / styling.
While I was throwing things at the wall to try to get the SVG to work, i thought that part of the secret sauce in Emperor's code might be its use of $() in creating / adding HTML elements. maybe it was, but in any case things work now.
in this case, the continuous values checkbox is hidden but it's still technically "checked". previously Colorer handled this case, but now some of that duty falls to the BarplotLayer class. We coould delegate it again to Colorer, but for now it's ok if untested and a bit kludgy
Looks pretty snazzy :3
This fixes two silly things: 1. after removing a layer, although below layers' nums changed, their HTML elements' IDs did *not* change. This caused problems, because it was possible to make a new layer with an old num and thus have its HTML elements' IDs match a current layer's elements' IDs, which messed up things like for="" attributes. Using a consistently unique number for the IDs fixes these problems. 2. When more than one gradient was present on the page, the oldest one would "override" any newer ones -- they'd have the same colors, even if the selected colormap was different. This was due to the gradient IDs all being the same. Fixing this (again using uniqueNum) solved the problem.
Also added a section on continuous values in the barplot legend
|
The following artifacts were built for this PR: empire-biplot.qzv, empire.qzv, empress-tree.qzv |
Thanks @ElDeveloper for pointing this out ._.
Co-authored-by: Yoshiki Vázquez Baeza <[email protected]>
Co-authored-by: Yoshiki Vázquez Baeza <[email protected]>
|
Thanks @ElDeveloper!
It should technically be possible, but I'm not sure it would be useful now for anything except feature metadata coloring without propagation (a.k.a. with the "Only use tip-level metadata?" checkbox unchecked). I think all of the stuff with calculating unique tips / branches for sample / feature metadata doesn't really (at least to me) make sense with quantitative data. (I guess you could have categorical groups where each group has its own number, hence the desire to color the groups by their numeric value, ...but that situation seems very unlikely to me.) I guess it would be possible to extend our current tree coloring functionality to work better with continuous metadata, though (I know ggtree has a lot of fancy support for this, e.g. this section of their docs. One option (that could be useful for things like Songbird differentials) could maybe be adding a new feature metadata coloring method where all tips have some continuous value, and then internal nodes are assigned the average (or median, etc.) of their children's values, and so on -- and then colors are assigned, creating a sort of gradient descending from the root of the tree. This could be kinda neat, but IDK if it'd be useful or not (@mortonjt, do you have any thoughts? :) |
|
@fedarko fair enough that makes sense. |
Closes #299 and closes #331. (Also counts as progress towards #142, since now
legend.jsis tested.) Also updates the barplots section of the README accordingly.This PR adds a pretty large amount of documentation / tests, both to new and previously-existing code.
Various notes