Feature request: Header row for adding new items

[rolfsmeds]

The Grid supports inline editing of rows, but there is no easy way to inline-ADD new items.

You can add a new entity to the dataprovider, but in many cases that's not feasible since you don't want to pre-populate the properties of the new entity, and in most cases entities have properties that cannot be null so you can't leave them empty.

Also adding a new row to the bottom of the Grid can be problematic for obvious reasons.

I propose adding a feature where a new entity can be entered using a header row. The contents of that row would be the same as for the row editor. This "add row" would replace the filter row when the Grid is in "add mode". The added benefit of an "add row" is that it would always be at the top of the grid and there would be no issues with scrolling etc.

[rolfsmeds]

related: vaadin/web-components#1180

[jouni]

Currently, is it possible to build a workaround yourself by first adding an "empty" item to the data set, and then enabling the edit mode for that row/item?

[sirbris]

Currently, is it possible to build a workaround yourself by first adding an "empty" item to the data set, and then enabling the edit mode for that row/item?

Sadly the edit mode can‘t be triggered via code, so the user has to find the new item and then double click on the cell to start editing

[jouni]

If edit mode would be possible to trigger via code, would that be enough, or would we still want to provide a “new item row” which is always visible?

[rolfsmeds]

It would still bit rather awkward for a couple of reasons:

1. That new row needs to be somewhere. I guess first or last row would make sense. But what if you're already scrolled somewhere? Does is scroll you up/down first? What about when you commit the item, does it stay put, potentially violating the current sorting, or immediately teleport to its correct position?
2. In my experience at least, it's quite rare for data entities to be initializable as empty, but that's pretty much what this would require. You could get around that by using some kind of intermediate class that's not persisted but only used to bind to the grid, but that's really awkward too and comes with its own issues.

[jouni]

1. Yeah, sorting and filtering of the existing data, combined with scrolling, definitely make it difficult to create a robust user experience. But having a fixed row at the top doesn't make it immediately trivial either.

2. The empty item is definitely a nasty workaround, not something you would really want. Perhaps we could solve this on the framework level.

For the first, UX related issues, how should we handle the case when the user has filtered and sorted the data set, and they add a new item?

I believe some kind of feedback would be required once the item has been added, as it might be that the item doesn't appear anywhere in the current Grid viewport. If the new item is not filtered out, should the viewport scroll to reveal it? Should this be configurable behavior? Would it be terrible to disable adding new rows when the data is filtered?

That said, having a permanent row for adding new items is not really that different from a button that opens a dialog to add a new item, and we haven't done anything special in our CRUD component for this use case. So perhaps we don’t need to pay more attention to the UX here either.

[rolfsmeds]

The CRUD dialog/split editor is a good comparison indeed, and exemplifies also the point of this feature proposal: that editing and creating should have the same user flow.

It's true that a dedicated fixed row at the top/bottom doesn't entirely solve the issues in (1), but it does solve some of them:

• Fixed row at top/bottom removes it conceptually (and visually?) from the sorting, filtering, etc
• Avoids scrolling it out of the viewport

The question of what happens to it when it's commited are not solved, but I'm not sure what we could do about that, other than perhaps scrolling to it automatically (which has it's own challenges in that we don't necessarily know where it is). Notifications can be shown of course, but I feel that's best left to the application logic.

Issue nr.2 above is a chicken-and-egg problem somewhat unique to the Grid – the item cannot be represented in the Grid until it is in the dataset, and it cannot be in the dataset until it's created, so it needs to be created before the user can create it, which doesn't make sense. The CRUD avoids this by not having the creation in the Grid itself.