neo.mjs 10.1.1 → 10.2.1

package/learn/guides/fundamentals/InstanceLifecycle.md

@@ -2,10 +2,15 @@
 
 Understanding the lifecycle of a class instance in Neo.mjs is crucial for building robust and predictable
 applications. The framework provides a series of well-defined hooks that allow you to tap into different stages of an
-instance's life, from its creation to its destruction.
+instance's life, from its creation and rendering to its destruction.
 
-This guide will walk you through the entire lifecycle, starting with the initial synchronous steps and moving on to
-the asynchronous parts and destruction.
+This guide will walk you through the entire lifecycle, which can be broken down into four main phases:
+
+1.  **Synchronous Creation**: The initial, synchronous setup of the instance and its configuration.
+2.  **Asynchronous Initialization**: An optional phase for asynchronous tasks like data fetching.
+3.  **Mounting & Unmounting**: The dynamic phase where a component is rendered into the DOM, and potentially unmounted
+    and re-mounted.
+4.  **Destruction**: The final cleanup phase.
 
 ## How the Lifecycle is Triggered
 
@@ -16,73 +21,65 @@ The most common way to create component instances is declaratively, by defining
 `items` array. The framework then internally uses `Neo.create()` to turn these configuration objects into fully-fledged
 instances, automatically initiating their lifecycle.
 
-It is crucial to **never** create a Neo.mjs class instance using the `new` keyword (e.g., `new MyComponent()`),
-as this would bypass the entire lifecycle initialization process described below, resulting in a broken and
-improperly configured instance. Always let the framework handle instantiation, either through declarative `items`
-configs or, in less common cases, by using `Neo.create()` directly.
+It is crucial to **never** create a Neo.mjs class instance using the `new` keyword (e.g., `new MyComponent()`), as this
+would bypass the entire lifecycle initialization process described below, resulting in a broken and improperly configured
+instance. Always let the framework handle instantiation.
 
 ## 1. The Synchronous Creation Flow
 
 When the framework creates a new instance, it executes a sequence of synchronous methods. This initial phase is
-responsible for setting up the instance's basic configuration and state.
+responsible for setting up the instance's basic configuration and state. **At this stage, the component has not been
+rendered to the DOM.**
 
 The synchronous lifecycle methods are called in the following order:
 
 1.  **`new YourClass()`**: The framework first calls the actual JavaScript class constructor with **no arguments**.
-    This is a crucial step. Its primary purpose is to create the instance and initialize all of its defined class
-    fields. This ensures that by the time any Neo.mjs lifecycle method (like `construct`) or config hook
-    (like `beforeGetX`) is called, all class fields are fully available on `this`, preventing potential race
-    conditions or errors from accessing uninitialized properties.
+    Its primary purpose is to create the instance and initialize all of its defined class fields. This ensures that by
+    the time any Neo.mjs lifecycle method is called, all class fields are fully available on `this`.
 
-2.  **`construct(config)`**: This is the first Neo.mjs lifecycle hook called on the new instance. Its primary role is
-    to process the configuration object that was passed to `Neo.create()`. It's here that the initial values for
-    your configs are processed and applied via the config system.
+2.  **`construct(config)`**: This is the first Neo.mjs lifecycle hook. Its primary role is to process the configuration
+    object passed to `Neo.create()`. It's here that the initial values for your configs are processed and applied via
+    the config system.
 
 3.  **`onConstructed()`**: This hook is called immediately after `construct()` has finished. It's the ideal place to
-    perform any setup that depends on the initial configuration, such as setting initial values for other
-    properties or starting a process.
+    perform any setup that depends on the initial configuration. **Crucially, do not attempt to access the DOM here**,
+    as the component is not yet rendered.
 
-4.  **`onAfterConstructed()`**: This hook is called after `onConstructed()`. It provides another opportunity for
-    setup logic, which can be useful for separating concerns or for logic that needs to run after the primary
-    `onConstructed` logic has completed.
+4.  **`onAfterConstructed()`**: This hook is called after `onConstructed()`. It provides another opportunity for setup logic.
 
 5.  **`init()`**: This is the final synchronous hook in the creation process. It's a general-purpose initialization
