Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Transform inverse mapping #2126

Merged
merged 8 commits into from Oct 27, 2017

Conversation

Projects
None yet
2 participants
@monfera
Copy link
Contributor

commented Oct 26, 2017

  • generating original points for transform results so that, upon interaction such as crossfiltering, the original (constituent) points can be recovered
  • cascading these points through a (purportedly) arbitrary sequence of filter and aggregation steps (groupby not yet supported)
  • adding test cases for these (also, we didn't have heterogeneous transforms testing with both filter and aggregate in the past)

There's still so much to do (PS: now documented the follow-up issue #2128); eg. more test cases; covering groupBy and sort. There's plenty of things to iterate on here.

On the pro side, the code change is rather small in terms of lines; also, the logic didn't need to change. So it's an add-on patch rather than anything heavy.

}

opts.indexToPoints = indexToPoints;

This comment has been minimized.

Copy link
@alexcjohnson

alexcjohnson Oct 27, 2017

Contributor

Since this isn't a real attribute but we're putting it back into fullData lets give it an _ - ie opts._indexToPoints.


done();
});
});

This comment has been minimized.

Copy link
@alexcjohnson

alexcjohnson Oct 27, 2017

Contributor

Thanks for testing this! Nice to see indexToPoints cascade through the transforms.

@alexcjohnson
Copy link
Contributor

left a comment

_ is the only blocking comment, this looks great. Really clean and easy!

With this in place you can get what you need for crossfiltering, and nothing you did will need to change as we extend this, so I'm all for merging this with only that change.

But to use this mapping, you have to dive into _fullData and look for transforms. Seems like it would be more powerful if this were already part of the event data. I'm not quite sure the right way to do this though... possibly just attach a new attribute like event.points[i].inputPointNumbers? If there are no transforms this would just be [pointNumber] or pointNumbers, but if there are, it would map whichever of those exists through _indexToPoints? That way you could always just use inputPointNumbers. Also since any trace type could have a transform (and at this point all or nearly all types produce pointNumber(s) fields), it would be nice to find a clean way to apply this to all events consistently. But again, lets do that in a separate PR. Really great idea to go in this direction, and I'm pleased that it's turning out to be pretty straightforward to implement!

@monfera monfera force-pushed the transform-inverse-mapping branch from 0bcf7a6 to 70a0f68 Oct 27, 2017

@monfera monfera force-pushed the transform-inverse-mapping branch from 40158ef to ce3a118 Oct 27, 2017

@alexcjohnson
Copy link
Contributor

left a comment

Very nice, thanks! 💃

@monfera monfera merged commit fd3a5b8 into master Oct 27, 2017

1 check passed

ci/circleci Your tests passed on CircleCI!
Details

@monfera monfera deleted the transform-inverse-mapping branch Oct 27, 2017

@monfera monfera referenced this pull request Nov 3, 2017

Merged

Persistent point selection #2135

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.