Rework edit cells
As my understanding of the components improved, I realized that NameTableCell
and ValueTableCell
abstractions were good progress but ultimately not right.
We have two major usecases for these cells
Input edition (default inputs, execution inputs, conditions)
- A cell to edit the name (only type
string
and perhapsnumber
#253 (closed)) with eventual options. UsesNameTableCell
. - A cell to edit the value (this value can be of several types, indicated by the type). No options. Uses
ValueTableCell
Data mapping
- A cell to edit the source (only type
string
and perhapsnumber
#253 (closed)) with eventual options. UsesNameTableCell
. - A cell to edit the target (only type
string
and perhapsnumber
#253 (closed)) with eventual options. UsesValueTableCell
🤔 .
We then notice how 1. of Input edition and 1. 2. of Data mapping are extremely similar but we use different components. One of the reasons we do this is before Data mapping types are flawed: the name
field is used for the source, the value
field is used for the target. This will have to be changed later.
Based on this, I replace NameTableCell
and ValueTableCell
by two new abstractions:
StrEditCell
- Allows to edit string fields (
number
in the future for #253 (closed)) - Allows to specify options to have a dropdown
- Has a
name
prop to fit the usecase (name
for input edition,name
for data mapping source orvalue
for data mapping output) - Does not need to deal with other input types so it relies on a control that can only edit strings (
StrEditControl
)
MultiTypeEditCell
- Allows to edit fields of multiple types (all the ones described by
RowType
!464 (merged) ). - Does not support options to have a dropdown (note that
Autocomplete
was removed from the underlying controlMultiTypeEditControl
) - Has no
name
prop since it only deals withvalue
By having type-specific abstractions, I will be able to rework the TS typings accordingly !462 (comment 308265)
I was also able to remove the allowBoolAndNumberInput
flag as I foresaw in !459 (merged)