-    method that you can use for any final setup tasks before the instance is returned by `Neo.create()`.
-
-It's important to remember that all of these methods are synchronous. Any asynchronous operations should be handled
-in the later, asynchronous phases of the lifecycle.
+    method for any final setup tasks.
 
-## 2. `constructor()` vs `construct()`: A Critical Distinction
+### `constructor()` vs `construct()`: A Critical Distinction
 
-While you *can* define a standard JavaScript `constructor()` method on a Neo.mjs class, it is strongly discouraged
-and considered a bad practice. The framework provides the `construct()` lifecycle hook for a very specific and
-powerful reason: **pre-processing configs**.
+While you *can* define a standard JavaScript `constructor()` method on a Neo.mjs class, it is strongly discouraged and
+considered a bad practice. The framework provides the `construct()` lifecycle hook for a very specific and powerful
+reason: **pre-processing configs**.
 
-### The `constructor()` Limitation
+#### The `constructor()` Limitation
 
 In standard JavaScript class inheritance, you **cannot** access the `this` context in a constructor before calling
 `super()`. This is a language-level restriction.
 
-```javascript
+```javascript readonly
 // Anti-pattern: Do not do this in Neo.mjs
 constructor(config) {
     // ERROR! 'this' is not available before super()
-    console.log(this.someClassField); 
+    console.log(this.someClassField);
 
     super(config); // Assuming a parent constructor call
 }
 ```
 
-### The `construct()` Advantage
+#### The `construct()` Advantage
 
-The `construct()` method, however, is just a regular method called by the framework *after* the instance has been
-fully created (via `new YourClass()`). This means that inside `construct()`, you have full access to `this` from the
-very first line.
+The `construct()` method, however, is just a regular method called by the framework *after* the instance has been fully
+created (via `new YourClass()`). This means that inside `construct()`, you have full access to `this` from the very first line.
 
 This enables a powerful pattern: you can inspect or modify the incoming `config` object *before* passing it up the
 inheritance chain with `super.construct(config)`. This is invaluable for component-specific logic.
 
-```javascript
+```javascript readonly
 // The correct Neo.mjs pattern
 construct(config) {
     // 'this' is fully available here!
@@ -97,53 +94,52 @@ construct(config) {
 }
 ```
 
-In summary, always use `construct()` for your initialization logic. It provides the flexibility needed to work
-within the Neo.mjs lifecycle and config system, a flexibility that the standard `constructor()` cannot offer.
-
-## 3. The Asynchronous Initialization Flow
+In summary, always use `construct()` for your initialization logic. It provides the flexibility needed to work within
+the Neo.mjs lifecycle and config system, a flexibility that the standard `constructor()` cannot offer.
 
-After the synchronous creation methods are complete, the instance lifecycle moves into an asynchronous phase. This is
-where you should place any logic that cannot be executed synchronously, such as loading external files, fetching
-data from a server, or waiting for other resources to become available.
+## 2. The Asynchronous Initialization Flow
 
-This phase is orchestrated by a microtask scheduled from within the `construct()` method.
+After the synchronous creation methods are complete, the instance lifecycle moves into an optional asynchronous phase.
+This is where you should place any logic that cannot be executed synchronously, such as loading external files or fetching data.
 
 ### `initAsync()`: The Asynchronous Entry Point
 
-The core of this phase is the `async initAsync()` method.
+The core of this phase is the `async initAsync()` method. It is scheduled as a microtask from within `construct()`.
 
-*   **Scheduling**: Immediately after the synchronous `construct()` logic is finished, the framework schedules a
-    microtask (`Promise.resolve().then(...)`) that will execute after the current JavaScript execution block is empty.
-*   **Execution**: This microtask calls and `await`s the `initAsync()` method. This is the designated place for all
-    asynchronous initialization logic. You can override this method in your own classes to perform tasks like
-    dynamic imports or initial data fetching.
-*   **Parent Call**: When overriding `initAsync()`, it is crucial to call `await super.initAsync()` at the beginning
-    of your implementation to ensure that parent classes can perform their own asynchronous setup, such as
-    registering remote methods.
+*   **Execution**: This microtask calls and `await`s `initAsync()`. This is the designated place for all asynchronous
+    initialization logic. When overriding `initAsync()`, it is crucial to call `await super.initAsync()` at the
+    beginning of your implementation.
 
