neo.mjs 10.0.0-beta.6 → 10.0.1

package/learn/blog/v10-post1-love-story.md

@@ -0,0 +1,383 @@
+# A Frontend Love Story: Why the Strategies of Today Won't Build the Apps of Tomorrow
+
+If you’re a frontend developer in 2025, you are a survivor. You’ve mastered a craft that exists in a state of constant,
+churning evolution. You embraced the power of declarative UIs, celebrated the elegance of modern component models, and
+learned to build entire worlds inside a browser tab. It was, for a time, a kind of honeymoon. We were in love with what
+we could create.
+
+But honeymoons end. And for many of us, the love story has become strained. The passion is still there, but it’s buried
+under layers of accumulated complexity, performance anxiety, and the nagging feeling that we’re spending more time fighting
+our tools than building the ambitious applications we dream of.
+
+This isn’t just a story about the pain of frontend development. It’s a story about a false choice we’ve been forced into
+a choice between two flawed paradigms that are holding us back from building the future.
+
+*(Part 1 of 5 in the v10 blog series. Details at the bottom.)*
+
+---
+
+## Part 1: The Client-Side Heartbreak - A War on a Single Front
+
+Our first love was the interactive, client-side application. We were promised a world of rich, stateful experiences that
+felt like native desktop software, running entirely in the browser. But as our ambitions grew, so did the heartbreak.
+The very architecture that gave us this power became our cage.
+
+### The Tyranny of the Main Thread
+
+The core philosophy of a truly performant system should be that *"the browser's main thread must be treated like a
+neurosurgeon: only perform precise, scheduled operations with zero distractions."*
+
+Mainstream frameworks do the opposite. They treat the main thread like a frantic, overworked general practitioner.
+We ask this single, precious resource to be a world-class UI renderer, a high-performance JavaScript VM, a sophisticated
+layout engine, and a millisecond-responsive event handler—all at the same time.
+
+The result is a constant, low-grade war for milliseconds. Every developer knows the feeling in their gut: the janky
+scroll as a list virtualizer struggles to keep up; the button that feels "stuck" because a complex component is rendering;
+the entire UI freezing during a heavy data calculation.
+
+This isn't just a technical failure; it's a breach of trust with the user. Every stutter and freeze erodes their confidence
+in our creations.
+
+### Death by a Thousand Optimizations
+
+To compensate for this architectural flaw, we've been given a toolbox of manual overrides. In the React world, this is
+the "memoization tax." In other frameworks, it might be manual change detection strategies or complex observable setups.
+
+The result is the same: you, the developer, are forced to write extra code to prevent the framework from doing unnecessary work.
+
+This tax is most obvious when looking at a "performant" component side-by-side with one that is performant by design.
+
+<center>
+<table>
+<tr>
+<th>A "Performant" React Component</th>
+<th>The Neo.mjs Equivalent</th>
+</tr>
+<tr>
+<td>
+
+```javascript
+import {useState, useMemo} from 'react';
+
+// A typical "optimized" React component
+const MyComponent = React.memo(({ user }) => {
+    // This will only log when the component *actually* re-renders
+    console.log('Rendering MyComponent');
+    return <div>{user.name}</div>;
+});
+
+const App = () => {
+    const [count, setCount] = useState(0);
+
+    // We must wrap this in useMemo...
+    const user = useMemo(() => ({ name: 'John Doe' }), []);
+
+    // ...to prevent MyComponent from re-rendering
+    // every time the App's state changes.
+    return (
+        <div>
+            <button onClick={() => setCount(c => c + 1)}>
+                App Clicks: {count}
+            </button>
+            <MyComponent user={user} />
+        </div>
+    );
+};
+```
+
+</td>
+<td>
+
+```javascript
+import {defineComponent, useConfig} from 'neo.mjs/src/functional/_export.mjs';
+
+const MyComponent = defineComponent({
+    // The user config is passed in from the parent
+    createVdom({user}) {
+        // This will only log when the component *actually* re-renders
+        console.log('Rendering MyComponent');
+        return {text: user.name};
+    }
+});
+
+export default defineComponent({
+    createVdom() {
+        const [count, setCount] = useConfig(0);
+        // By using useConfig, the user object is stable across re-renders
+        const [user]            = useConfig({name: 'John Doe'});
+
+        return {
+            cn: [{
+                tag    : 'button',
+                text   : `App Clicks: ${count}`,
+                handler: () => setCount(prev => prev + 1)
+            }, {
+                module: MyComponent,
+                // Pass the stable user object to the child
+                user
+            }]
+        }
+    }
+});
+```
+
+</td>
+</tr>
+</table>
+</center>
+
+At first glance, the Neo.mjs syntax might seem more verbose than JSX. That's a deliberate design choice.
+Instead of a custom syntax that requires transpilation, Neo.mjs uses plain, structured JavaScript objects to define the UI.
+This makes the code more explicit, eliminates a build step, and creates a blueprint that is incredibly easy for LMMs/AIs
+to read and manipulate.
+
+Because the core is pure JavaScript, it also opens the door for optional, more familiar syntaxes
+based on [Template Literals](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals) in the
+future, should the community desire it. The real story, however, isn't the syntax, but the outcome:
+the elimination of the memoization tax.
+
+This isn't an advanced optimization strategy; it's a tedious, mandatory chore. It's a tax on our time and a cage for our
+creativity. We spend a significant portion of our development cycle simply preventing the framework from doing unnecessary
+work, a task that the framework should be doing for us.
+
+One of the core goals for Neo.mjs v10 was to 'meet developers where they are,' making the framework more approachable
+with familiar patterns.
+
+While the syntax for these functional components might feel familiar, it's crucial to understand that this familiarity
+is just the tip of the iceberg. There is a LOT more to it.
+
+### The State Management Labyrinth
+
+Nowhere is this pain more acute than when building a truly complex, stateful UI. Forget a simple login form. Imagine a
+common enterprise requirement: a massive, multi-page, drag-and-drop form generator for a government agency, with 300+ fields,
+conditional logic, and real-time validation.
+
+How do we even begin to build this in a single-threaded world?
+
+The state management alone is a paralyzing choice.
+
+Do we use hundreds of local state hooks and create a component tree
+so riddled with props-drilling that it becomes unmanageable? Or do we build a monolithic state object in a global store,
+only to find that every keystroke triggers a performance-killing update across the entire application?
+
+We reach for heroic third-party libraries—each a brilliant solution to a problem that, if we're being honest, shouldn't
+be this hard in the first place. The simple act of building a form, a fundamental building block of the web, has become
+an architectural nightmare.
+
+In Neo.mjs, forms are powerful, self-contained state managers. Each `FormContainer` inherently manages the data for its
+fields, building a hierarchical data object based on field `name` attributes. This simplifies data collection, validation,
+and even supports complex nested structures and lazy-loaded sections **without requiring an external state provider**.
+While forms can seamlessly integrate with the framework's state providers for broader application-level data sharing,
+their core functionality for managing form data is self-sufficient.
+
+---
+
+## Part 2: The Server-Side Mirage - A Different Kind of Heartbreak
+
+The industry saw this pain and offered a solution: "The client is too slow! Let's move rendering to the server with
+Server-Side Rendering (SSR)." Frameworks like Next.js and SvelteKit promised to solve our problems by delivering
+fast-loading, pre-rendered HTML.
+
+And for a certain class of website, it was a revelation. Blogs, marketing sites, and e-commerce storefronts have never
+been faster. SSR is a brilliant strategy for delivering *content*.
+
+But it is a poor strategy for building *applications*.
+
+The promise of SSR quickly becomes a mirage when confronted with the applications we truly want to build.
+
+How do you build a multi-window IDE, where a user can drag a component from one screen to another,
+when the server's job is to send you static HTML? How do you manage the persistent, real-time state of a financial trading
+dashboard when every update requires a round trip to a serverless function?
+
+You can't. You end up with a clunky hybrid, where the dream of a fluid, native-like web app dies, caught between a slow
+client and an inflexible server. The server can't possibly know the intricate, second-by-second state of a complex user
+interface, and the client is left trying to hydrate static markup into a living, breathing application.
+
+SSR isn't a solution to the problem of application complexity; it's an elegant retreat from it.
+
+---
+
+## Part 3: The Architectural Epiphany - The Third Way
+
+We've been trapped in a false choice: a client-side app that's a nightmare to scale, or a server-side site that can't
+handle true interactivity. Neither of these paths leads to the future we were promised.
+
+The entire client vs. server debate is a distraction. The answer isn't about *where* you render, but *how* your entire
+application is architected.
+
+The only real solution is to **escape the main thread entirely.**
+
+This is the architectural epiphany that powers Neo.mjs. It’s a framework built on a simple, powerful idea: your
+application should not live on the main thread. It should live in a Web Worker.
+
+By moving the entire application—the component tree, the state management, and the business logic—into a dedicated App Worker,
+we liberate the main thread to do what it does best: paint pixels. The result is a level of performance and responsiveness
+that single-threaded frameworks can only dream of.
+
+That 300-field form generator that was an architectural nightmare? In Neo.mjs, it's trivial. The form's state and
+validation logic live in the worker, completely decoupled from the DOM. The main thread only ever receives the minimal
+set of changes required to update the view. The UI remains fluid and responsive, even with hundreds of fields, because
+it is architecturally impossible for the application logic to block it.
+
+This isn't a workaround. It's a new paradigm.
+
+---
+
+## Part 4: The AI Revelation - The Framework for the Next Generation
+
+This architectural shift doesn't just solve the problems of today; it unlocks the possibilities of tomorrow. The next
+great leap in software development is upon us: the rise of AI as a co-developer and a core part of the user experience.
+And this new reality exposes the flaws of our current tools in a new and unforgiving light.
+
+Neo.mjs is uniquely positioned as **The Framework For and By AI.**
+
+### The Framework FOR AI: Building the Cockpit
+
+Interacting with powerful AI models requires more than a simple chat window. It requires a cockpit. A multi-window,
+IDE-like environment where a user can write a prompt in one window, see the AI's reasoning in a second, view the
+generated code in a third, and see a live preview in a fourth.
+
+This is impossible with traditional frameworks.
+
+But it's native to Neo.mjs. Its multi-threaded, multi-window architecture
+is the perfect foundation for building the complex, data-intensive UIs that the AI era demands.
+
+### The Framework BY AI: Speaking the Right Language
+
+AIs are now writing frontend code. But we are asking them to write JSX or other template syntaxes—a mix of HTML and
+JavaScript that is verbose, error-prone, and fundamentally human-centric.
+
+AIs don't think in JSX. They think in structured data. They think in JSON.
+
+Neo.mjs is built on the language of AI. It uses **declarative JSON blueprints** to define UI. An AI generating a JSON
+blueprint is an order of magnitude simpler, faster, and more reliable than an AI generating JSX. The framework's
+`DomApiRenderer` then takes this simple blueprint and translates it into hyper-performant, secure DOM operations.
+The AI doesn't need to know *how* to build the UI; it just needs to describe *what* the UI is.
+
+Beyond the architectural innovations, a significant effort has been invested in making the Neo.mjs codebase inherently
+understandable for AI. Through countless dedicated sessions, we've meticulously added intent-driven comments to core
+files (like `src/core/Config.mjs`), ensuring that when Large Language Models are pointed to relevant source code, they
+can easily grasp the underlying logic and design. This commitment to AI-readability is a testament to Neo.mjs truly
+being a 'Framework For and By AI,' designed for the future of collaborative development.
+
+---
+
+## Your Invitation to a New Way of Building
+
+This brings us to today. **Neo.mjs v10 is not an upgrade—it's a new operating system for the web.** It is the culmination
+of years of architectural pioneering, refined into a cohesive and powerful whole. It is the realization of the "third way."
+
+**Quick Project Overview**
+
+Neo.mjs is a pioneering multi-threaded JavaScript framework that redefines web development. Leveraging an Off-Main-Thread
+(OMT) architecture, it delivers unparalleled performance and scalability for complex applications, enabling desktop-class
+multi-window experiences with advanced features like shared state and component persistence, and a zero-builds development
+workflow. Its unified class config system provides a consistent, declarative approach to building UIs, managing data, and
+orchestrating application logic, ensuring linear scalability even for the most intricate projects.
+
+---
+
+We've rebuilt our core, created a new functional component model, and revolutionized our rendering engine. But you don't
+have to take our word for it. We invite you to explore for yourself.
+
+### Choose Your Own Adventure:
+
+*   **I'm skeptical. Show me the code.**
+    Dive into our collection of 74 live, interactive examples. See the code, edit it in real-time, and witness the
+    performance for yourself. No setup required. Many more demo apps can get navigated to from here.
+    <br>
+    **[=> Explore the Examples Portal](https://neomjs.com/dist/esm/apps/portal/#/home)**
+
+*   **I'm intrigued. How does it actually work?**
+    This article is the first in a five-part series that goes deep into the architecture of v10. Start with our deep
+    dive on the new reactivity system that makes manual optimizations a thing of the past.
+    <br>
+    **[=> Next Article: Deep Dive into the Two-Tier Reactivity System](./v10-deep-dive-reactivity.md)**
+
+*   **I'm ready to build. What's the "Hello World"?**
+    Our `create-app` script will have you running your first multi-threaded application in under a minute. Experience
+    the difference firsthand.
+    <br>
+    `npx neo-app@latest`
+
+---
+
+## Conclusion: Fall in Love with Frontend Again
+
+For too long, we have accepted the limitations of our tools. We have patched the symptoms, paid the performance tax,
+and lowered our ambitions. We have forgotten the initial joy of building for the web—the thrill of creating something
+new, powerful, and beautiful.
+
+Neo.mjs v10 is an invitation to rediscover that passion. It's a framework built on the belief that you shouldn't have
+to choose between performance and interactivity, between a powerful developer experience and an ambitious user experience.
+
+It's time to stop fighting the main thread. It's time to stop paying the performance tax. It's time to start building
+the applications of the future.
+
+It's time to fall in love with frontend again.
+
+---
+
+## The Neo.mjs v10 Blog Post Series
+
+1. A Frontend Love Story: Why the Strategies of Today Won't Build the Apps of Tomorrow
+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](./v10-deep-dive-state-provider.md)
+
+---
+
+## A Personal Note from the Author
+
+Neo.mjs is one of Europe's biggest Open Source Projects, using the MIT license.</br>
+Meaning: The entire code base, as well as all demo apps and examples, are **free to use**.
+
+To put the magnitude of the project in numbers:
+
+**Number of files:**
+* `/src` 303
+* `/apps` 260
+* `/examples` 471 (105 executable example apps)
+* `/test` 48
+* `/resources` 420
+
+We are talking about **22,000+** commits inside the ecosystem, and **5000+** closed tickets.
+**770** passing unit tests.
+
+While the Blog Post Series goes deep into the heart of the v10 core changes, they are barely touching the surface
+of the entire project. We are talking about a `Buffered Grid` on AG Grid level, Multi-Window IDEs directly included
+inside the Neo.mjs Website, a fully functional `Calendar` app, a vast component library, and more.
+
+While Neo.mjs made it into the Top5 of "The most exciting use of technology in 2021" of the OS Awards Program,
+it is fair to say that the framework is an underdog. Maybe the most underrated framework in the history of
+frontend development.
+
+I encourage you to take a deeper dive into the code base and examples. You will find countless hidden gems, and
+concepts which would have been worth patents.
+
+Neo.mjs is an Enabler. Using it can give developers wings, and push companies literally years ahead of the competition.
+
+My belief in Neo.mjs's transformative potential led me to dedicate myself fully to its development, stepping away from a
+"Custom Software Engineering Senior Manager" role to bring this vision to life. While the open-source landscape presents
+challenges, we are actively seeking partners and sponsors who share our vision and want to accelerate the future of web development.
+
+There are several exciting enhancements on the horizon for v11+:
+* A Neo.mjs middleware (SEO support, critical rendering paths, backend-connectors, Websocket connections to clients)
+* A multi-window LLM UI
+* A new design and theming system
+* `Template Literls` support, for those who really want it
+* A new version of the Docs App
+* A lot more Learning Section Content
+
+---
+
+Neo.mjs is at a pivotal moment, poised for its next phase of growth. Your engagement is crucial to shaping its future and
+accelerating its impact. Use your chance to influence the project roadmap, let us know what you would love to see next,
+e.g. via opening feature requests. Most importantly, you can help to increase the visibility, to allow the right
+people to find the project. Even with something as simple as a mention on social media.
+
+A huge **"Thank you!"**, to everyone who was involved with reviewing v10 items.
+
+Best regards & happy coding,</br>
+Tobias

