Skip to content

multiple selections on parcoords axes #2415

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.

Sign up for GitHub

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

Merged
merged 26 commits into from
Mar 21, 2018
Merged

multiple selections on parcoords axes #2415

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
26 commits
Select commit Hold shift + click to select a range
9208cc3
- factored out brushing
monfera Feb 5, 2018
40b0c2b
- full refactor of shader code, DRY, optimizations etc.
monfera Mar 3, 2018
7f507c3
remove constraintrange from parcoords mocks
alexcjohnson Mar 6, 2018
d25d261
tweak the parcoords constraint grabber ranges
alexcjohnson Mar 9, 2018
367e294
parcoords constraint cleanup
alexcjohnson Mar 12, 2018
1030542
dimension.multiselect boolean attr
alexcjohnson Mar 12, 2018
c046397
Merge branch 'master' into parcoords-multiselect-squashed
alexcjohnson Mar 12, 2018
a4f4a5f
info_array dimensions='1-2'
alexcjohnson Mar 13, 2018
a78db76
finalize multiselect functionality
alexcjohnson Mar 15, 2018
01ba11e
:hocho: fdescribe
alexcjohnson Mar 15, 2018
68e9e48
lint axisbrush
alexcjohnson Mar 15, 2018
cb00901
fail -> failTest - fail is a jasmine global
alexcjohnson Mar 15, 2018
f2690ac
fix one more filter bug, refactor parcoords test to hopefully reuse c…
alexcjohnson Mar 15, 2018
ec44922
refactor more of parcoords test to use Plotly.react
alexcjohnson Mar 15, 2018
352a884
parentElement -> parentNode
alexcjohnson Mar 15, 2018
57085e1
shorten parcoords snap tweening during tests
alexcjohnson Mar 15, 2018
fff668a
@flaky on ordinal constraint snap test
alexcjohnson Mar 15, 2018
6fe2d79
I give up... @noCI my new tests
alexcjohnson Mar 15, 2018
2911ae6
:hocho: parcoords memory leak
alexcjohnson Mar 16, 2018
fa1a436
parcoords create/update pattern
alexcjohnson Mar 16, 2018
0e75c5a
parcoords test cleanup
alexcjohnson Mar 16, 2018
a7bd686
click to select an ordinal value
alexcjohnson Mar 17, 2018
6432b89
cleanup, and remove some obsolete code
alexcjohnson Mar 17, 2018
03d8779
tweaked parcoords mocks
alexcjohnson Mar 19, 2018
f147644
Revert "tweaked parcoords mocks"
alexcjohnson Mar 19, 2018
c3cc927
fix bug introduced in cleanup
alexcjohnson Mar 19, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 16 additions & 2 deletions src/traces/parcoords/attributes.js
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -80,8 +80,22 @@ module.exports = {
valType: 'info_array',
role: 'info',
items: [
{valType: 'number', editType: 'calc'},
{valType: 'number', editType: 'calc'}
{
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This just shows the current structure, there won't be a limit of two specified intervals.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(for my own notes, @monfera don't worry about this unless it's blocking you)

If we merge in master, particularly #2399, we can use 2D and/or unbounded free-length info_array.
I'm not sure the best way to handle it though - since the vast majority of cases will still use a single range, I'd like to keep constraintrange 1D rather than forcing people to wrap it into 2D. So the two options that occur to me are:

  1. make it a length-2N array, ie [min1, max1, min2, max2, min3, max3...] - this would be fairly simple for us to work with, and seems easy to describe to users, not sure how intuitive it will be for them to use though.
  2. make a separate 2D attribute constraintranges that we switch to when there are multiple ranges. That would be more plumbing on our side, and we'd have to decide which one wins in a conflict, but the structure may be more intuitive.

@etpinard thoughts?

Copy link
Contributor

@etpinard etpinard Mar 1, 2018 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Users should not have to make constraintrange 2D to set a single constraint.

I'll like to add a third option, make constraintrange 1D OR 2D. This would be a first for info arrays, but note that some data arrays already use this pattern (e.g. heatmap x and y).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another aspect is that the functionality is initially discussed specifically for ordinal dimensions, where it'd be natural to simply list values, eg. [1, 5, 8, 12], and even to mix singular values and ranges, like [1, [5, 8], 12] meaning 1, 5 to 8 and 12. It would be possible to support this, but it wouldn't blend well with using an 1D array for a single range, because then an 1D array with two elements could be interpreted as either a single range, or as two discrete values.

valType: 'info_array',
editType: 'calc',
items: [
{valType: 'number', editType: 'calc'},
{valType: 'number', editType: 'calc'}
]
},
{
valType: 'info_array',
editType: 'calc',
items: [
{valType: 'number', editType: 'calc'},
{valType: 'number', editType: 'calc'}
]
}
],
editType: 'calc',
description: [
Expand Down
Loading