Merge branch 'latest' into docs/copilot-feature-flag

articles/components/grid/columns.adoc

@@ -147,37 +147,25 @@ endif::[]
 
 == Column Visibility
 
-When you want, columns and column groups can be hidden. You can provide the user with a menu for toggling column visibilities, for example, using Menu Bar. Allowing the user to hide columns is useful when only a subset of the columns is relevant to their task, and if there are plenty of columns.
-
-In the example here, notice that the email addresses and telephone numbers are not fully visible because the data doesn't wrap and won't fit in the width provided. Now click on the _Show/Hide Columns_ button to see a menu of choices to reduce the number of columns. Notice that all columns are checked. De-select the _First Name_ and then the _Profession_ column. That should allow the email addresses and telephone numbers to be fully visible. Incidentally, if you don't deselect any columns, you can still right-click on an email address to copy it: You'll still get the whole address, even if it's not visible.
+When you want, columns and column groups can be hidden. You can provide the user with a menu for toggling column visibilities, for example, using Popover. Allowing the user to hide columns is useful when only a subset of the columns is relevant to their task, and if there are plenty of columns.
 
 [.example]
 --
 
-ifdef::lit[]
-[source,typescript]
+[source,html]
 ----
-include::{root}/frontend/demo/component/grid/grid-column-visibility.ts[render,tags=snippet,indent=0,group=Lit]
+include::{root}/frontend/demo/component/popover/popover-anchored-dialog.ts[render,tags=gridsnippet,indent=0,group=Lit]
 ----
-endif::[]
 
-ifdef::flow[]
 [source,java]
 ----
-include::{root}/src/main/java/com/vaadin/demo/component/grid/GridColumnVisibility.java[render,tags=snippet1,indent=0,group=Flow]
-
-...
-
-include::{root}/src/main/java/com/vaadin/demo/component/grid/GridColumnVisibility.java[render,tags=snippet2,indent=0,group=Flow]
+include::{root}/src/main/java/com/vaadin/demo/component/popover/PopoverAnchoredDialog.java[render,tags=gridsnippet,indent=0,group=Flow]
 ----
-endif::[]
 
-ifdef::react[]
 [source,tsx]
 ----
-include::{root}/frontend/demo/component/grid/react/grid-column-visibility.tsx[render,tags=snippet,indent=0,group=React]
+include::{root}/frontend/demo/component/popover/react/popover-anchored-dialog.tsx[render,tags=gridsnippet,indent=0,group=React]
 ----
-endif::[]
 --
 
 

articles/components/grid/selection.adoc

