Merge pull request #1964 from prpr19xx/prpr19xx-patch-5

Steve-Mcl · web-flow · commit 0769710614e0 · 2025-12-13T16:16:04.000Z
docs: Grammar and typo fixes
diff --git a/README.md b/README.md
@@ -31,7 +31,7 @@ FlowFuse also comes with a collection of [FlowFuse Dashboard Blueprints](https:/
 
 ## Features
 
-FlowFuse Dashboard provides a base set of nodes for building your own user interfaces and data visualisations. Much like it's predecessor, it provides a set of easy-to-use, core nodes, but provides complete flexibility for customisation and control over theming, layout and behaviour if you want to go further.
+FlowFuse Dashboard provides a base set of nodes for building your own user interfaces and data visualisations. Much like its predecessor, it provides a set of easy-to-use, core nodes, but provides complete flexibility for customisation and control over theming, layout and behaviour if you want to go further.
 
 ### Easy Integration
 
diff --git a/cypress/fixtures/user-dir/settings.js b/cypress/fixtures/user-dir/settings.js
@@ -491,7 +491,7 @@ module.exports = {
      */
     // nodeMessageBufferMaxLength: 0,
 
-    /** If you installed the optional node-red-dashboard you can set it's path
+    /** If you installed the optional node-red-dashboard you can set its path
      * relative to httpNodeRoot
      * Other optional properties include
      *  readOnly:{boolean},
diff --git a/docs/en/contributing/guides/events.md b/docs/en/contributing/guides/events.md
@@ -38,7 +38,7 @@ Our default server-side `onInput` handler handles the common use cases of:
 
 - Updating the widget's value into our server-side data store
 - Checking if the widget is configured to define a `msg.topic` and if so, updating the widget's `msg.topic` property
-- Check if the widget is configured with a `passthrough` option, and if so, check it's value before emitting the `msg` object to any connected nodes.
+- Check if the widget is configured with a `passthrough` option, and if so, check its value before emitting the `msg` object to any connected nodes.
 - Emit the `msg` object to any connected nodes, if appropriate.
 
 ### "Dashboard Actions" Event Flow
diff --git a/docs/en/contributing/guides/registration.md b/docs/en/contributing/guides/registration.md
@@ -8,7 +8,7 @@ Every `ui-base`, `ui-page` and `ui-group` has a `.register` function. The core r
 
 This function is used by all of the widgets to inform Dashboard of their existence, and allows the widget to define which group/page/ui it belongs too, along with the relevant properties that widget has and any event handlers (e.g. `onInput` or `onAction`).
 
-The function is called within the node's Node-RED `.js` file, and in th case of a widget registering as part of a group (the most common use case), would look something like this:
+The function is called within the node's Node-RED `.js` file, and in the case of a widget registering as part of a group (the most common use case), would look something like this:
 
 ```js
 module.exports = function (RED) {
@@ -48,13 +48,13 @@ This is the `this` of your node's constructor, and can be used directly from the
 
 ### `config`
 
-This is made available by Node-RED as the input to the constructor, and can generally passed straight into the `.register` function without modification, it will be an object that maps all of the properties and values that have been described in the node's `.html` definition.
+This is made available by Node-RED as the input to the constructor, and can generally passed straight into the `.register` function without modification. It will be an object that maps all of the properties and values that have been described in the node's `.html` definition.
 
 ### `evts`
 
 We expose a range of different event handlers as part of the `register` function. All of these handlers run server (Node-RED) side.
 
-In some cases, it is possible to define full functions (that will run at the appropriate point in the event lifecycle), in other occasions, it's only possible to define a `true`/`false` value that informs Dashboard that you wish for the widget to send or subscribe to that event.
+In some cases, it is possible to define full functions (that will run at the appropriate point in the event lifecycle); in other cases, it is only possible to define a `true`/`false` value that informs Dashboard that you wish for the widget to send or subscribe to that event.
 
 A full breakdown of the event lifecycle can be found [here](../../contributing/guides/events.md).
 
@@ -88,7 +88,7 @@ An example of this is with `ui-button`, where the widget's `UIButton` contains a
 this.$socket.emit('widget-action', this.id, msg)
 ```
 
-This sends a message via SocketIO to Node-RED, with the topic of the widget's ID. Because the `ui-button` has `onAction: true` in it's registration, it will consequently run the default handler detailed above.
+This sends a message via SocketIO to Node-RED, with the topic of the widget's ID. Because the `ui-button` has `onAction: true` in its registration, it will consequently run the default handler detailed above.
 
 ### `.onChange` (`boolean` || `function`)
 
@@ -100,12 +100,12 @@ Similar to `onAction`, when used as a boolean, this flag will trigger the defaul
 2. Appends any `msg.topic` defined on the node config
 3. Runs `evts.beforeSend()` _(if provided)_
 4. Store the most recent message on the widget under the `._msg` property which will contain the latest state/value of the widget
-5. Pushes a `widget-sync` event to synchronize the widgets in all clients.
+5. Pushes a `widget-sync` event to synchronize the widgets in all clients
 6. Sends the `msg` onwards to any connected nodes
 
 #### Custom `onChange` Handler
 
-Alternatively, you can override this default behaviour by providing a custom `onChange` function. An example of this is in the `ui-switch` node which needs to do `node.status` updates to in order for the Node-RED Editor to reflect it's latest status:
+Alternatively, you can override this default behaviour by providing a custom `onChange` function. An example of this is in the `ui-switch` node which needs to do `node.status` updates to in order for the Node-RED Editor to reflect its latest status:
 
 ```js
 /**
@@ -165,7 +165,7 @@ When provided, this will override the default handler.
 
 We use this in the core widgets in Dashboard with `ui-chart`, where we want to be storing the history of recent `msg` value, rather than _just_ the most recent value as done in the default handler. We also use it here to ensure we don't have too many data points (as defined in the `ui-chart` config).
 
-Another use case here would be if you do not want to pass on any incoming `msg` payloads onto connected nodes automatically, for example, you could have a bunch of command-type `msg` payloads that instruct your node to do something, that are then not relevant to any preceding nodes in the flow.
+Another use case here would be if you do not want to pass on any incoming `msg` payloads onto connected nodes automatically. For example, you could have a bunch of command-type `msg` payloads that instruct your node to do something, that are then not relevant to any preceding nodes in the flow.
 
 ### `.onError(err)` (`function`)
 
diff --git a/docs/en/contributing/widgets/third-party.md b/docs/en/contributing/widgets/third-party.md
@@ -42,7 +42,7 @@ FlowFuse Dashboard is built on top of [VueJS](https://vuejs.org/), and as such,
 
 We have created an [Example Node repository](https://github.com/FlowFuse/node-red-dashboard-example-node) that will provide foundations for your widget. It includes plenty of examples for functionality you'll likely need.
 
-It's base repository has the following file/folder structure:
+Its base repository has the following file/folder structure:
 
 As with any Node-RED nodes, you'll need to start with two files:
 
@@ -79,7 +79,7 @@ To start working with your own third-party widget, locally on your machine:
    ```bash
    export NODE_ENV=development
    ```
-4. Inside the Example Node directory, build the Example Node's `.umd.js` file (what Node-RED uses to run your widget), this will generate it's `/resources` folder, loaded by Node-RED.
+4. Inside the Example Node directory, build the Example Node's `.umd.js` file (what Node-RED uses to run your widget), this will generate its `/resources` folder, loaded by Node-RED.
    ```bash
    npm run build
    ```
@@ -356,7 +356,7 @@ You can read more about the Node-RED data store in our [State Management](../gui
 
 State refers to any properties of your widget that have changed in runtime, and would differ from that set in the Node-RED editor.
 
-For example, the `ui-dropdown` can have it's `options` overriden with a `msg.options` message sent to the node. This updates `options` would be stored against the node in the state store.
+For example, the `ui-dropdown` can have its `options` overriden with a `msg.options` message sent to the node. This updates `options` would be stored against the node in the state store.
 
 #### Client-Side Data Store
 
diff --git a/docs/en/layouts/types/notebook.md b/docs/en/layouts/types/notebook.md
@@ -25,7 +25,7 @@ A group has a default width of "6" columns, with the full Notebook also a width
 ![Notebook Layout](../../../assets/images/layout-eg-notebook-width6.png){data-zoomable}
 *An example UI rendered using the "Notebook" Layout*
 
-We can get finer grain width control within a group by increasing it's width. The Notebook itself will not render the group any wider, but the group itself will render with 12 columns internally. So, if we increase the "width" (number of columns) of the group to 12, then the two charts are then setup to only take up half of the width of the group (3 columns each).
+We can get finer grain width control within a group by increasing its width. The Notebook itself will not render the group any wider, but the group itself will render with 12 columns internally. So, if we increase the "width" (number of columns) of the group to 12, then the two charts are then setup to only take up half of the width of the group (3 columns each).
 
 ![Notebook Layout](../../../assets/images/layout-eg-notebook-width12.png){data-zoomable}
 *An example UI rendered using the "Notebook" Layout*
diff --git a/docs/en/nodes/config/ui-group.md b/docs/en/nodes/config/ui-group.md
@@ -4,9 +4,9 @@ props:
     Name: Descriptive name for this group, will show in the Node-RED Editor and as a label in the Dashboard.
     Page: The Page (<code>ui-page</code>) that this group will render on.
     Type: Controls whether the group appears as a default group or as a dialog, which needs to be triggered manually using ui-control. You can choose between 'Default' and 'Dialog' types.
-    Size: The width and height of the group. Height will always be reinforced by this value, the height is generally a <i>minimum</i> height, and will extend to fit it's content.
+    Size: The width and height of the group. Height will always be reinforced by this value, the height is generally a <i>minimum</i> height, and will extend to fit its content.
     Class: Any custom CSS classes you wish to add to the Group.
-    Default State: <ul><li><b>Visibility</b> - Defines the default visibility of this group.</li><li><b>Interactivity</b> - Controls whether the group and it's contents are disabled/enabled when the page is loaded.</li></ul><p>Both of these can be overridden by the user at runtime using a <code>ui-control</code> node.</p>
+    Default State: <ul><li><b>Visibility</b> - Defines the default visibility of this group.</li><li><b>Interactivity</b> - Controls whether the group and its contents are disabled/enabled when the page is loaded.</li></ul><p>Both of these can be overridden by the user at runtime using a <code>ui-control</code> node.</p>
 ---
 
 <script setup>
diff --git a/docs/en/nodes/widgets/ui-button.md b/docs/en/nodes/widgets/ui-button.md
@@ -102,7 +102,7 @@ Adds a clickable button to your dashboard.
 
 ### Measuring Hold Duration
 
-It's possible to cofnigure a button to emit `pointerdown` and `pointerup` events. With this, it's possible to measure how long a button is held down for.
+It's possible to configure a button to emit `pointerdown` and `pointerup` events. With this, it's possible to measure how long a button is held down for.
 
 <video controls height="200px">
     <source src="/videos/demo-button-hold.mp4" type="video/mp4">
diff --git a/docs/en/nodes/widgets/ui-dropdown.md b/docs/en/nodes/widgets/ui-dropdown.md
@@ -50,7 +50,7 @@ dynamic:
 
 </TryDemo>
 
-Adds a dropdown to your dashboard that will emit values in Node-RED under `msg.payload` anytime it's value is changed.
+Adds a dropdown to your dashboard that will emit values in Node-RED under `msg.payload` anytime its value is changed.
 
 ## Programmatic Selections
 
diff --git a/docs/en/nodes/widgets/ui-gauge.md b/docs/en/nodes/widgets/ui-gauge.md
@@ -129,7 +129,7 @@ For example, if you want to round the value to 1 decimal place, you can set the
 $round(payload, 1) // round to 1 decimal place
 ```
 
-You can read more about the JSONata expression language and in particular, it's numeric functions, [here](https://docs.jsonata.org/numeric-functions).
+You can read more about the JSONata expression language and in particular, its numeric functions, [here](https://docs.jsonata.org/numeric-functions).
 
 ## Examples
 
diff --git a/docs/en/nodes/widgets/ui-slider.md b/docs/en/nodes/widgets/ui-slider.md
@@ -78,7 +78,7 @@ dynamic:
 
 </TryDemo>
 
-Adds a slider to your dashboard that will emit values in Node-RED under `msg.payload` anytime it's value is changed.
+Adds a slider to your dashboard that will emit values in Node-RED under `msg.payload` anytime its value is changed.
 
 ## Properties
 
diff --git a/docs/en/nodes/widgets/ui-text.md b/docs/en/nodes/widgets/ui-text.md
@@ -61,7 +61,7 @@ Displays a non-editable text field on the user interface. Each received `msg.pay
 
 ## Adding Prefixes & Suffixes
 
-In Node-RED Dashboard an option existed called `valueFormat` which allowed you to add a prefix or suffix to a `ui-text` widget within the node's configuration. Whilst valuable, this had a lot of security vulnerabilities, so with FlowFuse Dashboard we made the decision to remove it..
+In Node-RED Dashboard an option existed called `valueFormat` which allowed you to add a prefix or suffix to a `ui-text` widget within the node's configuration. Whilst valuable, this had a lot of security vulnerabilities, so with FlowFuse Dashboard we made the decision to remove it.
 
 Instead, we take a different approach, and use Node-RED's built-in "template" node:
 
@@ -118,7 +118,7 @@ For example, if you want to round the value to 1 decimal place, you can set the
 $round(payload, 1) // round to 1 decimal place
 ```
 
-You can read more about the JSONata expression language and in particular, it's numeric functions, [here](https://docs.jsonata.org/numeric-functions)
+You can read more about the JSONata expression language and in particular, its numeric functions, [here](https://docs.jsonata.org/numeric-functions)
 
 ## Example
 
diff --git a/docs/en/user/migration/ui_form.json b/docs/en/user/migration/ui_form.json
@@ -55,7 +55,7 @@
     "new_properties": [
         {
             "property": "reset",
-            "notes": "On 'submit', this property defines whether or not the form clears it's data in the Dashboard."
+            "notes": "On 'submit', this property defines whether or not the form clears its data in the Dashboard."
         }
     ],
     "msgs": [
diff --git a/docs/en/user/multi-tenancy.md b/docs/en/user/multi-tenancy.md
@@ -88,7 +88,7 @@ When "Include Client Data" is enabled, every `msg._client` will detail the `sock
 
 ### Storing User Data
 
-By default, Dashboard will store the latest messages received against a given node in it's own context stores. However, for nodes that are setup to "Accept Client Data", this is not he case, as it's very memory inefficient for us to automatically store data for _every_ message, for _every_ user against every _widget_.
+By default, Dashboard will store the latest messages received against a given node in its own context stores. However, for nodes that are setup to "Accept Client Data", this is not he case, as it's very memory inefficient for us to automatically store data for _every_ message, for _every_ user against every _widget_.
 
 Instead, the recommended pattern is to use the "change" node, and the built-in `global` and `flow` context stores of Node-RED. We can make use of the `[]` annotation available in the "change" node, to store an object of the latest submitted form for a given user (making the most of the FlowFuse User Addon to get `msg._client.user.username`):
 
@@ -105,7 +105,7 @@ Let's take a look at the steps involved here:
 1. When a user loads the page, `ui-event` triggers a `$pageview` event, containing the details of the user viewing the page. 
 2. We check our `global` context store to see if we have any data stored against the user's username.
 3. If we do, we set `msg.payload` to the contents of the store, otherwise, branch to a "debug" node.
-4. Send the `msg.payload` to the form to populate it with the stored values
+4. Send the `msg.payload` to the form to populate it with the stored values.
 5. On submit of the form, save the contents of the form to the `global` context store, using the user's username as the key.
 
 ### Comparing different communication options
@@ -127,7 +127,7 @@ We can see how it's possible to control the interaction of a widget, and how the
 
 2. "Send to Same User" slider passes through a change node, and has the `socketId` field removed from `msg._client`, leaving just the `user` object. This means the data is sent to any connected clients where the same authenticated user is found.
 
-3. "Single Client" slider just passes it's default output to the "Chart" node, including the full `msg._client` object. This means that the data is only sent to the client (`socketId`) & user (`user`) that interacted with the slider.
+3. "Single Client" slider just passes its default output to the "Chart" node, including the full `msg._client` object. This means that the data is only sent to the client (`socketId`) & user (`user`) that interacted with the slider.
 
 Below you will find the flow that runs the above example:
 
diff --git a/docs/en/user/subflows.md b/docs/en/user/subflows.md
@@ -11,7 +11,7 @@ description: Maximize efficiency in FlowFuse Dashboard by leveraging subflows fo
 
 ## What are subflows?
 
-A subflow as an opportunity to build your own, completely custom node, with it's logic completely defined by other Node-RED nodes that you can configure and connect together in the workspace in any way you like.
+A subflow as an opportunity to build your own, completely custom node, with its logic completely defined by other Node-RED nodes that you can configure and connect together in the workspace in any way you like.
 
 Subflows remove the need to write any code, publish to npm, or maintain a separate repository. They are particularly useful for two reasons:
 
@@ -101,7 +101,7 @@ NOTE: You can still set the widget width and height to `0` to make the it perfor
 ![Screenshot of Node-RED, highlighting where the "Appearance" button is](../../assets/images/subflow-appearance.png){data-zoomable}
 *Screenshot of Node-RED, highlighting where the "Appearance" button is*
 
-When editing a subflow's properties, you can click the "Appearance" tab in order to customise it's appearance when the subflow is rendered in the workspace flows.
+When editing a subflow's properties, you can click the "Appearance" tab in order to customise its appearance when the subflow is rendered in the workspace flows.
 
 You can control:
 
diff --git a/docs/en/user/template-examples.md b/docs/en/user/template-examples.md
@@ -31,7 +31,7 @@ You can find a collection of example of how to use Chart.js within the `ui-templ
 
 ### Custom Data Tables
 
-Whilst we do offer the [`ui-table`](../nodes/widgets/ui-table.md) widget out of the box, it's fairly basic in it's functionality, and doesn't allow for much customization of cells and styling. 
+Whilst we do offer the [`ui-table`](../nodes/widgets/ui-table.md) widget out of the box, it's fairly basic in its functionality, and doesn't allow for much customization of cells and styling.
 
 In Node-RED Dashboard, there was a popular third-party `ui-table` widget, which offered wider customisation, but for FlowFuse Dashboard, we've taken a slightly different approach. Rather than defining a spec that you must put your data into, in order to utilise a set number of features in a library, with FlowFuse Dashboard, you can use the `ui-template` to customise a data table in anyway you like, and with any data format.
 
