Modal views: shall be easily editable without using mouse

[teosarca]

To fix this issues open problems, please use the existing branch `dev2156 -fix` (or a subranch of that, if you want)

Is this a bug or feature request?

FR

What is the current behavior?

Which are the steps to reproduce?

What is the expected or desired behavior?

Consider a view which has a numeric column which is editable.

That column shall be nice and smooth editable a user, using only the keyboard. Similar feeling like editing in Excel, i.e. write the number, press down, write the number, press down (or up).

UPDATE After discussing with @teosarca we agreed on the following behavior:

• fields with viewEditorRenderMode set to always should be in a constant edit mode, showing input at all times. Fields with value set to onDemand should turn editable after double-click/{enter} key.
• field that is editable is immediately patched after losing focus ~(so when user changes value and switches with arrow key to the next field for instance) or pressing {enter}~
• ~arrows for changing value will be removed from number fields. (Not 100% sure about that)This is due to the fact that we want to be able to switch to the next editable cell with up/down arrows~

UPDATE 2 I played around with different approaches and the one described above does not feel natural. So here's how I think we should approach this:

• We traverse tab cells instead of widgets (like Google Sheets) using Arrows and {tab}
• When cell is focused:
  • Focus any input fields (selects, text, number, textarea)
  • Select attributes button, but don't open it - wait for {space}/{down}
  • Select list, but don't open it - wait for {space}/{down} (so this is seamless with what we normally have for widgets)
  • Arrows don't traverse between cells but navigate text/lists (Excell only uses one type of field so they don't have this problem. We would otherwise loose the ability to change number values or move across text)
  • {tab} still switches to next cell
  • tabbing out submits the input
  • {enter} submits the field and blurs the widget, but cell is still selected
• if cell is selected, but widget blurred (after submit)
  • {enter} focuses the widget
  • {arrows}/{tab} work for navigating between the cells

to give some basic idea:

[siemiatj]

~I think we should identify what we're lacking and create separate tickets for this. Right now it's really vague, and it's really hard to think of the effort it needs. I can already say a lot of code will have to be touched as most of the navigation is still the old lump from almost 2yrs ago.~

[siemiatj]

@teosarca @metas-dh @metas-mk I've added some basic specification/changes that this effort will require.

[siemiatj]

WiP tests: http://recordit.co/qQO149n5IP

[siemiatj]

BASIC FLOW:

#1A User uses arrow/tab keys to traverse the table, and moves to a cell:

• It starts with TableCell component listening to keydown event. If a control key is found, field is focused and we set a flag in the state: https://github.com/metasfresh/metasfresh-webui-frontend/blob/dev-2156/src/components/table/TableCell.js#L271 (in this case there's a second focus event called from TableItem.editProperty)
• row's handler function is then called: https://github.com/metasfresh/metasfresh-webui-frontend/blob/dev-2156/src/components/table/TableItem.js#L266
• we then call functions responsible for storing the active cell DOM element https://github.com/metasfresh/metasfresh-webui-frontend/blob/dev-2156/src/components/table/TableItem.js#L109
• and (if widget is editable) save the property being edited and disable keyboard event listeners for Table and row elements (so that we won't jump out of the widget when using arrow keys) : https://github.com/metasfresh/metasfresh-webui-frontend/blob/dev-2156/src/components/table/TableItem.js#L165

#2A User submits field with {enter}:

• This part is a bit hacky. Again we're listening to keyboard events in TableCell. When control key is recognized, we're doing the same thing as before. But now cell's onFocus handler sets the widget focused flag to false, to prevent infinite loop where user could not leave the field: https://github.com/metasfresh/metasfresh-webui-frontend/blob/dev-2156/src/components/table/TableCell.js#L273
• Next row's keyboard event listener is called and it does only one thing - turns on key event listeners for row and table on: https://github.com/metasfresh/metasfresh-webui-frontend/blob/dev-2156/src/components/table/TableItem.js#L190
• Now we can navigate around the table again

**#3A User presses {enter} on a a submitted focused field

• Because of the widgetFocused: false flag we've set in #2A tableCell propagates the event to TableItem. Row's event handler calls editProperty and then flow is the same as in #1A https://github.com/metasfresh/metasfresh-webui-frontend/blob/dev-2156/src/components/table/TableItem.js#L188

The problem I had with lists and dropdowns is caused by the fact, that SelectionDropdown doesn't get the key event (it is killed by the TableItem). After commenting this https://github.com/metasfresh/metasfresh-webui-frontend/blob/dev-2156/src/components/table/TableItem.js#L196 it works properly. Maybe this can be safely left out ?

SHOWING WIDGETS:

The second thing this effort changes is how we control the visibility of widgets. They can either be

• editable on demand: https://github.com/metasfresh/metasfresh-webui-frontend/blob/dev-2156/src/components/table/TableItem.js#L332
• editable by default: https://github.com/metasfresh/metasfresh-webui-frontend/blob/dev-2156/src/components/table/TableItem.js#L65

There's a bit of a mess over here, as there's some old code that I don't know and without tests was scared to break it.

• this can probably be removed, as the isEditableOnDemand does a similar check https://github.com/metasfresh/metasfresh-webui-frontend/blob/dev-2156/src/components/table/TableItem.js#L80

• I'm almost sure this can be simplified to just 2 checks, instead of 4 https://github.com/metasfresh/metasfresh-webui-frontend/blob/dev-2156/src/components/table/TableItem.js#L332