Vaadin Flow Components V25.1.11

Vaadin Flow Components 25.1.11

This is a release of the Java integration for Vaadin Components to be used from the Java server side with Vaadin Flow.

Changes in Flow Components from 25.1.10

Changes in All Components

• Chore:
  • ⧉ Increase Web-Component version

Changes in vaadin-grid-flow

• Fixes:
  • ⧉ Include descendant items in TreeGrid selectAll (#9819). PR:9831

Changes in vaadin-spreadsheet-flow

• Fixes:

  • ⧉ Reuse custom editors on user-driven cell updates (#9814) (CP: 25.1). PR:9833

    This PR cherry-picks changes from the original PR #9814 to branch 25.1. --- #### Original PR description > Custom editors from a SpreadsheetComponentFactory were replaced with new instances on every user interaction that commits a cell value, so whatever the user had entered was lost. #9493 fixed the cases that re-render the same cells (scrolling, selection, resize), but the paths through updateMarkedCells() still recreated them. #9493 even describes refreshCells() as reusing editors, while in code it recreated them, and that is the case the reproducer in #9180 hits. > > ## Reproduction > > java > ComboBox<String> comboBox = new ComboBox<>(); > comboBox.setItems("Apple", "Banana", "Cherry"); > comboBox.addValueChangeListener(event -> { > spreadsheet.createCell(rowIndex, columnIndex, event.getValue()); > spreadsheet.refreshCells(spreadsheet.getCell(rowIndex, columnIndex)); > }); > > > Pick a value in the editor cell: it is replaced by whatever onCustomEditorDisplayed sets. The same happens on Delete, paste, fill-drag, merging cells and collapsing a group. > > A second case: double-click a plain cell to open the built-in editor, then click a cell that has a custom editor. That editor disappears until the cell is selected again. > > ## Changes > > Reuse is now the default in updateMarkedCells(). Only shiftRows() and deleteRows() opt out, through updateMarkedCellsRecreatingEditors(), because they move cells and editors are cached per cell. > > Reused editors keep their client node ids, so cellKeysToEditorIdMap stops changing, and the client re-attaches editors only when it does. That revealed an older bug behind the second case: the deferred commit of an inline edit takes its target from the selection, which may have moved onto an editor cell by then, and writing a value into a cell removes the editor in it. SheetWidget.updateSelectedCellValue now skips that write, using the check cellValuesUpdated already applies. The late target resolution itself is left alone, and the cell value is not affected, because doCommitIfEditing commits it before the deferred call runs. > > Since the factory is now asked for an editor only once per cell, an editor picked from the cell's value is no longer replaced when that value changes. getCustomEditorForCell says so now, and names reloadVisibleCellContents() as the way to force a re-ask. Factories that decide by position, which is the common case, are unaffected. > > reloadVisibleCellContents(), shiftRows() and deleteRows() still leave a recreated editor empty with no callback to fill it. That is long-standing behaviour, reported as #9812. > > CustomEditorSelectionIT covers the text selection asked for in #9036, which no test asserted before. > > Part of #9180, Follow-up to #9493, Related to #9036, Related to #9812 > > --- > > 🤖 Generated with Claude Code >

Compatibility

• This release use Web Components listed in Vaadin Platform 25.1.11
• Tested with Vaadin Flow version 25.1.14