Best practice for building an editable table row

[lixiaoyan]

I saw an editable cell demo in the React Spectrum documentation. However, in our use case, we need the entire row to enter edit mode together. Is there a good way to achieve this? If we use the dialog approach, the column widths would need to be handled separately; if we edit directly within the Table, it's difficult to integrate form and validation.

[snowystinger]

You're welcome to look at the source for EditableCell,

react-spectrum/packages/@react-spectrum/s2/src/TableView.tsx

Line 1145 in 676de79

export const EditableCell = forwardRef(function EditableCell(props: EditableCellProps, ref: ForwardedRef<HTMLDivElement>) {

It's probably the best way to do it right now since we aren't there yet on supporting textfields inside of Tables. Each cell in your row could open the same Popover. If you want the fields to match widths of their cells or some close approximation you can either measure it like we did in that implementation. Or you could possibly put the Table into a controlled resizable state, and use the column widths to set it https://react-aria.adobe.com/Table#resize-events, up to you if you actually support the resizing.

The editable cell you're looking at also supports form validation.

Hopefully this will be easier down the line, maybe even with the EditableCell as a part of RAC, but we've not had a chance to think about that yet.

[lixiaoyan]

@snowystinger

I've considered a similar approach. I was planning to get the column widths and labels from the collection, then render another table inside the dialog. But it seems difficult to access the collection at the row level. Is there a good solution for this?

[snowystinger]

Maybe I'm misunderstanding something here. Why do you need to access it from the row? I'd just do it either at the cell level or at the table level
Maybe a codesandbox/stackblitz could help illustrate what you're trying to do

[lixiaoyan]

Never mind, please ignore my previous comment as I had misunderstood some of the details.

I noticed you mentioned that input elements within Tables are currently not supported. We have a similar UI pattern, and I hadn't realized that arrow key navigation doesn't work as expected inside these inputs. Furthermore, our specific use case doesn't allow for a distinct "toggle edit mode" interaction like the example shows.

To be more specific, we have an m*n grid of inputs with row and column headers. These cells are editable by default, and users expect to fill them out one-by-one using Tab or other shortcut keys. Given this requirement, would you still recommend building this with RAC's Table, or would I be better off implementing a custom component that doesn't rely on the Grid interaction model?

[mryechkin]

Given this requirement, would you still recommend building this with RAC's Table, or would I be better off implementing a custom component that doesn't rely on the Grid interaction model?

For what it's worth, we've run into the same issue with our "column filters" design, which are just text inputs within the header for filtering within each column, and had to abandon that design exactly for this reason. The Grid pattern is fundamentally at odds with text inputs (or any other field that assumes left / right keyboard arrow interaction) - I believe the only way around it is by having a distinct edit mode, which would then take precedence over the underlying Grid interactions.

[snowystinger]

@mryechkin has the right of it at the moment. It's one of our top backlog items, but is very involved and we haven't had a chance to address it yet.

Some explorations:
#8775
#8691
#8628