Doc updates, Multirow filtering, strlcpy, inline

Author: ewowi

docs/develop/development.md

@@ -37,11 +37,11 @@ npm run dev
 
 There are 3 levels to add functionality:
 
-* **Standard ESP32-Sveltekit code**, e.g. Connections, Wifi and System. MoonBase files is also made using standard sveltekit as example but contains a few components used in MoonLight modules. Might be rewriteen as MoonLight Module in the future.
-  * lib folder for Sveltekit vack-end
+* **Standard ESP32-Sveltekit code**, e.g. Connections, Wifi and System. MoonBase files are also made using standard SvelteKit as examples but contain a few components used in MoonLight modules. Might be rewritten as a MoonLight Module in the future.
+  * lib folder for Sveltekit back-end
   * Read the [ESP32 Sveltekit docs](https://moonmodules.org/MoonLight/esp32sveltekit/)
 * [MoonLight Modules](https://moonmodules.org/MoonLight/moonbase/modules/) e.g. Lights Control, Effects, Info, Channels. They are subclasses of Modules.h/cpp and implement setupDefinition, onUpdate and optional loop. New modules need to be defined in main.cpp and added to menu.svelte. All further UI is generated by Module.svelte.
-  * src folder for MoonBase and MoonLight vack-end
+  * src folder for MoonBase and MoonLight back-end
 * **MoonLight Nodes**: the easiest and recommended way. See Effects.h, Layouts.h, Modifiers.h and Drivers.h for examples. They match closest WLED usermods. Each node has controls, a setup and a loop and can be switched on and off. For specific purposes hasOnLayout() and hasModifier() can return true.
   * src/MoonLight/nodes
 
@@ -67,7 +67,7 @@ See [Documentation](https://moonmodules.org/MoonLight/develop/documentation/)
 
     * The upstream MoonLight repo can now process this PR
 
-## Addtional info
+## Additional info
 
 ### Emoji coding
 
@@ -88,9 +88,9 @@ See [Documentation](https://moonmodules.org/MoonLight/develop/documentation/)
 
 ### UI development server
 
-To ease the frontend development you can deploy the vack-end code on an ESP32 board and pass the websocket and REST API calls through the development server's proxy running on your computer.
+To ease the front-end development you can deploy the back-end code on an ESP32 board and pass the websocket and REST API calls through the development server's proxy running on your computer.
 
-This very much speeds up UI development as no flashing to ESP32 is required to test updated UI. Svaing an UI file is enough to see the results!!!
+This very much speeds up UI development, as no flashing to the ESP32 is required to test updated UI. Saving a UI file is enough to see the results.
 
 See [Setup Proxy for Development](https://moonmodules.org/MoonLight/gettingstarted/#setup-proxy-for-development) and [development-server](https://moonmodules.org/MoonLight/gettingstarted/#development-server) how to setup.
 

docs/develop/installation.md

@@ -180,7 +180,7 @@ Before changing code, test if the current download of MoonLight is running fine.
 
 ### Install nodejs
 
-nodejs is needed if changes on the frontend (UI) are made (interface folder). On each file change, ☑️ or ➡️ will rebuild the UI using nodejs.
+nodejs is needed if changes on the front-end (UI) are made (interface folder). On each file change, ☑️ or ➡️ will rebuild the UI using nodejs.
 
 * Windows: if nodejs is not on your system you will get this error:
 

docs/develop/standardsguidelines.md

@@ -9,7 +9,7 @@
 * The main branch is the source to branch and merge to, no direct code commits to the main branch. As the main branch docs folder is the source for the website, doc changes can be made directly to main. 
 * Branches from main are made for latest updates and merged back to main when done.
 * The src folder is for all MoonBase and MoonLight Nodes and Modules development. No need for UI changes as that is generated for Nodes and Modules. The lib folder is for upstream (Sveltekit). The interface folder is for UI, mainly Sveltekit and Modules and Nodes generic functions.
-* A pull request should contain compilable code and tested to not crash the system at minimal and support also boards without PSRAM, e.g. ESP32-D0. Code may be work in progress.
+* A pull request should contain compilable code that is tested to, at minimum, not crash the system and also supports boards without PSRAM, e.g. ESP32-D0. Code may be work in progress.
 
 ## Describe your PR
 
@@ -35,7 +35,7 @@ Github will pick up the changes so your PR stays up-to-date.
 
 > [!CAUTION]
 > Do not use "force-push" while your PR is open!
-> It has many subtle and unexpected consequences on our github repository.
+> It has many subtle and unexpected consequences on our GitHub repository.
 > For example, we regularly lost review comments when the PR author force-pushes code changes. So, pretty please, do not force-push.
 
 You can find a collection of very useful tips and tricks here: https://github.com/wled-dev/WLED/wiki/How-to-properly-submit-a-PR
@@ -52,10 +52,10 @@ You can find a collection of very useful tips and tricks here: https://github.co
 * If you don't feel very confident using English, you can use AI for translating code comments and descriptions into English. AI bots are very good at understanding language. However, always check if the results is correct. The translation might still have wrong technical terms, or errors in some details.
 
 ### best practice with AI:
-  * As the person who contributes source code to MoonLight, make sure you understand exactly what the AI generated code does
-  * best practice: add a comment like ``'// below section of my code was generated by an AI``, when larger parts of your source code were not written by you personally.
+  * As the person who contributes source code to MoonLight, make sure you understand exactly what the AI-generated code does
+@@  * best practice: add a comment like ``'// below section of my code was generated by an AI``, when larger parts of your source code were not written by you personally.
   * always review translations and code comments for correctness
-  * always review AI generated source code
+  * always review AI-generated source code
   * If the AI has rewritten existing code, check that the change is necessary and that nothing has been lost or broken. Also check that previous code comments are still intact.
 
 ## Code style
@@ -64,7 +64,7 @@ You can find a collection of very useful tips and tricks here: https://github.co
 
 We use Clang-format for c-files (see .clang-format in the repo for the definition) and Prettier for front-end files.
 
-Right click Format Document on each file you edit before committing.
+Right-click Format Document on each file you edit before committing.
 
 ### Comments
 

interface/src/lib/components/moonbase/MultiRow.svelte

@@ -48,9 +48,14 @@
 		}
 	}
 
-	function handleReorder(reorderedItems: any[]) {
+	function handleReorder(reorderedItems: { item: any; originalIndex: number }[]) {
 		console.log('handleReorder', property.name, reorderedItems);
-		data[property.name] = reorderedItems.map((wrapper: any) => wrapper.item);
+		const full = [...data[property.name]];
+		reorderedItems.forEach(({ item }, pos) => {
+			const originalIndex = filteredItems[pos].originalIndex;
+			full[originalIndex] = item;
+		});
+		data[property.name] = full;
 		onChange();
 	}
 
@@ -98,11 +103,15 @@
 		const query = (isNegated ? filterValue.slice(1) : filterValue).toLowerCase();
 
 		// No filter or empty query → return items directly
-		if (!query) return data[property.name].map((item: any) => ({ item }));
+		if (!query)
+			return data[property.name].map((item: any, index: number) => ({
+				item,
+				originalIndex: index
+			}));
 
 		// Filtered items
 		return data[property.name]
-			.map((item: any) => ({ item }))
+			.map((item: any, index: number) => ({ item, originalIndex: index }))
 			.filter(({ item }: { item: any }) => {
 				const matchFound = property.n.slice(0, 3).some((propertyN: any) => {
 					let valueStr;