Open bakesteve opened 10 years ago
@malonecj @d4nj0nes started this to get us moving take a look, add any missing detail / tasks and we can then get cracking
@bakesteve I'm not convinced that you should need to press a key to start editing a cell. Assuming that we make it very clear where the users' context is, and we have the ability to cancel changes by pressing ESC (or just not save pending changes immediately) then the first keystroke should just start editing. In fact, I think pressing Enter should just take the user to the cell below.
@leeandrews I've covered these off in the main section now: [Lee's added features - must haves]
[Lee's added features - nice-to-haves]
@bakesteve if not already covered, we should look to use an appropriate column width for grid columns. By appropriate, I mean it should be determined by the length of the header and the expected length of the contents of the column. Where we have a more than one word in the header and the expected length of the contents is significantly shorter, perhaps we wrap the header text.
Tracker for what we'd like to have out of a react grid
See SlickGrid for a very strong implementation of features
Other Grid componnets
Griddle looks good, though missing number of features React-Grid the original version of this. no edits/navigation ReactiveGrid more of a PoC but has got keyboard navigation
Todo / Wish List
Keyboard Navigation
Tasks
Initial design thoughts
One immediate issue is React doesnt delegate KeyUp unless you are in a form field, so will need to resort back to native / jQuery in
ComponentDidMount
We also need to know what row we are on. Cells probably shouldnt be aware of that (though that may too restrictive) Also need to be carefull about indexes for rows (needs to understand data index, not the display index) and columns (frozen columns, hidden cols, etc) < in both scenarios if we have a cell.idx and a row.idx we will be fineRenderers
Initial thoughts
Controlled through column.celRenderer Needs to control style and text display. Common use cases will be formatting a number as a currency May need access to several data attributes, so need to think out how this is done
Also need to think about allowing custom formulas, and allowing overrides for them - see locked editors. The renderer should indicate if a cell is ReadOnly, Overridable, or Editable. If the value has been overriden, this should be flagged in a consistent manner
Editors
Initial design thoughts
We can control the editor easily enough through the
column.renderer
property, but need to know if the cell is being edited or not. Grids are, by design, going to be killing off rows (and cells) as you scroll, so cant use state to manage that. We also want mouse clicks elsewhere to commit the edit, so that implies state is held at a higher level. Using a prop, seems like a better choice.**Commiting an edit*** Assumed flow would be:
Editor.onCommit=>Editor.Valdate=>Cell.handleCommit=>Cell.onChange=>Row.handleCellChange=>Row.onChange
Canvas and Viewport make this chain a bit longer to then bubble up to the grid so that we can update the data store/state. We could probably jump from Row -> Grid/Store. May be a case where Flux helps outEditor controls Simple editors (numbers, dates, etc) will be straightforward. But some editors will require a lot more info than may be contained in a simple key/value set that a cell operates on. A few things to consider
Keyboard navigation We will want pressing Tab in an editor to either:
Validation commiting an edit should call a validate function. Needs to be a standard way to provide user feedback, and the commit edit shoudl be blocked till this returns true
Sorting
Should be easy enough, just need the UX and a sorting algorithm Also need to ideally add custom sorting via drag handlers. Again, should just be the same When designing, should extend the simple sample to give the capability for multiple levels of sorting, and sort by (ie sort by Name: Z-A, then by Country: A-Z (or Id, using ISO code?), then by Age: 0-9, then by Date: Oldest to Smallest)
Override Locked Editors
Need to distiunguish between cells that are Editable, ReadOnly, and Overidable If it is overidable, the cell renderer shoudl indicate this in the same way as ReadOnly, but ideally we'd have teh same user experience for editing - possibly with some UX highlights to show this is overiding.
Drag Down
Ideally done as a form of UX mask
Need to think how we:
Copy and paste
Ideally handled at a high level, using OnCopy and OnPaste events Assuming we have an [Active Cell]() concept, then should be ok to grab that in Copy, and push it on Paste
Undo / Redo
At first glance this is very, very easy (thanks react!) however, want to be more efficient that just storing entire object graphs on every change. We want something that works with large collections (100 cols x 1000s rows) with a large number of edits Maybe do something esoteric like storing individual changes with functional lens to apply that back ontop of the main data?
Performance
Should be bloody fast, but need to ensure we only update the dom if we need to ideally that would just be using immutable data (by convention, or being clever