@@ -68,11 +68,40 @@ include::{root}/frontend/demo/component/grid/react/grid-multi-select-mode.tsx[re
 endif::[]
 --
 
-In addition to selecting rows individually, a range of rows can be selected by dragging from one selection checkbox to another, if enabled:
+=== Range Selection
+
+In addition to selecting rows individually, you may want to allow users to select or deselect a range of rows using kbd:[Shift] + Click. Since there are a variety ways for range selection, Grid provides the necessary event, `item-toggle` to create your own implementation. This event provides information about the toggled row, its selection state, and whether the user was holding kbd:[Shift] during the toggle.
+
+The example below demonstrates a possible implementation of range selection using `item-toggle`. In this implementation, the first clicked row is stored as an anchor point. When the user holds kbd:[Shift] and clicks another row, the selection state of all rows between the anchor and the newly clicked row is updated to match the clicked row's state. The second clicked row then becomes the new anchor point for future selections.
 
 [.example]
 --
+ifdef::lit[]
+[source,typescript]
+----
+include::{root}/frontend/demo/component/grid/grid-range-selection.ts[render,tags=snippet,indent=0,group=Lit]
+----
+endif::[]
+
+ifdef::flow[]
+[source,java]
+----
+include::{root}/src/main/java/com/vaadin/demo/component/grid/GridRangeSelection.java[render,tags=snippet,indent=0,group=Flow]
+----
+endif::[]
 
+ifdef::react[]
+[source,tsx]
+----
+include::{root}/frontend/demo/component/grid/react/grid-range-selection.tsx[render,tags=snippet,indent=0,group=React]
+----
+endif::[]
+--
+
+A range of rows can also be selected by dragging from one selection checkbox to another, if that's enabled:
+
+[.example]
+--
 [source,typescript]
 ----
 <source-info group="Lit"></source-info>
@@ -97,9 +126,9 @@ selectionModel.setDragSelect(true);
   ...
 </Grid>
 ----
-
 --
 
+
 == Selection Modes in Flow
 
 Each selection mode is represented by a [classname]`GridSelectionModel`, accessible through the [methodname]`getSelectionModel()` method, which can be cast that to the specific selection model type, [classname]`SingleSelectionModel` or [classname]`MultiSelectionModel`. These interfaces provide selection mode specific APIs for configuration and selection events.

articles/components/multi-select-combo-box/index.adoc

@@ -64,7 +64,7 @@ The overlay opens when the user clicks the field using a pointing device. Using
 Multi-Select Combo Box supports the following features from the regular Combo Box. All the linked examples and code snippets can be applied by replacing the Combo Box with a Multi-Select Combo Box.
 
 - <<../combo-box#custom-value-entry, Custom Value Entry>>
-- <<../combo-box#custom-item-representation, Custom Item Presentation>>
+- <<../combo-box#custom-item-presentation, Custom Item Presentation>>
 - <<../combo-box#auto-open, Auto Open>>
 - <<../combo-box#placeholder, Placeholder>>
 - <<../combo-box#custom-filtering, Custom Filtering>>

articles/flow/advanced/server-client-communication.adoc

@@ -30,3 +30,43 @@ The `clientId` holds the latest communication state identifier given by the clie
 On the client, pending messages are removed from the queue as handled when `clientId` from server matches the next expected value. If the id is less than expected, the client waits since the server has not yet seen all messages. The response should arrive later. Otherwise, the client trusts the server and updates the id to the server's expectations.
 
 On the server, in cases where the id is the previous one with the same request payload, the server re-sends the latest response since the client probably didn't receive the message. If the client-sent id doesn't match the server-expected id, a re-synchronization is initiated.
+
+
+= UI State Re-Synchronization
+
+Re-synchronization occurs when the client detects that its state is no longer in sync with the server. This can happen due to unexpected network interruptions, or inconsistencies between the client-side UI and server-side state caused by misconfigured reverse proxies or session replication setups.
+
+Several factors can lead to message loss or unexpected message identifiers:
+
+- *Incorrect load balancer or reverse proxy configuration:* Using setups without sticky sessions may result in receiving messages from the server which were meant for a different session or UI.
+- *Firewall or Virtual Private Network (VPN) interference:* Deep packet inspection can block certain packets.
+
+These factors might also generate a delay in arrival of the messages. Virus scanners are particularly problematic and may cause issues when `WebSocket_XHR` is used. Increasing the `maxMessageSuspendTimeout` parameter value could help mitigate message arrival delays.
+
+Other potential causes include:
+
+- *Faulty router hardware:* This could be due to routers using outdated firmware versions.
+- *Unstable Wi-Fi or cellular connections*: Fluctuating network conditions can disrupt communication.
+- *Server-side issues:* Request-handling hiccups may lead to inconsistencies, possibly due to server performance degradation.
+
+
+== Re-Synchronization Initiation & Mechanism
+
+Re-synchronization is initiated by the client when it can't find a message with the expected `syncId` among the pending messages from the server within a given timeout. The default is 5 seconds, which is configurable using the `maxMessageSuspendTimeout` parameter. Below is the process followed to re-synchronize:
+
+*Client Initiation:*
+
+- The client clears the queue of pending messages from the server.
+- It terminates the current request and sends a re-synchronization request to the server.
+
+*Server Handling:*
+
+- Upon receiving the re-synchronization request, the server invokes the detached listeners of UI components and re-attaches all components to the state tree.
+- The server then sends a response that includes the current UI state needed to rebuild the client-side state tree.
+
+*Client Update:*
+
+- The client receives the updated UI state from the server.
+- It clears all old pending messages, updates the last known `syncId` to the newly received value, and rebuilds the DOM tree from scratch based on the server's current state.
+
+This process ensures UI consistency, even in the presence of errors or unexpected behavior. The application remains robust against transient network problems or client-side interruptions. Additionally, the user experience is preserved without requiring a full page reload, as Vaadin rebuilds the UI without reloading the entire bundle from the server.