Confirmed that the issue can be reproduced in V14.7.3 as well as the latest V22.0.0.alpha9 so that it isn't a regression.

Tried out to reproduce the issue with different editor components. The issue only occured for custom editor components but it didn't for the built-in editor components:

• .custom(new TextField(), SamplePerson::setName) – reproducible
• .custom(new TextArea(), SamplePerson::setName) – reproducible
• .text(SamplePerson::setName) – not reproducible

Here is the video with the TextField used as a custom editor component (V22):

This is a Flow component issue. The observed delay is the server roundtrip between showing the editor when cell editing starts, and updating the editor with the edited value from the server.

This also implies that any ideal solution to this problem will need to avoid a server roundtrip, and run some client-side logic as soon as cell editing starts. Resetting the value of the editor to "empty" is not a trivial problem, because we are dealing with custom elements. Best-case the element has a value property that can be set to null. However there are also components that use other value properties, for example combo box uses selectedItem. Worst case we have a composite component that wraps the actual input into a <div>, or contains multiple inputs. Since the component logic is defined in the Flow component, only the Flow component actually knows how to properly apply a value to the custom elements that it contains.

Given that, I can not see any perfect solution to this problem. I can only list some options that come with different trade-offs:

Improve behavior for simple editors

For cases where the editor itself is an input component, such as <input>, <vaadin-combo-box>, or <vaadin-date-picker>, we can add some code that checks if the component has a value-like property, such as value, selectedItem, or checked, and then reset that to a default empty value. The downside is that this solution will not work for composite components, and there might be confusion about the diverging behaviour of simple and composite editors. There is also a concern that resetting the value could lead to a side-effect that modifies the server-side state, which would be critical to avoid.

Hide editors until the value is loaded

Make the custom editor invisible when starting editing, and only show it after the value has loaded. This basically trades the effect of briefly showing the previous value, to the effect of flashing the whole editor. Another concern here is focus management, the web component keeps track of the cell editing state using focus events. So even if the editor is not visible yet, it must already be focused, and must not loose focus until it becomes visible. There might also be accessibility concerns, as the editor still contains the old value, which screen readers might anounce (same problem with the current behavior).

That would kind of look this this:

Use web components for custom editors

For complex / composite editors the only way to guarantee a contract for setting a value on the client-side is to use a web component that must implement a value property. There would be several ways to go about this implementation-wise (reuse default Grid Pro web component mechanics that gets and sets the value on the client-side, create Flow wrapper and then reset value when starting editing as proposed in the first option). The downside is that this requires to dive into client-side development. We might also want to add new APIs to tell the Flow component to "just use this tag as custom editor".

This could be fixed in the GridPro by not removing the Field immediately but upon grid being refreshed.

We are currently investigating, if the GridPro suits our needs for inline editing of items.
We are currently using the inline editing of the normal Grid but activating the editor needs a server roundtrip and therefor decreases the productivity.
Unfortunately most of our columns need custom components, we can't even use the build in TextField as we need custom client side logic for it.
If we were able to use custom web components as editors in GridPro, that would be a huge benefit and would drastically improve the productivity of our users as they don't need to wait for a server roundtrip before starting to edit the items.

There is also a closely related issue (caused by the same underlying cause), that the regular (non-edit) value in the cell briefly shows the old (pre-edited) value when the editor is closed, before it is updated with the new value.

So, the plan now is to accept that we cannot do anything about the delay itself, and instead

• Hide the editor until its value has been updated
• Hide the cell's readonly value rendering until its value has been updated
• Show some kind of loading indicator in the cell in the meantime

The design of the loading indicator is still up for discussion. Suggestions welcome.

Suggestions welcome

Indeterminate circular progress indicator, or something like https://tailwindcss.com/docs/animation#pulse.

The design of the loading indicator is still up for discussion. Suggestions welcome.

Lumo does have it already

'@vaadin/vaadin-lumo-styles/mixins/loader.js';

It is used e.g. in TabSheet

One idea is to fill the editor with the known client-side value and replace it with the server value as soon as it is known.
If the user changes the value in the mean time (i.e. the filed is foucsed and has an "dirty" value), the server value could be ignored.