chore: refresh documentation to cover new widget shipped with v4

Author: r0b1n

content/en/docs/marketplace/platform-supported-content/services/pusher.md

@@ -9,25 +9,25 @@ aliases:
 
 ## Introduction
 
-The [Pusher](https://marketplace.mendix.com/link/component/107957/) service allows you to trigger a microflow or nanoflow directly from the server on non-native client apps. This means it is triggered from the other session, without waiting for end-users to interact with the page.
+The [Pusher](https://marketplace.mendix.com/link/component/107957/) service lets you trigger a client action from the server in non-native client apps. This means an action can be triggered by another user session without waiting for end-user interaction.
 
-In the standard situation, updates in the client are triggered by a user interaction, by timed actions, or by data-grid refresh time. For information not created by the same user session that needs to be updated immediately in the client app, the Mendix core product does not support a viable option to accomplish this. As an alternative, you need to refresh the page constantly with timers or constant clicking. This is not user-friendly, and it is not preferred when scaling.
+In standard scenarios, client updates are triggered by user interaction, timed actions, or data grid refresh intervals. When data is changed outside the current user session and must be updated immediately in the client, the Mendix core product does not provide a direct option. As an alternative, you can refresh the page continuously by using timers or repeated clicks, but this is not user-friendly and does not scale well.
 
-With this service, you can create a notify event on the server that directly causes an action in the client application. The event is based on a persistable object that is available in the server and the client page. From a microflow, the notify action will send a message to every listening widget that is listening to the same object and the action name.
+With this service, you can create a notify event on the server that directly triggers a configured client action in the client app. The event is based on a persistable object that is available on the server and on the client page. When the server-side **Notify** action is executed from a microflow, it sends a message to every listening widget that listens to the same object and action name.
 
 {{% alert color="info" %}}
-The listening widget can only listen when the page is active, so the widget cannot be used to send a notification when the user has navigated away.
+The listening widget only listens while the page is active, so it cannot receive a notification after the user navigates away from the page.
 {{% /alert %}}
 
 ### Typical Use Cases
 
 * Asynchronous refreshes
 * Notifications
-* Chat function
+* Chat functions
 
 ### Dependencies
 
-* External service [Pusher](https://pusher.com/) – the service is built around the Pusher [Channels](https://pusher.com/channels) product; Pusher is a paid service, but there is a generous [free Sandbox plan](https://pusher.com/channels/pricing):
+* External service [Pusher](https://pusher.com/). The service is built around Pusher [Channels](https://pusher.com/channels). Pusher is a paid service and also provides a [free Sandbox plan](https://pusher.com/channels/pricing):
 
     | Detail | Sandbox |
     | --- | --- |
@@ -38,57 +38,85 @@ The listening widget can only listen when the page is active, so the widget cann
     | Support | Limited |
     | Protection | SSL |
 
+### React Client Compatibility
+
+Versions earlier than v4 do not support React client apps. Starting with v4, this module includes a new widget that supports React client apps while the legacy widget remains available. Both widgets can be used side by side while migrating to React client. The runtime parts stay the same for both widgets. The new widget is compatible with Mendix 11.11 and later.
+
 ## Setting Up the Pusher App
 
-To set up the necessary Pusher app, follow these steps:
+To set up the Pusher app, follow these steps:
 
 1. Sign up at [Pusher](https://dashboard.pusher.com/accounts/sign_up).
-2. From the dashboard, create an app
-3. On the **Channels Apps** page, select the new app. The keys are shown in **App Keys**.
+2. In the dashboard, create an app.
+3. On the **Channels Apps** page, select the new app. The keys are listed in **App Keys**.
 4. Copy the key information into the following **Pusher** service constants:
     * `app_id` – `Pusher_App_ID`
     * `key` – `Pusher_Key`
     * `secret` – `Pusher_Secret`
     * `cluster` – `Pusher_Cluster`
 
 {{% alert color="info" %}}
-Make sure you have different apps (keys) created for each app and environment (development, acceptance, and production). When the credentials are shared, messages could go across environments and have unwanted side effects. The configuration can also be set per developer via **App Settings** > **Edit** configuration > [Constants](/refguide/configurations-tab/#constants).
+Use different apps (keys) per Mendix app and environment (development, acceptance, and production). If credentials are shared, messages can cross environments and cause unwanted side effects. You can also set the configuration per developer via **App Settings** > **Edit** configuration > [Constants](/refguide/configurations-tab/#constants).
 {{% /alert %}}
 
 ## Configuration
 
-To use this service after importing it from the Marketplace, follow these steps:
+After you import this module from the Marketplace, configure both parts:
+
+* Server-side configuration for sending notify messages.
+* Client-side configuration for listening to notify messages and executing client actions.
+
+### Server Side Configuration
+
+Follow these steps to configure the server side:
 
 1. Add the **Pusher User** [module role](/refguide/module-security/#module-role) to the relevant app security [user role](/refguide/security/#user-role).
-2. Update the constants in the **Configuration** folder with the keys of the app.
-3. Create a microflow to execute the **Notify** action with the following input parameters:
+2. Update the **Pusher** service constants in the **Configuration** folder with the app keys.
+3. Create a microflow that executes the **Notify** action with these input parameters:
     * Key settings
-    * **Action name** same as configured in the widget
-    * The context object of the widget
-4. Place the widget in a page within a [data view](/refguide/data-view/), where the context should match the parameter object.
-5. In the **Action list**, add an action in which the **Action name** matches the action name parameter provided in the **Notify** action.
-6. Select a microflow or nanoflow the execute the action.
+    * **Action name** that matches the action name configured in the widget
+    * Context object of the widget
+
+### Client Side Configuration
+
+To receive notify messages in the client, place a widget on a page inside a [data view](/refguide/data-view/). The widget listens for notify messages from the server and executes the configured client action when a message is received.
+
+#### React-Compatible Widget
+
+1. Place the new widget on a page within a [data view](/refguide/data-view/) where the context matches the parameter object.
+2. Configure **Action list**. For each entry:
+    * **Action name** matches the notify message name sent from the server.
+    * **Action** defines the client action to run when the message is received. The new widget can run any configured client action. For example, you can run a microflow to retrieve committed data and refresh the page.
+
+#### Legacy Widget
+
+1. Place the legacy widget on a page within a [data view](/refguide/data-view/) where the context matches the parameter object.
+2. Configure **Action list**. For each entry:
+    * **Action name** matches the notify message name sent from the server.
+    * Select whether a nanoflow or microflow is executed when the message is received.
+
+### Fetching Updated Data Example
 
-This diagram describes updating an object via the Notify action:
+You can use a microflow to retrieve data changed by other users, as long as the data is committed and the transaction is complete.
 
-{{< figure src="/attachments/appstore/platform-supported-content/services/pusher/SequenceDiagramUpdateObject.png" alt="update object via notify listen" class="no-border" >}}
+In this example the `$Message` variable contains the object in session state. Use the `[id = $Message]` XPath query to retrieve the object from the database. The change action refreshes the client, which triggers an update on the client page.
 
-### Refresh Microflow
+{{< figure src="/attachments/appstore/platform-supported-content/services/pusher/RefreshMicroflowSample.png" alt="Sample refresh microflow that retrieves updated data for the current page" class="no-border" >}}
 
-You can use a microflow to retrieve data that is changed by other users as long is it committed and the transaction has finished.
+## Working Flow
 
-The `$Message` variable contains the object in the session state. With the `[id = $Message]` XPath query, the object is retrieved from the database. The changes action only does a refresh in the client, which triggers a refresh update on the client page.
+This diagram shows how an object is updated through the **Notify** action:
 
-{{< figure src="/attachments/appstore/platform-supported-content/services/pusher/RefreshMicroflowSample.png" alt="refresh microflow" class="no-border" >}}
+{{< figure src="/attachments/appstore/platform-supported-content/services/pusher/SequenceDiagramUpdateObject.png" alt="Sequence diagram for updating an object through notify and listen" class="no-border" >}}
 
-### Security 
+## Security
 
-The notify messages are sent to anybody who is listening. 
+Notify messages are sent to any listener.
 
-A message will contain limited data (entity name, ID, changed date, notifier user name). To send a notify message, it is required to have the private key that is stored on the server in the `NotifyListen.secret` constant. This secret should not be shared with anybody. The listening widget will use the public `NotifyListen.key` to receive a signal and perform the action as the logged-in user.
+A message contains limited data (entity name, ID, changed date, and notifier username). Sending a notify message requires the private key stored on the server in the `NotifyListen.secret` constant. Do not share this secret. The listening widget uses the public `NotifyListen.key` to receive a signal and perform the action as the logged-in user.
 
-An addition authentication request is made to the Mendix REST server via `<host>/rest/pusher/key` and `<host>/rest/pusher/auth`. Only when successful is the user allowed to access the lists. The service will only allow a logged-in user with the **NotifyListen.User** module role to listen when the user has entity access to the object of the data in which the widget is placed.
+An additional authentication request is made to the Mendix REST server through `<host>/rest/pusher/key` and `<host>/rest/pusher/auth`. Only after successful authentication can a user access the lists. The service only allows a logged-in user with the **NotifyListen.User** module role to listen when the user has entity access to the object used by the widget's data context.
 
 ## Strict CSP Compatibility
 
-This service requires additional configuration to be compliant with strict content security policy (CSP). The Pusher service makes use of an external service for its functionalities. To make this service work, you need to configure the CSP headers to allow resources from that domain.
+This service requires extra configuration to comply with a strict content security policy (CSP). The Pusher service uses an external service for its functionality. To make this service work, configure CSP headers to allow resources from that domain.