You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In 54e79fc, I made the line and area mark sort by z, since this matches the behavior of dot and bar, and I think it’s a more sensible default. However, you might want to sort by a different order, for example, if you want to highlight a few series and draw them on top. Or you might be applying the stack transform which computes its own order, and want to use that order.
So, should the line and area marks take an order option, too? Perhaps the default order is “ascending z”, but it could support other orders. And perhaps the stack transform should explicitly set the returned order to null (a.k.a. index order), so that the downstream mark respects the order computed by the stack transform?
Also, I think we should think a little more about the names of the stack orders. Currently we don’t directly support an equivalent “ascending z” order for the stack transform — you have to specify the order option as the same value as z. Also, the names of those orders can conflict with the field names in the dataset, which I find a little confusing since it’s not obvious from reading the code whether it’s referring to a built-in order or a field name.
I reverted sorting by z in line and area in favor of the more explicit sort option added in #205. I think it might still be nice to sort by z, but we need a way to disable it if it’s not desired… and for now, sort seems to do the trick.
Maybe the answer here is that dot and bar should not sort by z, and instead should respect the sort option. And then z is strictly about series (grouping) rather than z-order.
In 54e79fc, I made the line and area mark sort by z, since this matches the behavior of dot and bar, and I think it’s a more sensible default. However, you might want to sort by a different order, for example, if you want to highlight a few series and draw them on top. Or you might be applying the stack transform which computes its own order, and want to use that order.
So, should the line and area marks take an order option, too? Perhaps the default order is “ascending z”, but it could support other orders. And perhaps the stack transform should explicitly set the returned order to null (a.k.a. index order), so that the downstream mark respects the order computed by the stack transform?
Also, I think we should think a little more about the names of the stack orders. Currently we don’t directly support an equivalent “ascending z” order for the stack transform — you have to specify the order option as the same value as z. Also, the names of those orders can conflict with the field names in the dataset, which I find a little confusing since it’s not obvious from reading the code whether it’s referring to a built-in order or a field name.
Ref. #193 (comment)
The text was updated successfully, but these errors were encountered: