BigFatDog/parcoords-es

brush.move instead of brush.extent in brushExtents

timelyportfolio opened this issue · 7 comments

In #6, a very helpful brushExtents method was fixed and provided to the API. However, when setting brushExtents, I think we should use brush.move instead of brush.extents. I'm not sure how best to provide a reproducible example, so I recorded the screenshot below. I will submit a pull. Thanks.

parcoords-brush-extents

Actually, to fix we only need to comment one line.

@BigFatDog now the question is what to do with brushExtents without arguments, since this will now only return the unhelpful potential range for the brush. I'm thinking we should return an object with dimensions as keys and the inverted brushSelection as the value.

How about this?
brushExtents returns objects with value in the following format:

extent, //the current return value of brush.extent
brushRange, // brush selection
dataRange // corresponding data range

Code modifications

const brushRange = brushSelection(brushNodes[cur]);
acc[cur] = {
          extent: brush.extent(),
          brushRange,
          dataRange: [
            config.dimensions[cur].yscale.invert(brushRange[0]),
            config.dimensions[cur].yscale.invert(brushRange[1]),
          ],
        };

@BigFatDog, I like this and will closely match our extra information from brush events (https://github.com/BigFatDog/parcoords-es/pull/44/files). I am wondering though should we use the same names - selection for dataRange and selection (raw) for brushRange. Also, we will need to use the invertCategorical (lines) for categorical scales. Should we move invertCategorical so that it is more generically available since we now have > 1 uses?

Thanks!!!

Your point makes sense. Pull request #55 has been created.

version 2.2.3 has been released to deliverd this enhancement.

@BigFatDog going to close; thanks again