neo.mjs 10.1.1 → 10.2.0

package/learn/blog/v10-deep-dive-functional-components.md

@@ -1,28 +1,27 @@
-# Beyond Hooks: A New Breed of Functional Components for a Multi-Threaded World
+# Designing Functional Components for a Multi-Threaded World
 
-If you're a seasoned React developer, you've mastered the art of hooks. You know how to build complex, stateful UIs with
-`useState`, `useEffect`, and `useMemo`. You also know the trade-offs—the intricate dependency arrays, the constant battle
-against unnecessary re-renders, and the "memoization tax" you pay to keep your application performant.
+## Say Goodbye to Manual Memoization: How a New Architecture Makes Performance a Feature, Not a Chore.
 
-We've been taught that these trade-offs are fundamental to the functional component model. But what if they aren't?
-What if they are merely symptoms of a single-threaded architecture?
+Functional components have become a standard for building UIs, but they often come with a hidden cost: a constant, manual
+effort to manage performance. We've learned to fight unnecessary re-renders with memoization hooks and complex dependency
+arrays. But what if these weren't fundamental trade-offs? What if they were symptoms of an architecture that binds our UI
+logic to a single thread?
 
-This article will show you a new breed of functional component, born from a multi-threaded world, that eliminates these
-compromises by design. We didn't build them to copy other frameworks; we built them because our architecture unlocked a
-better way to write UIs.
+This is an exploration into a different kind of functional component—one designed from the ground up for a multi-threaded
+world, where performance is a feature of the architecture, not a burden on the developer.
 
 *(Part 3 of 5 in the v10 blog series. Details at the bottom.)*
 
-### A First Look: The Anatomy of a Neo.mjs Functional Component
+### A First Look: The Anatomy of a Multi-Threaded Functional Component
 
-Before we dive into the "why," let's look at the "what." Here is a simple, complete, and reactive functional component
-in Neo.mjs. Keep this structure in mind as we explore how it solves the problems you've come to accept as normal.
+Before we dive into the "why," let's look at the "what." Here is a simple, complete, and reactive functional component in
+Neo.mjs. Keep this structure in mind as we explore how it solves common performance problems at an architectural level.
 
 ```javascript
 import {defineComponent, useConfig, useEvent} from 'neo.mjs';
 
 export default defineComponent({
-    // The component's public API (like props)
+    // The component's public API
     config: {
         className: 'My.Counter',
         labelText_: 'Counter:'
@@ -30,7 +29,7 @@ export default defineComponent({
 
     // The function that creates the VDOM
     createVdom(config) {
-        // Internal, private state (like useState)
+        // Internal, private state
         const [count, setCount] = useConfig(0);
 
         // An event listener that updates the private state
@@ -47,22 +46,26 @@ export default defineComponent({
 });
 ```
 
-Notice what's missing: there are no dependency arrays, no `memo` wrappers, and no `useCallback` hooks. Now, let's explore
-the architecture that makes this clean, simple code possible.
+Notice what's missing: there are no dependency arrays and no manual memoization wrappers. Now, let's explore the
+architecture that makes this clean, simple code possible.
 
 ---
 
 ### The Architectural Divide: Why Your Component's Environment Matters
 
