Grid UX: keyboard navigation while in interactive mode

[juanca]

Motivation

1. There are too (two) many keystrokes in the following workflow: edit a cell; navigate to adjacent cell; edit the cell.
2. There exists a precedence for navigating between "cells" via <tab> and <enter> (along with the <shift> modifier key) in other grid-based interfaces

Changes

Given that a cell knows about its own reference, it also consumes the references to adjacent cells. Upon the appropriate key strokes, it focuses the appropriate adjacent cell -- exactly how <Grid> manages arrow navigation.

There is some duplication between <FancyInputGridCell> and <InteractiveGridCell>. There is also some duplication between <FancyInputGridCell> and <Grid>. I would like to focus on improving these two aspects of the codebase. The solution might involve an overhaul in the architecture of the Grid and its related components. Given that particular risk, I will make it its own PR as this is just a proof of concept for better UX.

[juanca]

There is one last bug.

This really isn't about the interactive mode. I've just found it through more extensive testing.

Essentially, the reproduction steps:

• Focus a grid cell (but do not enter interactive mode)
• Tab into some element outside the grid (e.g. a Tab)
• Click on a different grid cell

Expected: Only the newly selected grid cell should have tabindex="0"

Actual: Both the last focused grid cell and newly selected grid cell have tabindex="0"

This is due to the fact that we're using focus and blur events for managing the tab index on the grid cell layer.

I might try to explore other solutions (possibly with context) or hoist the state up. If there is pretty bad performance issues, I might introduce virtualize rendering for large grid. Hoping small and medium grids will have acceptable performance.