Tags: vaadin/flow-components
Tags
feat: add Tabs.getIndexOf and deprecate indexOf (#9719) ## Description Fixes #3822 Added `getIndexOf(Tab)` as the replacement for the deprecated `indexOf(Component)` and `indexOf(Tab)` methods, aligned with `TabSheet.getIndexOf(Tab)`. ## Type of change - Feature Co-authored-by: claude[bot] <41898282+claude[bot]@users.noreply.github.com> Co-authored-by: Serhii Kulykov <10589913+web-padawan@users.noreply.github.com>
fix: style spreadsheet overlays when nested in a shadow root (#9713) Since #9303, spreadsheet overlays (context menu, popup-button filters, cell comments, tooltips) live in a `#spreadsheet-overlays` container in the component's light DOM, styled by a global `<style>` in `document.head`. When `<vaadin-spreadsheet>` is nested in another element's shadow root — for example embedded as a web component, as in the docs filtering example — the container ends up inside that shadow tree, which the document-level stylesheet cannot cross, so the overlays render unstyled. To reproduce: open the [docs "spreadsheet filtering" example](https://vaadin.com/docs/latest/example?embed=spreadsheet-filtering-wc.js&import=component/spreadsheet/spreadsheet-imports.ts) (the spreadsheet is embedded as a web component) and open a column filter — the popup shows with no rounded corners, background, or shadow. On attach, also adopt the overlay stylesheet onto the container's own root (`this._overlays.getRootNode()`) when that root is a `ShadowRoot`, so the scoped `#spreadsheet-overlays …` rules apply inside the shadow tree. Top-level usage is unchanged: the root is the document, already covered by the existing `document.head` stylesheet. Follow-up to #9303 --- 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01QjNdPXWEUciMEXQe9hMgMt --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
fix: render grid data when cache is populated before attach (CP: 25.2) ( #9704) This PR cherry-picks changes from the original PR #9689 to branch 25.2. The connector on this branch doesn't have `resolvePendingCallbacks`, so the fix sets `_hasData` in `$connector.confirm` instead, which is where pending callbacks are resolved here. --- > When the connector receives data while the grid is still detached from the DOM, for example when a grid is rendered inside another grid's component renderer, there is no data provider call, so nothing sets the grid's `_hasData` property. After attaching, the grid then doesn't render the cached rows (the `_flatSizeChanged` observer only updates the virtualizer when `_hasData` is set) and also sends an unnecessary data request to the server. This change makes the connector set `_hasData` when resolving pending callbacks, which covers this case since populating the cache always ends with a `confirm` call. > > Fixes #9674 Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
refactor: move row details renderer state into DetailsManager (#9663) Details rendering registrations and the details data generator lived on `Grid` directly, separate from `DetailsManager`, which already handled the rest of row details (visibility, data generation). This split state across two places for one feature. Move `setItemDetailsRenderer`'s renderer setup/cleanup logic into `DetailsManager.setRenderer`, along with the data generator and registration fields it used. `Grid.setItemDetailsRenderer` now just delegates to `DetailsManager`. 🤖 Generated with Claude Code
refactor: reuse setupColumnEditor in setRenderer (#9659) When a column has an editor, `setRenderer` needs to apply the editor renderer again on top of the new regular renderer. This logic duplicated most of `setupColumnEditor`: rendering the editor renderer and registering its data generator. `setupColumnEditor` now skips creating the `EditorRenderer` when it already exists, so `setRenderer` can call it instead of repeating the same steps. Extracted from #6798 --- 🤖 Generated with Claude Code --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
fix: reuse tooltip instance for composite components (#9639) Tooltip instances should be reused when calling `Tooltip.forComponent` repeatedly for the same component, as introduced in #4736. This did not work for composite components: the tooltip was stored on the original component, but the lookup in `Tooltip#getForElement` resolves the innermost content component instead, so the cached instance was never found and a new one was created on every call. ```java Component composite = new MyComposite(); // extends Composite<Span> Tooltip a = Tooltip.forComponent(composite); Tooltip b = Tooltip.forComponent(composite); // a != b before this fix ``` Store the cached tooltip on the innermost component in `forComponent`, so the write matches the read in `getForElement` (and the existing `forHasTooltip`, which already resolves the innermost component). Fixes #9638 --- 🤖 Generated with Claude Code Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
PreviousNext