What is your suggestion?
I think it would be neat to support calculation transforms inline in encodings similar to how it is currently supported for aggregations. I have an implementation suggestion for this in #3991, but I think we could have some discussion around which syntax we prefer before reviewing that in more detail.
In the PR I went with autodetection of when an alt.expr is passed to and encoding field, e.g. encode(x=alt.expr.random()). I considered using magic strings just as for the aggregation transforms (e.g. x='random()'), but it seemed a bit brittle and would not leverage our expr submodule. A more promising alternative I considered was a .calc method, e.g. alt.X().calc(alt.expr...). I see pros and cons of this approach:
Pros:
- Allows additional parameters, e.g.
as=new_field_name for naming the calculated field.
- It could be argued that we should prefer
alt.X(...).agg() over the current magic strings aggregations and then .calc() would be more consistent with that approach.
- Potentially composable with other methods, such as
agg(), e.g. alt.X().agg(...).calc(...) could allow a calculate transform involving the aggregated field.
Cons:
- More verbose and potentially more cryptic. Compare the simple form
yOffset=alt.expr.random() to the longer alt.yOffset().calc(alt.expr.random()) . It seems a bit redundant to both spell out .calc and alt.expr, since the fact that a calculation would be performed can already be inferred from that alt.expr is used.
- Maybe a bit less natural when a value from a parameter is being passed, since it is not obvious that a calculation should be performed to grab the parameter value (PR with example coming soon)
Have you considered any alternative solutions?
No response
What is your suggestion?
I think it would be neat to support calculation transforms inline in encodings similar to how it is currently supported for aggregations. I have an implementation suggestion for this in #3991, but I think we could have some discussion around which syntax we prefer before reviewing that in more detail.
In the PR I went with autodetection of when an
alt.expris passed to and encoding field, e.g.encode(x=alt.expr.random()). I considered using magic strings just as for the aggregation transforms (e.g.x='random()'), but it seemed a bit brittle and would not leverage ourexprsubmodule. A more promising alternative I considered was a.calcmethod, e.g.alt.X().calc(alt.expr...). I see pros and cons of this approach:Pros:
as=new_field_namefor naming the calculated field.alt.X(...).agg()over the current magic strings aggregations and then.calc()would be more consistent with that approach.agg(), e.g.alt.X().agg(...).calc(...)could allow a calculate transform involving the aggregated field.Cons:
yOffset=alt.expr.random()to the longeralt.yOffset().calc(alt.expr.random()). It seems a bit redundant to both spell out.calcandalt.expr, since the fact that a calculation would be performed can already be inferred from thatalt.expris used.Have you considered any alternative solutions?
No response