Input mini table

[benjaminleonard]

Still very rough, don't look too closely, lest your eyes be burned.

Closes #2627

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Project	Deployment	Preview	Updated (UTC)
console	✅ Ready	Preview	Aug 13, 2025 10:01am

[charliepark]

I know this is still in process, but wanted to note a UX interaction that feels a little odd.

In this screenshot I've added two items, but it's unclear whether the second line has been added to the subform at this point, or whether I need to [add item] to actually … add it(?).

(You know this, but I, a novice user, don't, that the presence of the row means that it has been "added")

If I click that button, though, a new line is added to the list. And if I don't then remove that new line, the validation checks throw an error when I try to submit the form. (A separate issue: what to do with those incomplete subform rows when it's time to submit the overall form?) (Another separate issue: should the user be able to add more rows when there's already an incomplete subform row? Probably not?)

One option would be to disable the "add item" button if one of the other inputs in the subform has focus, but that then creates its own odd interaction mode where I WANT to add a new row and I can't without burring the current field.

Another option to indicate the row's successful "adding" would be to have a green check show up as soon as the row is added, to indicate "success", and then the check fades to the x button after a few seconds, continuing the vocabulary of the "success" checkmark of the ClickToCopy component.

[david-crespo]

Good thought. To me the fact that clicking the button adds an empty row makes reasonably clear that clicking the button adds an empty row, though maybe "add row" is a better label than add item because it makes clearer that it's operating at the level of the form UI rather than the underlying data (though it is also operating on the underlying data). Also maybe it's clear right after you've clicked, but if you scroll somewhere else and come back, you might forget how it worked.

Before you've clicked anything, it is maybe less clear — the copy difference between the button and the empty table is confusing (and also shows why my "add row" idea might be not work). The table says "add a target" but the button says "add item". I think they should say the same thing, so that probably means "Add target", but that makes the original confusion about what the button does even worse. The transition from the empty state to an empty row feels a little weird to me too. All this difficulty shows how right you are to push on this.

For incomplete rows, I figure making the user clean them up is the least bad option — anything more automatic could be error prone and prevent the user from catching their own mistakes.