IMO this is a great question for AI.
I asked Claude and that’s what it says:
Let me give you my take on the inline-edit pattern in Vaadin Flow.
The two-tab approach is pragmatic but has UX friction. Every tab switch is a context switch. The user sees the summary, clicks something, gets teleported to a form, and has to mentally re-orient. For a “review and lightly edit” flow, that is one step too many.
True inline edit in Vaadin Flow is absolutely doable and not as painful as you might think. Here is the core pattern:
public class InlineEditField extends Div {
private final Span readView;
private final TextField editView;
private boolean editing = false;
public InlineEditField(String label, String value,
Consumer<String> onSave) {
readView = new Span(value);
readView.addClassName("inline-edit-read");
readView.getElement().setAttribute("tabindex", "0");
editView = new TextField(label);
editView.setValue(value);
editView.setVisible(false);
editView.setWidthFull();
// Click to edit
readView.addClickListener(e -> startEditing());
// Enter on read view also starts editing
readView.getElement().addEventListener("keydown", e -> startEditing())
.setFilter("event.key === 'Enter'");
// Save on blur
editView.addBlurListener(e -> save(onSave));
// Enter saves, Escape cancels
editView.getElement().addEventListener("keydown", e -> save(onSave))
.setFilter("event.key === 'Enter'");
editView.getElement().addEventListener("keydown", e -> cancelEditing())
.setFilter("event.key === 'Escape'");
add(readView, editView);
}
private void startEditing() {
if (editing) return;
editing = true;
readView.setVisible(false);
editView.setVisible(true);
editView.focus();
}
private void save(Consumer<String> onSave) {
editing = false;
String newValue = editView.getValue();
readView.setText(newValue);
editView.setVisible(false);
readView.setVisible(true);
onSave.accept(newValue);
}
private void cancelEditing() {
editing = false;
editView.setValue(readView.getText());
editView.setVisible(false);
readView.setVisible(true);
}
}
The CSS is minimal:
.inline-edit-read {
cursor: pointer;
border-bottom: 1px dashed transparent;
padding: 2px 4px;
border-radius: 3px;
transition: background-color 0.15s;
}
.inline-edit-read:hover,
.inline-edit-read:focus {
background-color: var(--lumo-contrast-5pct);
border-bottom-color: var(--lumo-contrast-30pct);
}
Key things to watch out for:
The focus() call after toggling visibility works fine because Vaadin batches the DOM updates in a single round-trip. The setVisible(false) on the read view and setVisible(true) plus focus() on the edit view all arrive at the client in one response. No timing hacks needed.
For save-on-blur vs. explicit save: blur works well for simple text fields. But be careful with fields that open overlays (date pickers, combo boxes), because the overlay itself triggers a blur on the field. The InlineDatePicker you mentioned does not really exist as a built-in toggle component. You would need to build the same read/edit swap around a DatePicker.
For keyboard navigation: the tabindex="0" on the read view is important. It puts the spans into the tab order so keyboard users can navigate between fields and press Enter to edit. Without it, the whole thing is mouse-only.
For the document-like layout, you can compose these inline edit fields into a narrative structure:
var summary = new Div();
summary.addClassName("document-view");
summary.add(
new H2(new InlineEditField("Event", event.getName(), event::setName)),
new Paragraph(
new Text("Taking place at "),
new InlineEditField("Venue", event.getVenue(), event::setVenue),
new Text(" on "),
new InlineEditField("Date", event.getDate().toString(),
val -> event.setDate(LocalDate.parse(val))),
new Text(".")
)
);
This gives you the Notion-like feel you are looking for, without the tab switching.
One more thing: if you want a “save all” button instead of save-on-blur for each field, collect all the dirty fields and batch the persistence. A Binder does not fit this pattern well because it expects a form layout. A simple list of Runnable save actions works better here.
The two-tab approach is not wrong. It is a safe, maintainable choice. But if the UX goal is “feels like reviewing a document”, the inline edit pattern gets you much closer with surprisingly little code.