package/learn/guides/uibuildingblocks/WorkingWithVDom.md

@@ -29,7 +29,7 @@ Neo.mjs VDom nodes are plain JavaScript objects that represent DOM elements.
     cn       : [],                   // Child nodes array (exclusive with html/text)
     vtype    : 'vnode',              // VNode type: 'vnode', 'text', 'root'
     static   : false,                // Exclude from delta updates (optimization)
-    removeDom: false,                // Hide/show element
+    removeDom: false,                // The recommended way to conditionally render nodes. true removes the element from the DOM while preserving the VDOM structure.
     data     : {custom: 'value'},    // data-* attributes
     // Standard HTML attributes
     disabled: true,
@@ -378,7 +378,31 @@ class DataList extends Component {
 }
 ```
 
-### 3. Complex VDom Transformations (e.g., 3D Animations)
+### 3. Best Practice: Conditional Rendering via `removeDom`
+
+For conditionally showing or hiding elements, the recommended and most robust pattern in Neo.mjs is to use the `removeDom`
+property. This approach ensures **structural integrity** of your VDom tree, which is critical for performance and stability.
+
+By keeping a static VDom structure and toggling the `removeDom` flag, you allow the framework's diffing engine to work
+most efficiently. It can rely on the stable index of each child node, resulting in minimal and correct deltas. This also
+ensures that internal framework features which traverse the VDOM tree (like `syncVdomIds`) function predictably.
+
+#### The Anti-Pattern: Modifying the `cn` Array
+
+Avoid dynamically adding or removing objects from the `cn` array. While it might seem intuitive to build the array based
+on conditions, it leads to a structurally unstable VDom, unless items have their explicitly defined id.
+
+This anti-pattern is problematic because:
+1. It changes the length and indexes of the cn array between renders.
+2. It confuses the diffing algorithm, which can lead to a "delta storm"—a cascade of inefficient and incorrect
+  `removeNode`, `insertNode`, and `moveNode` operations instead of a single, simple update.
+3. It forces the developer to manually add stable ids to all sibling nodes to help the diffing algorithm keep its bearings,
+   which is an extra, error-prone step.
+4. It breaks the contract of a stable VDOM structure, which can interfere with internal framework optimizations.
+
+Always prefer the `removeDom` flag for predictable, performant, and robust components.
+
+### 4. Complex VDom Transformations (e.g., 3D Animations)
 
 For sophisticated UI patterns like 3D visualizations or complex dynamic layouts, you might imperatively calculate and apply VDom properties or even use `Neo.applyDeltas()` for maximum performance.
 

package/package.json

@@ -1,6 +1,6 @@
 {
     "name"           : "neo.mjs",
-    "version"        : "10.0.0-beta.6",
+    "version"        : "10.0.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"     : {
@@ -78,7 +78,7 @@
     },
     "homepage"       : "https://neomjs.com/",
     "devDependencies": {
-        "@fortawesome/fontawesome-free": "^6.7.2",
+        "@fortawesome/fontawesome-free": "^7.0.0",
         "autoprefixer"                 : "^10.4.21",
         "chalk"                        : "^5.4.1",
         "clean-webpack-plugin"         : "^4.0.0",
@@ -88,7 +88,7 @@
         "fs-extra"                     : "^11.3.0",
         "highlightjs-line-numbers.js"  : "^2.9.0",
         "html-minifier-terser"         : "^7.2.0",
-        "inquirer"                     : "^12.7.0",
+        "inquirer"                     : "^12.8.2",
         "marked"                       : "^16.1.1",
         "monaco-editor"                : "0.50.0",
         "neo-jsdoc"                    : "1.0.1",

package/src/DefaultConfig.mjs

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

package/src/Neo.mjs

@@ -372,59 +372,61 @@ If you intended to create custom logic, use the 'beforeGet${Neo.capitalize(key)}
                     const config = this.getConfig(key);
                     if (!config) return;
 
-                    let me                   = this,
-                        oldValue             = config.get(), // Get the old value from the Config instance
-                        {EffectBatchManager} = Neo.core,
-                        isNewBatch           = !EffectBatchManager?.isBatchActive();
+                    let me              = this,
+                        oldValue        = config.get(), // Get the old value from the Config instance
+                        {EffectManager} = Neo.core,
+                        isNewBatch      = !EffectManager?.isPaused();
 
                     // If a config change is not triggered via `core.Base#set()`, honor changes inside hooks.