-```javascript
+```javascript readonly
 // In your class
 async initAsync() {
     // Always call the parent method first!
     await super.initAsync();
 
-    // Your async logic here
-    const myModule = await import('./MyOptionalModule.mjs');
-    this.data = await myService.fetchInitialData();
+    // Your async logic here, wrapped in a try...catch block
+    try {
+        const myModule = await import('./MyOptionalModule.mjs');
+        this.data = await myService.fetchInitialData();
+    } catch (e) {
+        console.error('Failed to initialize component asynchronously', e);
+        // Handle the error appropriately, e.g., by setting an error state on the component.
+    }
 }
 ```
 
+**Important**: If the `initAsync()` method throws an error, the `isReady` flag will never be set to `true`. It is crucial
+to wrap your asynchronous logic in `try...catch` blocks to handle potential failures gracefully.
+
 ### `isReady`: The Signal of Completion
 
-Once the `initAsync()` promise resolves, the framework sets the instance's `isReady` config to `true`.
+Once the `initAsync()` promise resolves successfully, the framework sets the instance's `isReady` config to `true`.
 
-*   **`isReady_`**: The config is defined as `isReady_` (with a trailing underscore), which means it gets an
-    `afterSetIsReady(value, oldValue)` hook.
-*   **Reacting to Readiness**: You can implement the `afterSetIsReady()` method to be notified precisely when the
-    instance is fully initialized and ready for interaction. This is the most reliable way to coordinate logic that
-    depends on the component's full readiness.
+*   **`isReady_`**: The config is defined as `isReady_`, which means it gets an `afterSetIsReady(value, oldValue)` hook.
+*   **Reacting to Readiness**: You can implement `afterSetIsReady()` to be notified precisely when the instance is fully
+* initialized and ready for interaction. This is the most reliable way to coordinate logic that depends on the
+* component's full readiness.
 
-```javascript
+```javascript readonly
 // In your class
 afterSetIsReady(isReady, wasReady) {
     if (isReady && !wasReady) {
@@ -153,8 +149,50 @@ afterSetIsReady(isReady, wasReady) {
 }
 ```
 
-This `initAsync` -> `isReady` pattern provides a robust and predictable way to manage the asynchronous parts of the
-instance lifecycle, ensuring that dependent logic only runs when the instance is in a known, ready state.
+## 3. The Mounting Phase: Interaction with the DOM
+
+This phase is what truly sets Neo.mjs apart. A component's lifecycle is not complete after initialization; it only
+becomes fully interactive once it is **mounted** into the DOM. Furthermore, a component can be unmounted and re-mounted
+multiple times, even into different browser windows, all while preserving its instance and state.
+
+### `mounted`: The DOM-Ready Signal
+
+The `mounted_` config is the key to this phase. It is a boolean flag that indicates whether the component is currently
+rendered in the DOM.
+
+*   **`afterSetMounted(isMounted, wasMounted)`**: This is the most important hook for DOM interaction. It is called with
+* `true` when the component's VDOM is successfully rendered into the DOM, and with `false` when it is removed.
+
+**This is the only safe and reliable place to perform DOM measurements or manipulations.**
+
+```javascript readonly
+// In your component class
+afterSetMounted(isMounted, wasMounted) {
+    if (isMounted) {
+        console.log('Component is now in the DOM!');
+        // It is now safe to measure this.vnode.dom
+        const rect = this.vnode.dom.getBoundingClientRect();
+        console.log('Component dimensions:', rect.width, rect.height);
+    } else {
+        console.log('Component was removed from the DOM.');
+    }
+}
+```
+
+### The Re-Mounting Lifecycle
+
+Because a component can be removed from a container and added back later, the `afterSetMounted` hook can fire multiple
+times. This allows you to correctly manage DOM-related resources, such as third-party libraries or complex event
+listeners, that need to be created and destroyed in sync with the component's presence in the DOM.
+
+### Multi-Window Mounting
+
+Neo.mjs's multi-window support adds another layer to this phase. A component can be unmounted from one browser window
+and re-mounted into another. The framework manages this through the `windowId_` config.
+
+*   **`windowId_`**: This config tracks which browser window the component currently belongs to.
+*   **`afterSetWindowId(newWindowId, oldWindowId)`**: This hook is called when a component is moved between windows.
+* You can use it to manage any window-specific resources or logic.
 
 ## 4. Destruction: Cleaning Up with `destroy()`
 
