Temporal visibility

[jameshadfield]

This PR changes the temporal branch filtering to only highlight branches whose end-points (tips for terminal nodes) are within the current time slice (previously it was highlighted if any time point between the tip and the parent node intersected with the selected time slice).

Before:

After:

This isn't perfect, and doesn't address all the concerns in #473, but I think it's an improvement.

[trvrb]

I agree with the intention, but I don't think this works as implemented. It breaks the logic of how we calculate map transitions. Compare:

http://localhost:4000/zika?dmax=2014-05-11&dmin=2013-08-13
https://nextstrain.org/zika?dmax=2014-05-11&dmin=2013-08-13

You can see that the transition from Brazil to Haiti is definitely in the window. However, on the PR branch the map does not show this transition.

Consequently, if you click to play the animation, it appears quite broken. Same for Ebola.

I think this requires deeper changes to get working.

[jameshadfield]

Hmm, yeah the map animation looks much worse with this. But I also think the tree, as it currently stands, is extremely misleading (e.g. the first screenshot).

So in that time slice, there's a branch from an ancestral state of Dom. Rep. (which is within the selected time slice) to Haiti (outside of the slice). The migration event could have occurred anywhere on that branch (and included unsampled intermediates). For the tree, I think this PR is better than the current release, i.e. this branch shouldn't be displayed. But for the For the map, where we infer a gradual missile from Dom. Rep to Haiti over the branch length, this PR is terrible.

I wonder if a solution which changes the visibility array from containing hidden & visible strings to containing {0, 1, 2}, where 0 is out-of-selection, 1 is display on map, and 2 is display on map and tree would be an acceptable solution. This should preserve the tree behavior of this PR together with the current live behavior of the map.

One alternative would be to move the map slicing of these "partially in-selection" branches to redux state and changing the tree to draw those branches as partially in-selection, which is much more involved.

[jameshadfield]

This PR now extends the visibility array to allow nodes not to be displayed on the tree but to be processed by the map (as per proposal). I think this results in a much improved tree with no change to the map. I think this PR also effectively closes #473.

Before:

After:

[trvrb]

This is a really fantastic change. I didn't realize how broken the tree visibility really was until you added the gray boxing. With this in place, the animation looks substantially better on the tree.

Definitely a hacky solution, but one that seems to work really well in practice. My only code issue is the use of 0, 1 and 2 for the visibility array. This seems unnecessarily opaque. Would it make sense to call this hidden, visibleMap (or visibleMapOnly) and visible (visibleMapTree) or some such? Keeps me from doing mental gymnastics while looking at code.

[rneher]

this is great. I have avoided showing animations so far because their behavior was so odd. regarding Trevor's proposal: having integers as states might be good for performance reasons (I doubt it makes a big difference though) but reduce readability.
What about defining states like HIDDEN=0, 'MAPONLY=1, VISIBLE=2` or similar and use these names in the code (akin to preprocessor directives in C)

[jameshadfield]

Good ideas - now implemented using named constants NODE_NOT_VISIBLE, NODE_VISIBLE_TO_MAP_ONLY, NODE_VISIBLE.