-                    isNewBatch && EffectBatchManager?.startBatch();
-
-                    // 1. Prevent infinite loops:
-                    // Immediately remove the pending value from the configSymbol to prevent a getter from
-                    // recursively re-triggering this setter.
-                    delete me[configSymbol][key];
-
-                    switch (config.clone) {
-                        case 'deep':
-                            value = Neo.clone(value, true, true);
-                            break;
-                        case 'shallow':
-                            value = Neo.clone(value, false, true);
-                            break;
-                    }
+                    isNewBatch && EffectManager?.pause();
+
+                    try {
+                        // 1. Prevent infinite loops:
+                        // Immediately remove the pending value from the configSymbol to prevent a getter from
+                        // recursively re-triggering this setter.
+                        delete me[configSymbol][key];
+
+                        switch (config.clone) {
+                            case 'deep':
+                                value = Neo.clone(value, true, true);
+                                break;
+                            case 'shallow':
+                                value = Neo.clone(value, false, true);
+                                break;
+                        }
 
-                    // 2. Create a temporary state for beforeSet hooks:
-                    // Set the new value directly on the private backing property. This allows any beforeSet
-                    // hook to access the new value of this and other configs within the same `set()` call.
-                    me[_key] = value;
+                        // 2. Create a temporary state for beforeSet hooks:
+                        // Set the new value directly on the private backing property. This allows any beforeSet
+                        // hook to access the new value of this and other configs within the same `set()` call.
+                        me[_key] = value;
 
-                    if (typeof me[beforeSet] === 'function') {
-                        value = me[beforeSet](value, oldValue);
+                        if (typeof me[beforeSet] === 'function') {
+                            value = me[beforeSet](value, oldValue);
 
-                        // If they don't return a value, that means no change
-                        if (value === undefined) {
-                            // Restore the original value if the update is canceled.
-                            me[_key] = oldValue;
-                            isNewBatch && EffectBatchManager?.endBatch();
-                            return
+                            // If they don't return a value, that means no change
+                            if (value === undefined) {
+                                // Restore the original value if the update is canceled.
+                                me[_key] = oldValue;
+                                return
+                            }
                         }
-                    }
 
-                    // 3. Restore state for change detection:
-                    // Revert the private backing property to its original value. This is crucial for the
-                    // `config.set()` method to correctly detect if the value has actually changed.
-                    me[_key] = oldValue;
-
-                    // 4. Finalize the change:
-                    // The config.set() method performs the final check and, if the value changed,
-                    // triggers afterSet hooks and notifies subscribers.
-                    if (config.set(value)) {
-                        me[afterSet]?.(value, oldValue);
-                        me.afterSetConfig?.(key, value, oldValue)
+                        // 3. Restore state for change detection:
+                        // Revert the private backing property to its original value. This is crucial for the
+                        // `config.set()` method to correctly detect if the value has actually changed.
+                        me[_key] = oldValue;
+
+                        // 4. Finalize the change:
+                        // The config.set() method performs the final check and, if the value changed,
+                        // triggers afterSet hooks and notifies subscribers.
+                        if (config.set(value)) {
+                            me[afterSet]?.(value, oldValue);
+                            me.afterSetConfig?.(key, value, oldValue)
+                        }
+                    } finally {
+                        // End the batch only if this setter started it.
+                        isNewBatch && EffectManager?.resume()
                     }
-
-                    isNewBatch && EffectBatchManager?.endBatch()
                 }
             };