@@ -182,7 +220,7 @@ registrations so that the instance can be safely garbage collected.
 
 Here is an example from `Neo.grid.Container` that illustrates key best practices:
 
-```javascript
+```javascript readonly
 // Example from src/grid/Container.mjs
 destroy(...args) {
     let me = this;
@@ -219,25 +257,24 @@ To summarize the best practices:
 2.  **Destroy Owned Instances**: If your class creates its own instances of other Neo.mjs classes (e.g., helpers,
     managers), you are responsible for calling `destroy()` on them.
 3.  **Clean Up Shared Instances**: If your class uses a shared instance (like a `Store` or a global service), do **not**
-    call `destroy()` on it. Instead, remove any listeners you added to it. A good pattern is to set the config
-    property to `null` (e.g., `this.store = null`) and perform the listener cleanup inside the `afterSet` hook.
+    call `destroy()` on it. Instead, remove any listeners you added to it. A good pattern is to set the config property
+    to `null` (e.g., `this.store = null`) and perform the listener cleanup inside the `afterSet` hook.
 4.  **Unregister from Services**: If your class registered itself with any external manager or service (like the
     `ResizeObserver`), be sure to unregister from it.
 
 ## 5. Lifecycle of Nested Instances: Set-Driven vs. Get-Driven
 
 A powerful feature of the config system is that a config property can be another Neo.mjs class instance. A common
-example is a grid's `selectionModel`. This raises an important architectural question: when should this nested
-instance be created? The framework supports two patterns, each with different implications for the lifecycle.
+example is a grid's `selectionModel`. This raises an important architectural question: when should this nested instance
+be created? The framework supports two patterns, each with different implications for the lifecycle.
 
 ### The Set-Driven Approach (Eager Instantiation)
 
-In this pattern, you ensure the instance is created as soon as the config is set. This is typically done inside a
-`beforeSet` hook.
+In this pattern, you ensure the instance is created as soon as the config is set. This is typically done inside a `beforeSet` hook.
 
 The `Neo.grid.Body` class provides a perfect example with its `selectionModel_` config.
 
-```javascript
+```javascript readonly
 // In Neo.grid.Body
 beforeSetSelectionModel(value, oldValue) {
     oldValue?.destroy();
@@ -248,13 +285,13 @@ beforeSetSelectionModel(value, oldValue) {
 }
 ```
 
-When the framework processes the grid body's configs during its `construct` phase, `beforeSetSelectionModel` is
-called. It immediately creates the selection model instance.
+When the framework processes the grid body's configs during its `construct` phase, `beforeSetSelectionModel` is called.
+It immediately creates the selection model instance.
 
-**The key takeaway is the guarantee this provides for `onConstructed()`**. Because the selection model was
-instantiated during `construct`, by the time `onConstructed()` is called, you can safely assume the instance exists.
+**The key takeaway is the guarantee this provides for `onConstructed()`**. Because the selection model was instantiated
+during `construct`, by the time `onConstructed()` is called, you can safely assume the instance exists.
 
-```javascript
+```javascript readonly
 // In Neo.grid.Body
 onConstructed() {
     super.onConstructed();
@@ -264,18 +301,18 @@ onConstructed() {
 }
 ```
 
-Use the set-driven approach when a nested instance is **essential** for the component's core functionality and needs
-to be available immediately after construction.
+Use the set-driven approach when a nested instance is **essential** for the component's core functionality and needs to
+be available immediately after construction.
 
 ### The Get-Driven Approach (Lazy Instantiation)
 
-Alternatively, you can defer the creation of a nested instance until it's actually needed for the first time. This
-is achieved by creating the instance within a `beforeGet` hook. This "lazy" approach can improve initial creation
+Alternatively, you can defer the creation of a nested instance until it's actually needed for the first time. This is
+achieved by creating the instance within a `beforeGet` hook. This "lazy" approach can improve initial creation
 performance if the nested instance is complex or not always used.
 
 `Neo.grid.Body` also demonstrates this pattern with its `columnPositions_` config.
 
-```javascript
+```javascript readonly
 // In Neo.grid.Body
 beforeGetColumnPositions(value) {
     // If the backing field (_columnPositions) is null...

package/learn/tree.json

@@ -64,6 +64,7 @@
         {"name": "Rock Scissors Paper",                                "parentId": "Tutorials",                                           "id": "tutorials/RSP", "hidden": true},
         {"name": "Earthquakes",                                        "parentId": "Tutorials",                                           "id": "tutorials/Earthquakes"},
         {"name": "Todo List",                                          "parentId": "Tutorials",                                           "id": "tutorials/TodoList"},
+        {"name": "Creating a Functional Button",                       "parentId": "Tutorials",                                           "id": "tutorials/CreatingAFunctionalButton"},
     {"name": "JavaScript Classes",                                     "parentId": null,                                 "isLeaf": false, "id": "JavaScript",  "collapsed": true},
         {"name": "Classes, Properties, and Methods",                   "parentId": "JavaScript",                                          "id": "javascript/Classes"},
         {"name": "Overriding Methods",                                 "parentId": "JavaScript",                                          "id": "javascript/Overrides"},

package/learn/tutorials/CreatingAFunctionalButton.md

@@ -0,0 +1,179 @@
+# Creating a Custom Functional Button
+
+In the "Describing a View" guide, you learned the basics of functional and class-based components. Now, let's dive
+deeper into the modern approach by creating our own custom, reusable functional button.
+
+**Note:** Neo.mjs already provides a powerful, feature-rich functional button (`Neo.functional.button.Base`). The purpose
+of this guide is not to replace it, but to use a button as a simple, practical example to teach you the fundamentals of
+creating your own functional components.
+
+This guide will walk you through the process of building a `MyCoolButton` component that has its own unique style and
+behavior, using the `defineComponent` helper.
+
+## 1. Defining the Component
+
+First, let's create the basic structure of our component. We'll use `defineComponent` and provide a `className`
+and a `createVdom` method.
+
+```javascript readonly
+import {defineComponent} from '../../src/functional/_export.mjs';
+
+const MyCoolButton = defineComponent({
+    className: 'My.CoolButton',
+
+    createVdom(config) {
+        // We will build our VDOM here
+        return {
+            tag : 'button',
+            cls : ['my-cool-button'],
+            text: 'Click Me'
+        }
+    }
+});
+
+export default MyCoolButton;
+```
+
+## 2. Adding Custom Configs
+
+A component isn't very reusable without configs. Let's add `text_` and `iconCls_` to our component's public API.
+Remember, the trailing underscore `_` makes the config reactive.
+
+We'll also update `createVdom` to use these configs. The `config` parameter of `createVdom` is a reactive proxy to the
+component's instance, so we can access our configs directly from it.
+
+```javascript readonly
+import {defineComponent} from '../../src/functional/_export.mjs';
+
+const MyCoolButton = defineComponent({
+    className: 'My.CoolButton',
+
+    // 1. Define the public API
+    config: {
+        iconCls_: null,
+        text_   : 'Default Text'
+    },
+
+    // 2. Use the configs in createVdom
+    createVdom(config) {
+        const {iconCls, text} = config;
+
+        return {
+            tag: 'button',
+            cls: ['my-cool-button'],
+            cn : [{
+                tag      : 'span',
+                cls      : ['fa', iconCls],
+                removeDom: !iconCls // Don't render the span if no iconCls is provided
+            }, {
+                tag: 'span',
+                cls: ['my-cool-button-text'],
+                text
+            }]
+        }
+    }
+});
+
+export default MyCoolButton;
+```
+
+## 3. Handling User Events
+
+Static buttons are boring. Let's make it interactive. We can add a `handler_` config and an `onClick` method to our
+component. The `addDomListeners` method in the `construct` hook allows us to listen for native DOM events.
+
+```javascript readonly
+import {defineComponent} from '../../src/functional/_export.mjs';
+
+const MyCoolButton = defineComponent({
+    className: 'My.CoolButton',
+
+    config: {
+        handler_: null, // A function to call on click
+        iconCls_: null,
+        text_   : 'Default Text'
+    },
+
+    construct(config) {
+        // The super.construct call is important!
+        // It sets up the component's lifecycle and effects.
+        this.super(config);
+
+        this.addDomListeners({
+            click: this.onClick,
+            scope: this
+        });
+    },
+
+    createVdom(config) {
+        // ... (same as before)
+    },
+
+    onClick(data) {
+        // If a handler function is provided, call it.
+        this.handler?.(this);
+    }
+});
+
+export default MyCoolButton;
+```
+
+## 4. Using Your Custom Component
+
+Now you can use `MyCoolButton` just like any other Neo.mjs component, either in a functional or a class-based view.
+
+```javascript live-preview
+import {defineComponent} from '../functional/_export.mjs';
+import Container         from '../container/Base.mjs';
+
+// 1. Define our custom button
+const MyCoolButton = defineComponent({
+    className: 'My.CoolButton',
+    config: {
+        handler_: null,
+        iconCls_: null,
+        text_   : 'Default Text'
+    },
+    construct(config) {
+        this.super(config);
+        this.addDomListeners({click: this.onClick, scope: this});
+    },
+    createVdom(config) {
+        const {iconCls, text} = config;
+        return {
+            tag: 'button',
+            cls: ['my-cool-button'],
+            cn : [
+                {tag: 'span', cls: ['fa', iconCls], removeDom: !iconCls},
+                {tag: 'span', cls: ['my-cool-button-text'], text}
+            ]
+        }
+    },
+    onClick(data) {
+        this.handler?.(this);
+    }
+});
+
+// 2. Use it in a MainView
+class MainView extends Container {
+    static config = {
+        className: 'GS.guides.CustomButtonMainView',
+        layout   : {ntype: 'vbox', align: 'start'},
+        items    : [{
+            module : MyCoolButton,
+            iconCls: 'fa-star',
+            text   : 'My Button!',
+            handler(button) {
+                console.log('Button clicked!', button);
+                button.text = 'Clicked!'; // It's reactive!
+            }
+        }]
+    }
+}
+
+MainView = Neo.setupClass(MainView);
+```
+
+This example demonstrates the full power of the functional component model. You can quickly create reusable, reactive,
+and encapsulated components with a clean and modern API. From here, you could add more configs, more complex VDOM logic,
+or even internal state using the `useConfig` hook to build even more powerful components.

package/package.json

@@ -1,6 +1,6 @@
 {
     "name"           : "neo.mjs",
-    "version"        : "10.1.1",
+    "version"        : "10.2.1",
     "description"    : "Neo.mjs: The multi-threaded UI framework for building ultra-fast, desktop-like web applications with uncompromised responsiveness, inherent security, and a transpilation-free dev mode.",
     "type"           : "module",
     "repository"     : {
@@ -88,7 +88,7 @@
         "fs-extra"                     : "^11.3.0",
         "highlightjs-line-numbers.js"  : "^2.9.0",
         "html-minifier-terser"         : "^7.2.0",
-        "inquirer"                     : "^12.8.2",
+        "inquirer"                     : "^12.9.0",
         "marked"                       : "^16.1.1",
         "monaco-editor"                : "0.50.0",
         "neo-jsdoc"                    : "1.0.1",
@@ -98,7 +98,7 @@
         "siesta-lite"                  : "5.5.2",
         "terser"                       : "^5.43.1",
         "url"                          : "^0.11.4",
-        "webpack"                      : "^5.100.2",
+        "webpack"                      : "^5.101.0",
         "webpack-cli"                  : "^6.0.1",
         "webpack-dev-server"           : "^5.2.2",
         "webpack-hook-plugin"          : "^1.0.7",

package/src/DefaultConfig.mjs

@@ -299,12 +299,12 @@ const DefaultConfig = {
     useVdomWorker: true,
     /**
      * buildScripts/injectPackageVersion.mjs will update this value
-     * @default '10.1.1'
+     * @default '10.2.1'
      * @memberOf! module:Neo
      * @name config.version
      * @type String
      */
-    version: '10.1.1'
+    version: '10.2.1'
 };
 
 Object.assign(DefaultConfig, {

package/src/button/Base.mjs

@@ -109,7 +109,10 @@ class Button extends Component {
         route_: null,
         /**
          * The text displayed on the button [optional]
-         * @member {String|null} text=null
+         * You can either pass a string, or a vdom cn array.
+         * @example
+         *  text: [{tag: 'span', style: {color: '#bbbbbb'}, text: '●'}, {vtype: 'text', text: ' Cases'}]
+         * @member {Object[]|String|null} text=null
          * @reactive
          */
         text: null,
@@ -378,8 +381,8 @@ class Button extends Component {
 
     /**
      * Triggered after the text config got changed
-     * @param {String|null} value
-     * @param {String|null} oldValue
+     * @param {Object[]|String|null} value
+     * @param {Object[]|String|null} oldValue
      * @protected
      */
     afterSetText(value, oldValue) {
@@ -393,7 +396,13 @@ class Button extends Component {
         textNode.removeDom = isEmpty;
 
         if (!isEmpty) {
-            textNode.text = value
+            if (Neo.isArray(value)) {
+                textNode.cn = value;
+                delete textNode.text
+            } else {
+                textNode.text = value;
+                delete textNode.cn
+            }
         }
 
         me.update()

package/src/container/Base.mjs

@@ -671,10 +671,17 @@ class Container extends Component {
      *
      */
     onConstructed() {
-        let me = this;
+        let me           = this,
+            layoutConfig = me.layout;
+
+        // If the layout is a config object (not an instance), deep clone it
+        // to prevent prototype pollution.
+        if (layoutConfig && !(layoutConfig instanceof LayoutBase)) {
+            layoutConfig = Neo.clone(layoutConfig, true)
+        }
 
         // in case the Container does not have a layout config, the setter won't trigger
-        me._layout = me.createLayout(me.layout);
+        me._layout = me.createLayout(layoutConfig);
         me._layout?.applyRenderAttributes();
 
         super.onConstructed();

package/src/data/Store.mjs

@@ -170,7 +170,9 @@ class Store extends Base {
 
                 me.isLoading = false;
 
-                me.add(value)
+                me.add(value);
+
+                me.isLoaded = true
             }
         }
     }
@@ -386,6 +388,7 @@ class Store extends Base {
                 if (response.success) {
                     me.totalCount = response.totalCount;
                     me.data       = Neo.ns(me.responseRoot, false, response); // fires the load event
+                    me.isLoaded   = true;
 
                     return me.data
                 }
@@ -402,6 +405,8 @@ class Store extends Base {
                     me.data = Neo.ns(me.responseRoot, false, data.json) || data.json // fires the load event
                 }
 
+                me.isLoaded = true;
+
                 return data?.json || null
             } catch(err) {
                 console.error('Error for Neo.Xhr.request', {id: me.id, error: err, url: opts.url});
@@ -446,8 +451,8 @@ class Store extends Base {
 
         // Being constructed does not mean that related afterSetStore() methods got executed
         // => break the sync flow to ensure potential listeners got applied
-        me.timeout(1).then(() => {
-            if (me.getCount() > 0) {
+        Promise.resolve().then(() => {
+            if (me.isLoaded) {
                 me.fire('load', me.items)
             } else if (me.autoLoad) {
                 me.load()