-Before we deconstruct the problems, we have to address the fundamental difference that changes everything. In a
-traditional framework like React, your component function, its state, its reconciliation (diffing), and its DOM
-manipulation all happen on the **same main thread** that is responsible for user interactions.
+The key to this new model is a fundamental shift in where your code runs. In a traditional single-threaded framework,
+your component logic, state management, VDOM diffing, and DOM manipulation all compete for resources on the
+**same main thread** that handles user interactions.
 
 In Neo.mjs, the architecture is fundamentally different:
 
 1.  **Your Application Logic (including your component's `createVdom` function) runs in a dedicated App Worker.**
 2.  **The VDOM diffing happens in a separate VDom Worker.**
 3.  **The Main Thread is left with one primary job: applying the calculated DOM patches.**
+    While this process leverages browser primitives like `requestAnimationFrame` for optimal visual synchronization,
+    it's crucial to understand that *only* the final, highly optimized DOM updates occur here. Your application logic
+    and VDOM calculations are entirely offloaded to workers, preventing main thread contention and ensuring a consistently
+    smooth user experience.
 
 This isn't just a minor difference; it's a paradigm shift. Your component code is decoupled from the rendering engine,
 which allows for a level of performance and predictability that is architecturally impossible on the main thread.
@@ -70,64 +73,76 @@ With this in mind, let's see how this new architecture solves old problems.
 
 ---
 
-### Deconstructing the "React Tax": How a New Architecture Solves Old Problems
+### Solving Core Performance Challenges Architecturally
 
-Let's tackle the compromises you've learned to live with, one by one, and show how a multi-threaded architecture solves
-them at their root.
+Let's tackle the performance compromises you've learned to live with, one by one, and show how a multi-threaded
+architecture solves them at their root.
 
-#### 1. The Problem: Cascading Re-Renders & The `memo` Tax
+#### 1. The Challenge: Cascading Updates
 
-**The React Way:** You know the drill. A state change in a parent component triggers a re-render. By default, React then
-re-renders **all of its children**, whether their props have changed or not. To prevent this performance drain,
-you are forced to pay the `memo` tax: wrapping components in `React.memo()`, manually memoizing functions with
-`useCallback()`, and objects with `useMemo()`. This manual optimization becomes a core, and often frustrating,
-part of the development process.
-
-```javascript
-// A typical "optimized" React component
-const MyComponent = React.memo(({ onButtonClick, user }) => {
-  console.log('Rendering MyComponent');
-  return <button onClick={onButtonClick}>{user.name}</button>;
-});
-
-const App = () => {
-  const [count, setCount] = useState(0);
-
-  // We must wrap this in useCallback to prevent MyComponent from re-rendering
-  // every time the App component's state changes.
-  const handleClick = useCallback(() => {
-    console.log('Button clicked!');
-  }, []);
-
-  // We must wrap this in useMemo to ensure the object reference is stable.
-  const user = useMemo(() => ({ name: 'John Doe' }), []);
-
-  return (
-    <div>
-      <button onClick={() => setCount(c => c + 1)}>App Clicks: {count}</button>
-      <MyComponent onButtonClick={handleClick} user={user} />
-    </div>
-  );
-};
-```
+In many component-based systems, a state change in a parent component triggers a re-render. By default, this often
+re-renders **all of its children**, whether their own inputs have changed or not. To prevent this performance drain,
+developers are forced into manual optimization. This often involves wrapping components in memoization functions and
+carefully managing the referential stability of callbacks and object props. This manual work becomes a core, and often
+frustrating, part of the development process.
 
 **The Neo.mjs Solution: Surgical Effects, Not Brute-Force Renders**
 
 Our `createVdom` method is a surgical `Effect`. It automatically and precisely tracks every piece of reactive state it reads.
-When a piece of state changes, **only the specific `createVdom` effects that depend on that exact piece of state are queued
-for re-execution.**
+When a piece of state changes, **only the specific `createVdom` effects that depend on that exact piece of state are
+queued for re-execution.**
 
 There are no cascading re-renders. If a parent's `createVdom` re-runs, but the configs passed to a child have not changed,
-the child component's `createVdom` function is **never executed**. 
+the child component's `createVdom` function is **never executed**.
+
+This efficiency extends to child components. On the first execution cycle, when a child component is encountered in the VDOM,
+Neo.mjs creates a new instance of that child component. In all subsequent renders, if the child component is still present,
+Neo.mjs *retains* the existing instance. Instead of re-executing the child's `createVdom` or re-creating its entire VDOM,
+Neo.mjs employs a sophisticated `diffAndSet()` mechanism. This process surgically compares the new configuration (props)
+intended for the child with its last applied configuration. Only if actual changes are detected are the corresponding
+`set()` methods invoked on the child component's instance. This triggers a highly localized, scoped VDOM update within
+that child, ensuring that only the truly affected parts of the UI are re-rendered, even for deeply nested components.
+
+To prove this, consider this example:
+```javascript
+import {defineComponent, useConfig} from 'neo.mjs/src/functional/_export.mjs';
+
+const ChildComponent = defineComponent({
+    createVdom(config) {
+        // This log is our proof. It will only fire when this
+        // specific component's render logic is executed.
+        console.log('Rendering ChildComponent');
+        return {tag: 'div', text: 'I am the child'};
+    }
+});
+
+export default defineComponent({
+    createVdom() {
+        const [count, setCount] = useConfig(0);
 
-This means `memo`, `useCallback`, and `useMemo` are not needed. The architecture is efficient by default, eliminating an
-entire class of performance optimizations and bugs.
+        return {
+            cn: [{
+                tag: 'button',
+                onclick: () => setCount(prev => prev + 1),
+                text: `Parent Clicks: ${count}`
+            }, {
+                // The child component receives no props that change
+                // when the parent's internal 'count' state changes.
+                module: ChildComponent
+            }]
+        }
+    }
+});
+```
+> When you run this code and click the button, you will see the "Parent Clicks" count update in the UI, but the
+> "Rendering ChildComponent" message will only appear in the console **once**. This demonstrates that the parent's state
+> change did not trigger a re-render of the child, proving the efficiency of the architecture.
 
-#### 2. The Problem: The Boilerplate of Immutability
+#### 2. The Challenge: The Boilerplate of Immutability
 
-**The React Way:** To change a nested object in React state, you have to meticulously reconstruct the object path with
-spread syntax (`...`), creating new references for every level. This is required to signal to React's diffing algorithm
-that something has changed.
+To signal that a state change has occurred, many frameworks require developers to treat state as immutable. To change a
+nested object, you have to meticulously reconstruct the object path, creating new references for every level. While this
+makes the change detection algorithm simpler for the framework, it offloads significant cognitive burden onto the developer.
 
 ```javascript
 // The familiar immutable update dance
@@ -143,7 +158,7 @@ setState(prevState => ({
 }));
 ```
 
-**The Neo.mjs Solution: Mutability for You, Immutability for the Machine**
+**The Neo.mjs Solution:** Mutability for You, Immutability for the Machine
 
 We believe the developer should not carry this cognitive load. In Neo.mjs, you can just mutate the state directly.
 It's simple and intuitive.
@@ -157,12 +172,12 @@ How does it work? When an update is triggered, the framework handles creating an
 the diffing process in the VDom Worker. We provide the best of both worlds: simple, direct mutation for the developer
 and a safe, immutable structure for the high-performance diffing algorithm.
 
-#### 3. The Problem: The "SSR and Hydration is the ONLY way" Mindset
+#### 3. The Challenge: The "Hydration is the Only Way" Mindset
 
-**The React/Next.js Way:** The industry has invested heavily in Server-Side Rendering and hydration to improve perceived
-performance and SEO. For content-heavy sites, this is a valid strategy. But for complex, stateful Single-Page Applications,
-it introduces immense complexity: the "hydration crisis," the difficulty of managing server vs. client components, and
-the fact that after all that work, your application is *still* running on the client's main thread.
+The industry has invested heavily in Server-Side Rendering and hydration to improve perceived performance and SEO.
+For content-heavy sites, this is a valid strategy. But for complex, stateful Single-Page Applications, it introduces
+immense complexity: the "hydration crisis," the difficulty of managing server vs. client components, and the fact that
+after all that work, your application is *still* running on the client's main thread.
 
 **The Neo.mjs Solution: Blueprints, Not Dehydrated HTML**
 
@@ -173,13 +188,20 @@ complex applications that are not primarily focused on static content.
 
 ---
 
-### The "WOW" Effect: Building a Real Application
+### Building a Real Application
 
 The simple counter example is a great start, but the true power of functional components is revealed when you build a
 complete, interactive application. Let's build a slightly more advanced "Task List" application to demonstrate how all
 the pieces come together.
 
 This example will showcase:
+- **Full Interoperability:** Neo.mjs embraces both functional and class-based (OOP) component paradigms as first-class
+  citizens, offering unparalleled flexibility. For developers familiar with the functional style, our functional
+  components provide a natural and intuitive starting point within Neo.mjs, allowing them to leverage a familiar approach.
+  Regardless of your preferred paradigm, you can seamlessly integrate functional components into traditional OOP containers,
+  and conversely, directly embed class-based components within the declarative VDOM of a functional component.
+  This architectural strength empowers developers to choose the most appropriate style for each part of their application,
+  or combine them as needed, without compromise.
 - **Component Composition:** Using a class-based `List` component within our functional view.
 - **State Management:** Tracking the currently selected task.
 - **Conditional Rendering:** Displaying task details only when a task is selected.
@@ -204,8 +226,7 @@ const TaskStore = Neo.create(Store, {
 // 2. Define our main application view
 export default defineComponent({
     config: {
-        className: 'My.TaskListApp',
-        layout: {ntype: 'hbox', align: 'stretch'}
+        className: 'My.TaskListApp'
     },
     createVdom() {
         // 3. Manage the selected task with useConfig
@@ -251,36 +272,25 @@ export default defineComponent({
 ```
 
 This single `defineComponent` call creates a fully-featured application. Notice how the `createVdom` function is a pure,
-declarative representation of the UI. When the `selectedTask` state changes, the framework surgically re-renders only
-the details pane. This is the power of the new component model in action: complex, stateful, and performant applications
-with beautifully simple code.
-
----
-
-### The AI Connection: The Inevitable Next Step
-
-This blueprint-first, surgically reactive, and mutable-by-default model isn't just better for you; it's the architecture
-an AI would choose. An AI can easily generate and manipulate a structured JSON blueprint, but it struggles to generate
-flawless, complex JSX. By building on these principles, you are not just using a new framework; you are future-proofing
-your skills for the AI era.
+declarative representation of the UI. When the `selectedTask` state changes, the framework surgically re-renders only the
+details pane. This is the power of the new component model in action: complex, stateful, and performant applications with
+beautifully simple code.
 
 ---
 
 ### Conclusion: A Different Philosophy, A Better Component
 
-Neo.mjs functional components are not a "React clone." They are a re-imagining of what a functional component can be
-when freed from the architectural constraints of the main thread. They offer a development experience that is not only
-more performant by default but also simpler, more intuitive, and ready for the AI-driven future of the web.
+Neo.mjs functional components are a re-imagining of what a functional component can be when freed from the architectural
+constraints of the main thread. They offer a development experience that is not only more performant by default but also
+simpler and more intuitive.
 
 This is what it feels like to stop paying the performance tax and start building again.
 
 The clean, hook-based API for functional components is possible because it stands on the shoulders of a robust, modular,
-and deeply integrated class system. We've engineered the framework's core to handle the complex machinery of reactivity
-and lifecycle management automatically. To learn more about the powerful engine that makes this all possible, see our
-deep dive on the **Two-Tier Reactivity System**.
+and deeply integrated class config system. To learn more about the powerful engine that makes this all possible, see our deep
+dive on the **Two-Tier Reactivity System**.
 
-Next, we will look at how this architecture revolutionizes the very way we render UIs with the Asymmetric VDOM
-and JSON Blueprints.
+Next, we will look at how this architecture revolutionizes the very way we render UIs with the Asymmetric VDOM and JSON Blueprints.
 
 ---
 
@@ -288,6 +298,6 @@ and JSON Blueprints.
 
 1. [A Frontend Love Story: Why the Strategies of Today Won't Build the Apps of Tomorrow](./v10-post1-love-story.md)
 2. [Deep Dive: Named vs. Anonymous State - A New Era of Component Reactivity](./v10-deep-dive-reactivity.md)
-3. Beyond Hooks: A New Breed of Functional Components for a Multi-Threaded World
-4. [Deep Dive: The VDOM Revolution - JSON Blueprints & Asymmetric Rendering](./v10-deep-dive-vdom-revolution.md)
-5. [Deep Dive: The State Provider Revolution](./v10-deep-dive-state-provider.md)
+3. Designing Functional Components for a Multi-Threaded World
+4. [The VDOM Revolution: How We Render UIs from a Web Worker](./v10-deep-dive-vdom-revolution.md)
+5. [Designing a State Manager for Performance: A Deep Dive into Hierarchical Reactivity](./v10-deep-dive-state-provider.md)

package/learn/blog/v10-deep-dive-reactivity.md

@@ -517,6 +517,6 @@ doesn't just simplify your code — it makes entirely new patterns of developmen
 
 1. [A Frontend Love Story: Why the Strategies of Today Won't Build the Apps of Tomorrow](./v10-post1-love-story.md)
 2. Deep Dive: Named vs. Anonymous State - A New Era of Component Reactivity
-3. [Beyond Hooks: A New Breed of Functional Components for a Multi-Threaded World](./v10-deep-dive-functional-components.md)
-4. [Deep Dive: The VDOM Revolution - JSON Blueprints & Asymmetric Rendering](./v10-deep-dive-vdom-revolution.md)
-5. [Deep Dive: The State Provider Revolution](./v10-deep-dive-state-provider.md)
+3. [Designing Functional Components for a Multi-Threaded World](./v10-deep-dive-functional-components.md)
+4. [The VDOM Revolution: How We Render UIs from a Web Worker](./v10-deep-dive-vdom-revolution.md)
+5. [Designing a State Manager for Performance: A Deep Dive into Hierarchical Reactivity](./v10-deep-dive-state-provider.md)

package/learn/blog/v10-deep-dive-state-provider.md

@@ -1,55 +1,31 @@
-# Deep Dive: The State Provider Revolution
+# Designing a State Manager for Performance: A Deep Dive into Hierarchical Reactivity
 
-**Subtitle: How Neo.mjs Delivers Intuitive State Management Without the Performance Tax**
+Every application developer knows the pain of state management. You have a piece of state—a user object, a theme setting—that needs to be accessed by a component buried deep within your UI tree. The traditional approach is "prop-drilling": passing that data down through every single intermediate component. It's tedious, error-prone, and creates a tight coupling between components that shouldn't know about each other.
 
-In our "Three-Act Revolution" series, we've explored the high-level concepts of Neo.mjs v10. Now, it's time to dive deep
-into the technology that powers **Act I: The Reactivity Revolution**. We'll explore the new `state.Provider`, a system
-designed to solve one of the most persistent challenges in application development: managing shared state.
+Modern frameworks solve this with a "Context API," a central provider that makes state available to any descendant. While this solves prop-drilling, it often introduces a hidden performance penalty. In many implementations, when *any* value in the context changes, *all* components consuming that context are forced to re-render, even if they don't care about the specific piece of data that changed.
 
-*(Part 5 of 5 in the v10 blog series. Details at the bottom.)*
-
-### 1. The Problem: Prop-Drilling and the "Context Tax"
-
-Every application developer knows the pain. You have a piece of state—a user object, a theme setting—that needs to be
-accessed by a component buried deep within your UI tree. The traditional approach is "prop-drilling": passing that data
-down through every single intermediate component. It's tedious, error-prone, and creates a tight coupling between
-components that shouldn't know about each other.
-
-Modern frameworks solve this with a "Context API," a central provider that makes state available to any descendant.
-While this solves prop-drilling, it often introduces a hidden performance penalty: the "Context Tax." In many
-implementations, when *any* value in the context changes, *all* components consuming that context are forced to re-render,
-even if they don't care about the specific piece of data that changed. This can lead to significant,
-unnecessary rendering work.
+This is the story of how we built a state provider from the ground up to solve this problem, delivering the convenience of a context API without the performance tax.
 
-Neo.mjs v10's `state.Provider` is designed to give you the convenience of a context API without this performance tax.
+*(Part 5 of 5 in the v10 blog series. Details at the bottom.)*
 
-### 2. The Neo.mjs Solution: From Custom Parsing to a Universal Foundation
+### The Evolution: From Custom Parsing to a Universal Foundation
 
-Neo.mjs has had a state provider for a long time, and it was already reactive. So, what’s the big deal with the v10 version?
-The difference lies in the *foundation*.
+Neo.mjs has had a state provider for a long time, and it was already reactive. So, what’s the big deal with the v10 version? The difference lies in the *foundation*.
 
-The previous state provider was a clever, custom-built system. It worked by parsing your binding functions with regular
-expressions to figure out which `data` properties you were using. This was effective, but had two major limitations:
+The previous state provider was a clever, custom-built system. It worked by parsing your binding functions with regular expressions to figure out which `data` properties you were using. This was effective, but had two major limitations:
 
-1.  **It Only Worked for `data`:** You could only bind to properties inside the provider's `data` object. Binding to an
-    external store's `count` or another component's `width` was simply not possible.
-2.  **It Was Brittle:** Relying on regex parsing meant that complex or unconventionally formatted binding functions could
-    sometimes fail to register dependencies correctly, leading to frustrating debugging sessions.
+1.  **It Only Worked for `data`:** You could only bind to properties inside the provider's `data` object. Binding to an external store's `count` or another component's `width` was simply not possible.
+2.  **It Was Brittle:** Relying on regex parsing meant that complex or unconventionally formatted binding functions could sometimes fail to register dependencies correctly, leading to frustrating debugging sessions.
 
-The v10 revolution was to throw out this custom parsing logic and rebuild the entire state management system on top of a
-universal, foundational concept: **`Neo.core.Effect`**.
+The v10 revolution was to throw out this custom parsing logic and rebuild the entire state management system on top of a universal, foundational concept: **`Neo.core.Effect`**.
 
-This new foundation is what makes the modern `state.Provider` so powerful. It doesn't need to guess your dependencies;
-it *knows* them. When a binding function runs, `core.Effect` observes every reactive property you access—no matter where
-it lives—and builds a precise dependency graph in real-time.
+This new foundation is what makes the modern `state.Provider` so powerful. It doesn't need to guess your dependencies; it *knows* them. When a binding function runs, `core.Effect` observes every reactive property you access—no matter where it lives—and builds a precise dependency graph in real-time.
 
-The result is an API that is not only more powerful but also simpler and more intuitive, especially when it comes to
-changing state. The provider does what you would expect, automatically handling complex scenarios like deep merging.
+The result is an API that is not only more powerful but also simpler and more intuitive, especially when it comes to changing state. The provider does what you would expect, automatically handling complex scenarios like deep merging.
 
-Where the magic truly begins is in how you *change* that data. Thanks to the new deep, proxy-based reactivity system,
-you can modify state with plain JavaScript assignments. It's as simple as it gets:
+Where the magic truly begins is in how you *change* that data. Thanks to the new deep, proxy-based reactivity system, you can modify state with plain JavaScript assignments. It's as simple as it gets:
 
-```javascript readonly
+```javascript
 // Get the provider and change the data directly
 const provider = myComponent.getStateProvider();
 
@@ -118,14 +94,11 @@ class MainView extends Container {
 }
 MainView = Neo.setupClass(MainView);
 ```
-Notice the "Change First Name" button. It calls `setState` with an object that only contains `firstName`. The v10 provider
-is smart enough to perform a deep merge, updating `firstName` while leaving `lastName` untouched. This prevents accidental
-data loss and makes state updates safe and predictable by default.
+Notice the "Change First Name" button. It calls `setState` with an object that only contains `firstName`. The v10 provider is smart enough to perform a deep merge, updating `firstName` while leaving `lastName` untouched. This prevents accidental data loss and makes state updates safe and predictable by default.
 
-### 3. The Power of Formulas: Derived State Made Easy
+### The Power of Formulas: Derived State Made Easy
 
-Because the provider is built on `Neo.core.Effect`, creating computed properties ("formulas") is a native, first-class
-feature. You define them in a separate `formulas` config, and the provider automatically keeps them updated.
+Because the provider is built on `Neo.core.Effect`, creating computed properties ("formulas") is a native, first-class feature. You define them in a separate `formulas` config, and the provider automatically keeps them updated.
 
 ```javascript live-preview
 import Container from 'neo.mjs/src/container/Base.mjs';
@@ -170,13 +143,11 @@ class MainView extends Container {
 }
 MainView = Neo.setupClass(MainView);
 ```
-When you edit the text fields, the `setState` call updates the base `user` data. The `Effect` system detects this,
-automatically re-runs the `fullName` formula, and updates the welcome label.
+When you edit the text fields, the `setState` call updates the base `user` data. The `Effect` system detects this, automatically re-runs the `fullName` formula, and updates the welcome label.
 
-### 4. Formulas Across Hierarchies
+### Formulas Across Hierarchies
 
-The true power of the hierarchical system is revealed when formulas in a child provider can seamlessly use data from a
-parent. This allows you to create powerful, scoped calculations that still react to global application state.
+The true power of the hierarchical system is revealed when formulas in a child provider can seamlessly use data from a parent. This allows you to create powerful, scoped calculations that still react to global application state.
 
 ```javascript live-preview
 import Button    from 'neo.mjs/src/button/Base.mjs';
@@ -237,14 +208,11 @@ class MainView extends Container {
 }
 MainView = Neo.setupClass(MainView);
 ```
-In this example, the child provider's `totalPrice` formula depends on its own local `price` and the parent's `taxRate`.
-Clicking either button triggers the correct reactive update, and the total price is always in sync. This demonstrates
-the effortless composition of state across different parts of your application.
+In this example, the child provider's `totalPrice` formula depends on its own local `price` and the parent's `taxRate`. Clicking either button triggers the correct reactive update, and the total price is always in sync. This demonstrates the effortless composition of state across different parts of your application.
 
-### 5. Hierarchical by Design: Nested Providers That Just Work
+### Hierarchical by Design: Nested Providers That Just Work
 
-The v10 provider was engineered to handle different scopes of state with an intelligent hierarchical model. A child
-component can seamlessly access data from its own provider as well as any parent provider.
+The v10 provider was engineered to handle different scopes of state with an intelligent hierarchical model. A child component can seamlessly access data from its own provider as well as any parent provider.
 
 ```javascript live-preview
 import Container from 'neo.mjs/src/container/Base.mjs';
@@ -277,13 +245,11 @@ class MainView extends Container {
 }
 MainView = Neo.setupClass(MainView);
 ```
-The nested component can access both `user` from its local provider and `theme` from the parent provider without any
-extra configuration.
+The nested component can access both `user` from its local provider and `theme` from the parent provider without any extra configuration.
 
-### 5. The Final Piece: State Providers in Functional Components
+### State Providers in Functional Components
 
-Thanks to the v10 refactoring, state providers are now a first-class citizen in functional components. You can define a
-provider and bind to its data with the same power and simplicity as in class-based components.
+Thanks to the v10 refactoring, state providers are now a first-class citizen in functional components. You can define a provider and bind to its data with the same power and simplicity as in class-based components.
 
 ```javascript live-preview
 import {defineComponent} from 'neo.mjs';
@@ -331,82 +297,21 @@ export default defineComponent({
 This example demonstrates the full power of the new architecture: a functional component with its own reactive data,
 computed properties, and two-way bindings, all with clean, declarative code.
 
-### 6. From Theory to Practice: The Comprehensive Guide
-
-The examples above show the clean, intuitive API. For a complete, hands-on exploration with dozens of live-preview
-examples covering everything from nested providers and formulas to advanced store management, we encourage you to
-explore our comprehensive guide. The rest of this article will focus on the deep architectural advantages that make
-this system possible.
-
-**[Read the Full State Providers Guide Here](../guides/datahandling/StateProviders.md)**
-
-### 7. Under the Hood Part 1: The Proxy's Magic
-
-The beautiful API above is powered by a sophisticated proxy created by `Neo.state.createHierarchicalDataProxy`.
-When you interact with `provider.data`, you're not touching a plain object; you're interacting with an intelligent agent
-that works with Neo's `EffectManager`.
-
-You can see the full implementation in
-**[src/state/createHierarchicalDataProxy.mjs](../../src/state/createHierarchicalDataProxy.mjs)**.
-
-Here’s how it works:
-
-1.  **The `get` Trap:** When your binding function (`data => data.user.firstname`) runs for the first time, it accesses
-    properties on the proxy. The proxy's `get` trap intercepts these reads and tells the `EffectManager`,
-    "The currently running effect depends on the `user.firstname` config." This builds a dependency graph automatically.
-2.  **The `set` Trap:** When you write `provider.data.user.firstname = 'Max'`, the proxy's `set` trap intercepts the
-    assignment. It then calls the provider's internal `setData('user.firstname', 'Max')` method, which triggers the
-    reactivity system to re-run only the effects that depend on that specific property.
-
-This proxy is the bridge between a simple developer experience and a powerful, fine-grained reactive engine.
+### Under the Hood: The Proxy and "Reactivity Bubbling"
 
-### 8. Under the Hood Part 2: The "Reactivity Bubbling" Killer Feature
+The beautiful API above is powered by a sophisticated proxy created by `Neo.state.createHierarchicalDataProxy`. When you
+interact with `provider.data`, you're not touching a plain object; you're interacting with an intelligent agent that
+works with Neo's `EffectManager`.
 
-This is where the Neo.mjs `state.Provider` truly shines and solves the "Context Tax." Consider this critical question:
+1.  **The `get` Trap:** When your binding function runs, the proxy's `get` trap intercepts these reads and tells the
+    `EffectManager`, "The currently running effect depends on this property." This builds a dependency graph automatically.
+2.  **The `set` Trap:** When you write `provider.data.user.firstname = 'Max'`, the proxy's `set` trap intercepts the assignment.
+    It then calls the provider's internal `setData()` method, which triggers the reactivity system to re-run only the
+    effects that depend on that specific property.
 
-> "What happens if a component is bound to the entire `data.user` object, and we only change `data.user.name`?"
-
-In many systems, this would not trigger an update, because the reference to the `user` object itself hasn't changed.
-This is a common "gotcha" that forces developers into complex workarounds.
-
-Neo.mjs handles this intuitively with a feature we call **"reactivity bubbling."** A change to a leaf property is
-correctly perceived as a change to its parent.
-
-We don't just claim this works; we prove it. Our test suite for this exact behavior,
-**[test/siesta/tests/state/ProviderNestedDataConfigs.mjs](../../test/siesta/tests/state/ProviderNestedDataConfigs.mjs)**,
-demonstrates this with concrete assertions.
-
-Here’s a simplified version of the test:
-
-```javascript
-// From test/siesta/tests/state/ProviderNestedDataConfigs.mjs
-t.it('State Provider should trigger parent effects when a leaf node changes (bubbling)', t => {
-    let effectRunCount = 0;
-
-    const component = Neo.create(MockComponent, {
-        stateProvider: { data: { user: { name: 'John', age: 30 } } }
-    });
-    const provider = component.getStateProvider();
-
-    // This binding depends on the 'user' object itself.
-    provider.createBinding(component.id, 'user', data => {
-        effectRunCount++;
-        return data.user;
-    });
-
-    t.is(effectRunCount, 1, 'Effect should run once initially');
-
-    // Change a leaf property.
-    provider.setData('user.age', 31);
-
-    // Assert that the effect depending on the PARENT object re-ran.
-    t.is(effectRunCount, 2, 'Effect should re-run after changing a leaf property');
-});
-```
-This behavior is made possible by the `internalSetData` method in **[state/Provider.mjs](../../src/state/Provider.mjs)**.
-When you set `'user.age'`, the provider doesn't just update that one value. It then "bubbles up," creating a new `user`
-object reference that incorporates the change: `{...oldUser, age: 31}`. This new object reference is what the reactivity
-system detects, ensuring that any component bound to `user` updates correctly.
+This proxy is the bridge between a simple developer experience and a powerful, fine-grained reactive engine. It also
+enables a key feature we call **"reactivity bubbling."** A change to a leaf property (e.g., `user.name`) is correctly
+perceived as a change to its parent (`user`), ensuring that components bound to the parent object update as expected.
 
 ### Conclusion: Reactivity at the Core
 
@@ -427,6 +332,6 @@ This is what a ground-up reactive system enables, and it's a cornerstone of the
 
 1. [A Frontend Love Story: Why the Strategies of Today Won't Build the Apps of Tomorrow](./v10-post1-love-story.md)
 2. [Deep Dive: Named vs. Anonymous State - A New Era of Component Reactivity](./v10-deep-dive-reactivity.md)
-3. [Beyond Hooks: A New Breed of Functional Components for a Multi-Threaded World](./v10-deep-dive-functional-components.md)
-4. [Deep Dive: The VDOM Revolution - JSON Blueprints & Asymmetric Rendering](./v10-deep-dive-vdom-revolution.md)
-5. Deep Dive: The State Provider Revolution
+3. [Designing Functional Components for a Multi-Threaded World](./v10-deep-dive-functional-components.md)
+4. [The VDOM Revolution: How We Render UIs from a Web Worker](./v10-deep-dive-vdom-revolution.md)
+5. Designing a State Manager for Performance: A Deep Dive into Hierarchical Reactivity