Conversation
I was a bit schizophrenic about this before...
|
🌟 Looks pretty clean! |
| @@ -1,6 +1,4 @@ | |||
| import collections | |||
| import inspect | |||
| import sys | |||
There was a problem hiding this comment.
dunno why, but locally npm run lint asked me to make the changes in this commit, even though on CI it passes 🤔
There was a problem hiding this comment.
Running the same versions? I've found that the default rules are updated frequently..
There was a problem hiding this comment.
oh actually npm run lint excluded a whole bunch of rules that we really don't need to exclude (as long as we're excluding the auto-generated files, which we are). I'll un-exclude them. Probably worth taking a look at this in other repos as well... it makes sense to have looser linting in tests but some of these rules are useful - like unused imports, can improve perf, only files setting up namespaces have any reason to include them.
| let endCol = end_cell && end_cell.column; | ||
|
|
||
| if (selectingDown) { | ||
| if (active_cell.row > minRow) { |
There was a problem hiding this comment.
I changed the logic here to be explicitly rectangular - ie picking out the region edges, editing these, and then recreating the selected_cells list from that at the end - rather than directly manipulating selected_cells as you had previously. I did this because it seemed both clearer and faster, I needed the new edges anyway for end_cell, and this way selected_cells will always be ordered as it appears on screen.
I considered changing these conditions from active_cell to start_cell. These are only different if you move active_cell after making the selection (via tab or enter), and as it stands some weird things can happen to the selection if you alter it via shift-arrow at that point - it's hard to predict whether shift-down will add a row at the bottom or remove one at the top. If I used start_cell instead of active_cell here, the cell you first clicked on would always be a corner of the selection, and shift-arrow would move the opposite corner. But there are two problems with that approach: (1) after you've moved active_cell, there's no visual indicator of which corner you started on, and (2) it's possible to shrink the selection so active_cell is no longer part of the selection. So in the end I left it with active_cell, but we could revisit that.
| const newStartCol = endCol === minCol ? maxCol : minCol; | ||
|
|
||
| if (startRow !== newStartRow || startCol !== newStartCol) { | ||
| newProps.start_cell = makeCell( |
There was a problem hiding this comment.
updating start_cell only for that strange situation of reshaping the selection after moving active_cell
| newProps.selected_rows = R.map( | ||
| // all rows past idx have now lost one from their index | ||
| i => i > idx ? i - 1 : i, | ||
| R.without([idx], selectedRows) |
There was a problem hiding this comment.
This was a bug previously - delete a row and any selected rows after it kept the same index, not the same row contents.
| data: R.remove(idx, 1, data) | ||
| data: R.remove(idx, 1, data), | ||
| // We could try to adjust selection, but there are lots of edge cases | ||
| ...clearSelection |
There was a problem hiding this comment.
previously we left selected_cells intact when deleting a row, and only cleared active_cell if it was actually deleted. But that has some problems, and for simplicity and symmetry with deleteColumns I decided to just clear the selection here too.
| loadNext: () => { | ||
| pagination_settings.current_page++; | ||
| setProps({ pagination_settings }); | ||
| setProps({ pagination_settings, ...clearSelection }); |
There was a problem hiding this comment.
Clearing cell selection on page changes. You can select rows on separate pages and have them stay selected... but that's with row-by-row checkboxes, an inherently stickier interaction that feels right to persist even when a checked box is on a hidden page.
| * And when you've selected multiple cells the browser selection is | ||
| * completely wrong. | ||
| */ | ||
| window.getSelection().removeAllRanges(); |
There was a problem hiding this comment.
For example, shift-click to select in the first example at https://dash.plot.ly/datatable:

| @@ -1,57 +1,69 @@ | |||
| import * as R from 'ramda'; | |||
| import { SelectedCells, ICellFactoryProps } from 'dash-table/components/Table/props'; | |||
| import { min, max, set, lensPath } from 'ramda'; | |||
There was a problem hiding this comment.
I made a couple of forays into specific ramda imports - my local linter complains about * as R and as @chriddyp pointed out (somewhere?) we may get a lighter build that way too.
There was a problem hiding this comment.
Yes. Depending on your linter / editor's capacity to handle tsconfig, it may or may not handle the typescript option for * as R. This is allowed because of "allowSyntheticDefaultImports": true, in tsconfig.base.json.
The way imports are used here webpack should prune the unused content automagically but this is fine too.
| minRow: min(row, start_cell.row), | ||
| maxRow: max(row, start_cell.row), | ||
| minCol: min(col, start_cell.column), | ||
| maxCol: max(col, start_cell.column) |
There was a problem hiding this comment.
Oh hmm, here I used start_cell and not active_cell like I did in the keypress handler... and indeed it can have weird effects like active_cell becoming outside the selection. So one of these should change... which one?
There was a problem hiding this comment.
standardized on active_cell like keypresses #412 (comment) -> 1c69cfb
| // don't update if already selected | ||
| if (selected) { | ||
| return; | ||
| } |
There was a problem hiding this comment.
BTW in case of shift-click I think this return is problematic - it means you can't shrink a selection without doing something hacky like first clicking over to the other side of the starting point.
src/dash-table/dash/DataTable.js
Outdated
| * The row and column indices and IDs of the currently active cell. | ||
| */ | ||
| active_cell: PropTypes.array, | ||
| active_cell: cellCoordsIDsProp, |
There was a problem hiding this comment.
Assuming the resulting metadata.json is correct b/c the value is defined in the same file?
There was a problem hiding this comment.
oh good call... looks like I can't 🌴 this in the existing react-docgen implementation
| />)); | ||
|
|
||
| const columns = ['a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i', 'j'] | ||
| const columnsA2J = ['a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i', 'j'] |
There was a problem hiding this comment.
Does A2J stand for Alex Johnson was here? 🤔
There was a problem hiding this comment.
haha I almost called it columnsAJ but thought that might be too selfish. It's supposed to be just 'a' -> 'j'
|
@Marc-Andre-Rivet ready for review. I didn't change |
| "private::host_js": "http-server ./dash_table -c-1 --silent", | ||
| "private::lint:ts": "tslint '{src,demo,tests}/**/*.{js,ts,tsx}' --exclude '**/@Types/*.*'", | ||
| "private::lint:py": "flake8 --exclude=DataTable.py,__init__.py,_imports_.py --ignore=E501,F401,F841,F811,F821 dash_table", | ||
| "private::lint:py": "flake8 --exclude=DataTable.py,__init__.py,_imports_.py dash_table", |
There was a problem hiding this comment.
Thanks for cleaning that up / removing the exceptions
| // there should always be an active_cell if we got here... | ||
| // but if for some reason there isn't, bail out rather than | ||
| // doing something unexpected | ||
| return; |
There was a problem hiding this comment.
If this is unexpected, maybe add a Logger.warning here
Marc-Andre-Rivet
left a comment
There was a problem hiding this comment.
This looks pretty good to me 💃 Thanks for all the additional clean up.
Row ID support - closes #312
data- each row can haveidkey, used as row id (can also be displayed if there’s a column withid='id')active_cell->{row, column, row_id, column_id}selected_cells-> array likeactive_cellselected_rows-> addedselected_row_idsstart_cellandend_cell-> these actually didn't seem to be wired up? Now they look likeactive_cellderived-> addedderived_viewport_row_idsderived_virtual_row_idsderived_virtual_selected_row_idsderived_viewport_selected_row_idsStill need to add tests, but AFAICT it works as intended.
Simple test app with pagination (so at least
viewportindices are different) and row selection & deletion: