neo.mjs 10.0.0-beta.2 → 10.0.0-beta.3

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -1,45 +1,287 @@
1
1
  ## Introduction
2
2
 
3
- Neo.mjs is class-based, which means you're free to extend any component (or any other Neo.mjs class).
3
+ A major strength of Neo.mjs is its extensive library of components. In most cases, you can build sophisticated
4
+ user interfaces simply by creating configuration objects for these existing components and adding them to a container's
5
+ `items` array. This configuration-driven approach is a significant departure from frameworks like Angular, React, or
6
+ Vue, where creating custom components is a core part of the development workflow.
4
7
 
8
+ However, there are times when you need to create something truly unique or encapsulate a specific set of configurations
9
+ and logic for reuse. In these scenarios, creating a custom component by extending a framework class is the perfect
10
+ solution.
5
11
 
6
- ## Overriding ancestor configs
12
+ This guide will walk you through the process.
7
13
 
8
- ## Introducing new configs
14
+ ## Choosing the Right Base Class
9
15
 
10
- ## Lifecycle config properties
16
+ In the world of React, developers often use Higher-Order Components (HOCs) to reuse component logic. In Neo.mjs, you
17
+ achieve a similar result through class extension. The key to creating a robust and efficient custom component is
18
+ choosing the correct base class to extend.
19
+
20
+ Instead of extending the most generic `Neo.component.Base` class, look for a more specialized class that already
21
+ provides the functionality you need.
22
+
23
+ - If your component needs to contain other components, extend `Neo.container.Base`.
24
+ - If you're creating an interactive element, extending `Neo.button.Base` gives you focus and keyboard support.
25
+ - If you need a custom form field, look for a suitable class within `Neo.form.field`.
26
+
27
+ By choosing the most specific base class, you inherit a rich set of features, saving you from having to reinvent the
28
+ wheel and ensuring your component integrates smoothly into the framework.
29
+
30
+ ## Real-World Examples inside the Neo.mjs Component Library
31
+
32
+ The Neo.mjs framework itself uses this principle of extending the most specific class. Let's look at a couple of
33
+ examples from the framework's source code.
34
+
35
+ ### Toolbar Inheritance
36
+
37
+ - **`Neo.toolbar.Base`** extends `Neo.container.Base`.
38
+ It's the foundational toolbar and extends `Container` because its main purpose is to hold other components. It adds
39
+ features like docking.
40
+
41
+ - **`Neo.tab.header.Toolbar`** extends `Neo.toolbar.Base`.
42
+ This is a specialized toolbar for tab headers. It inherits the ability to hold items and be docked, and adds new
43
+ logic for managing the active tab indicator.
44
+
45
+ - **`Neo.grid.header.Toolbar`** extends `Neo.toolbar.Base`.
46
+ This toolbar is for grid headers. It also inherits from `toolbar.Base` and adds grid-specific features like column
47
+ resizing and reordering.
48
+
49
+ ### Button Inheritance
50
+
51
+ - **`Neo.button.Base`** extends `Neo.component.Base`.
52
+ This is the basic button, providing core features like click handling and icon support.
53
+
54
+ - **`Neo.tab.header.Button`** extends `Neo.button.Base`.
55
+ A button used in tab headers. It inherits all the standard button features and adds a visual indicator for the
56
+ active tab.
57
+
58
+ - **`Neo.grid.header.Button`** extends `Neo.button.Base`.
59
+ A button for grid column headers. It inherits from the base button and adds features for sorting and filtering the
60
+ grid data.
61
+
62
+ These examples show how building on top of specialized base classes leads to a clean, maintainable, and powerful
63
+ component architecture.
64
+
65
+ ## The Role of `Neo.setupClass()` and the Global `Neo` Namespace
66
+
67
+ When you define a class in Neo.mjs and pass it to `Neo.setupClass()`, the framework does more than just process its configurations and apply mixins. A crucial step performed by `Neo.setupClass()` is to **enhance the global `Neo` namespace** with a reference to your newly defined class.
68
+
69
+ This means that after `Neo.setupClass(MyClass)` is executed, your class becomes accessible globally via `Neo.[your.class.name]`, where `[your.class.name]` corresponds to the `className` config you defined (e.g., `Neo.button.Base`, `Neo.form.field.Text`).
70
+
71
+ **Implications for Class Extension and Usage:**
72
+
73
+ * **Global Accessibility**: You can refer to any framework class (or your own custom classes after they've been set up) using their full `Neo` namespace path (e.g., `Neo.button.Base`, `Neo.container.Base`) anywhere in your application code, even without an explicit ES module import for that specific class.
74
+ * **Convenience vs. Best Practice**: While `extends Neo.button.Base` might technically work without an `import Button from '...'`, it is generally **not recommended** for application code. Explicit ES module imports (e.g., `import Button from '../button/Base.mjs';`) are preferred because they:
75
+ * **Improve Readability**: Clearly show the dependencies of your module.
76
+ * **Enhance Tooling**: Enable better static analysis, auto-completion, and refactoring support in modern IDEs.
77
+ * **Ensure Consistency**: Promote a consistent and predictable coding style.
78
+ * **Framework Internal Use**: The global `Neo` namespace is heavily utilized internally by the framework itself for its class registry, dependency resolution, and dynamic instantiation (e.g., when using `ntype` or `module` configs).
79
+
80
+ Understanding this mechanism clarifies how Neo.mjs manages its class system and provides the underlying flexibility for its configuration-driven approach.
81
+
82
+ ## Overriding Ancestor Configs
83
+
84
+ The simplest way to create a custom component is to extend an existing one and override some of its default
85
+ configuration values.
86
+
87
+ Every class in Neo.mjs has a `static config` block where its properties are defined. When you extend a class, you can
88
+ define your own `static config` block and set new default values for any property inherited from an ancestor class.
89
+
90
+ In the example below, we create `MySpecialButton` by extending `Neo.button.Base`. We then override the `iconCls` and
91
+ `ui` configs to create a button with a specific look and feel.
92
+
93
+ ## Introducing New Configs
94
+
95
+ You can also add entirely new configuration properties to your custom components. To make a config "reactive" – meaning
96
+ it automatically triggers a lifecycle method when its value changes – you **must** define it with a trailing underscore (`_`).
97
+
98
+ For a reactive config like `myConfig_`, the framework provides this behavior:
99
+ - **Reading**: You can access the value directly: `this.myConfig`.
100
+ - **Writing**: Assigning a new value (`this.myConfig = 'new value'`) triggers a prototype-based setter. This is the core of Neo.mjs reactivity.
101
+ - **Hooks**: The framework provides three optional hooks for each reactive config: `beforeGet`, `beforeSet`, and `afterSet`. After a value is set, the `afterSetMyConfig(value, oldValue)` method is automatically called.
102
+
103
+ If you define a config without the trailing underscore, it will simply be a static property on the class instance and will not trigger any lifecycle methods.
104
+
105
+ For a complete explanation of the config system, including details on all the lifecycle hooks, please see the [Unified Config System guide](benefits.ConfigSystem).
106
+
107
+ ## Example: A Custom Button
108
+
109
+ Let's look at a practical example. Here, we'll create a custom button that combines the standard `text` config with a new
110
+ `specialText_` config to create a dynamic label.
11
111
 
12
112
  ```javascript live-preview
13
- import Button from '../button/Base.mjs';
14
- // In practice this would be some handy reusable component
113
+ import Button from '../button/Base.mjs';
114
+ import Container from '../container/Base.mjs';
115
+
116
+ // 1. Define our custom component by extending a framework class.
15
117
  class MySpecialButton extends Button {
16
118
  static config = {
17
119
  className: 'Example.view.MySpecialButton',
18
- iconCls : 'far fa-face-grin-wide',
19
- ui : 'ghost'
120
+
121
+ // a. Override configs from the parent class
122
+ iconCls: 'far fa-face-grin-wide',
123
+ ui : 'ghost',
124
+
125
+ // b. Add a new reactive config (note the trailing underscore)
126
+ specialText_: 'I am special'
127
+ }
128
+
129
+ // c. Hook into the component lifecycle
130
+ afterSetSpecialText(value, oldValue) {
131
+ this.updateButtonText()
132
+ }
133
+
134
+ afterSetText(value, oldValue) {
135
+ this.updateButtonText()
136
+ }
137
+
138
+ // d. A custom method to update the button's text
139
+ updateButtonText() {
140
+ const {specialText, text} = this;
141
+ let fullText = `${text} (${specialText})`;
142
+
143
+ // Directly manipulate the VDom text node and update the component
144
+ this.textNode.text = fullText;
145
+ this.update();
20
146
  }
21
147
  }
22
148
 
23
149
  MySpecialButton = Neo.setupClass(MySpecialButton);
24
150
 
25
151
 
26
- import Container from '../container/Base.mjs';
27
-
152
+ // 2. Use the new component in a view.
28
153
  class MainView extends Container {
29
154
  static config = {
30
155
  className: 'Example.view.MainView',
31
- layout : {ntype:'vbox', align:'start'},
156
+ layout : {ntype: 'vbox', align: 'start'},
32
157
  items : [{
158
+ // A standard framework button for comparison
33
159
  module : Button,
34
160
  iconCls: 'fa fa-home',
35
161
  text : 'A framework button'
36
162
  }, {
37
- module : MySpecialButton,
38
- text : 'My special button'
163
+ // Our new custom button
164
+ module : MySpecialButton,
165
+ text : 'My button',
166
+ specialText: 'is very special'
167
+ }]
168
+ }
169
+ }
170
+
171
+ MainView = Neo.setupClass(MainView);
172
+ ```
173
+
174
+ ### Breakdown of the Example:
175
+
176
+ 1. **Class Definition**: We define `MySpecialButton` which `extends` the framework's `Button` class.
177
+ 2. **New Reactive Config**: We add a `specialText_` config. The trailing underscore makes it reactive.
178
+ 3. **Lifecycle Methods**: We implement `afterSetSpecialText()` and override `afterSetText()` to call our custom
179
+ `updateButtonText()` method. Because `afterSet` hooks are called for initial values upon instantiation, this
180
+ ensures the button text is correct from the start and stays in sync.
181
+ 4. **Custom Method**: The `updateButtonText()` method combines the `text` and `specialText` configs and updates the
182
+ `text` property of the button's `textNode` in the VDOM.
183
+ 5. **`this.update()`**: After changing the VDOM, we call `this.update()` to make the framework apply our changes to the
184
+ real DOM.
185
+
186
+ This example shows how you can create a component that encapsulates its own logic and provides a richer, more dynamic
187
+ behavior than a standard component.
188
+
189
+ ## Extending `Component.Base`: Building VDom from Scratch
190
+
191
+ While extending specialized components like `Button` or `Container` is common for adding features (acting like a
192
+ Higher-Order Component), there are times when you need to define a component's HTML structure from the ground up. For
193
+ this, you extend the generic `Neo.component.Base`.
194
+
195
+ When you extend `component.Base`, you are responsible for defining the component's entire virtual DOM (VDom) structure
196
+ using the `vdom` config. This gives you complete control over the rendered output.
197
+
198
+ ### Example: A Simple Profile Badge
199
+
200
+ Let's create a `ProfileBadge` component that displays a user's name and an online status indicator.
201
+
202
+ ```javascript live-preview
203
+ import Component from '../component/Base.mjs';
204
+ import Container from '../container/Base.mjs';
205
+ import NeoArray from '../util/Array.mjs';
206
+ import VdomUtil from '../util/Vdom.mjs';
207
+
208
+ // 1. Extend the generic Component.Base
209
+ class ProfileBadge extends Component {
210
+ static config = {
211
+ className: 'Example.view.ProfileBadge',
212
+ ntype : 'profile-badge',
213
+
214
+ // a. Define the VDom from scratch
215
+ vdom: {
216
+ cls: ['profile-badge'],
217
+ cn : [
218
+ {tag: 'span', cls: ['status-indicator'], flag: 'statusNode'},
219
+ {tag: 'span', cls: ['username'], flag: 'usernameNode'}
220
+ ]
221
+ },
222
+
223
+ // b. Add new reactive configs to control the component (note the trailing underscore)
224
+ online_ : false,
225
+ username_: 'Guest'
226
+ }
227
+
228
+ // d. Define getters for easy access to flagged VDom nodes
229
+ get statusNode() {
230
+ return VdomUtil.getByFlag(this.vdom, 'statusNode')
231
+ }
232
+
233
+ get usernameNode() {
234
+ return VdomUtil.getByFlag(this.vdom, 'usernameNode')
235
+ }
236
+
237
+ // c. Use lifecycle methods to react to config changes
238
+ afterSetOnline(value, oldValue) {
239
+ // Access the VDom node via the getter
240
+ NeoArray.toggle(this.statusNode.cls, 'online', value);
241
+ this.update() // Trigger a VDom update
242
+ }
243
+
244
+ afterSetUsername(value, oldValue) {
245
+ this.usernameNode.text = value;
246
+ this.update()
247
+ }
248
+ }
249
+
250
+ ProfileBadge = Neo.setupClass(ProfileBadge);
251
+
252
+
253
+ // 2. Use the new component
254
+ class MainView extends Container {
255
+ static config = {
256
+ className: 'Example.view.MainView',
257
+ layout : {ntype: 'vbox', align: 'start'},
258
+ items : [{
259
+ module : ProfileBadge,
260
+ username: 'Alice',
261
+ online : true
262
+ }, {
263
+ module : ProfileBadge,
264
+ username: 'Bob',
265
+ online : false,
266
+ style : {marginTop: '10px'}
39
267
  }]
40
268
  }
41
269
  }
42
270
 
43
- Neo.setupClass(MainView);
271
+ MainView= Neo.setupClass(MainView);
44
272
  ```
45
273
 
274
+ ### Key Differences in this Approach:
275
+
276
+ 1. **Base Class**: We extend `Neo.component.Base` because we are not inheriting complex logic like a `Button` or
277
+ `Container`.
278
+ 2. **`vdom` Config**: We define the entire HTML structure inside the `vdom` config. We use `flag`s (`statusNode`,
279
+ `usernameNode`) to easily reference these VDom nodes later.
280
+ 3. **Lifecycle Methods**: We use `afterSet...` methods to react to changes in our custom `online_` and `username_`
281
+ configs. Inside these methods, we directly manipulate the properties of our VDom nodes and then call `this.update()`
282
+ to apply the changes to the real DOM.
283
+
284
+ This approach gives you maximum control, but it also means you are responsible for building the structure yourself.
285
+
286
+ For a deeper dive into advanced VDom manipulation, including performance best practices and security, please refer to the
287
+ [Working with VDom guide](guides.WorkingWithVDom).
@@ -0,0 +1,331 @@
1
+ # Extending Neo Classes
2
+
3
+ Neo.mjs is built upon a robust and consistent class system. Understanding how to extend framework classes is fundamental to building custom functionality, whether you're creating new UI components, defining data structures, or implementing application logic.
4
+
5
+ This guide covers the universal principles of class extension in Neo.mjs, which apply across all class types, not just UI components.
6
+
7
+ ## 1. The `static config` Block: Defining Properties
8
+
9
+ Every Neo.mjs class utilizes a `static config` block. This is where you define the properties that instances of your class will possess. These properties can be simple values, objects, or even other Neo.mjs class configurations.
10
+
11
+ ```javascript readonly
12
+ class MyBaseClass extends Neo.core.Base {
13
+ static config = {
14
+ className: 'My.Base.Class', // Unique identifier for the class
15
+ myString : 'Hello',
16
+ myNumber : 123
17
+ }
18
+ }
19
+
20
+ export default Neo.setupClass(MyBaseClass);
21
+ ```
22
+
23
+ Common configs you'll encounter include `className` (a unique string identifier for your class) and `ntype` (a shorthand alias for component creation).
24
+
25
+ ## 2. Reactive Configs: The Trailing Underscore (`_`)
26
+
27
+ A cornerstone of Neo.mjs's reactivity is the trailing underscore (`_`) convention for configs defined in `static config`. When you append an underscore to a config name (e.g., `myConfig_`), the framework automatically generates a reactive getter and setter for it.
28
+
29
+ ```javascript readonly
30
+ class MyReactiveClass extends Neo.core.Base {
31
+ static config = {
32
+ className : 'My.Reactive.Class',
33
+ myReactiveConfig_: 'initial value' // This config is reactive
34
+ }
35
+
36
+ onConstructed() {
37
+ super.onConstructed();
38
+ console.log(this.myReactiveConfig); // Accesses the getter
39
+ this.myReactiveConfig = 'new value'; // Triggers the setter
40
+ }
41
+ }
42
+
43
+ export default Neo.setupClass(MyReactiveClass);
44
+ ```
45
+
46
+ Assigning a new value to a reactive property (e.g., `this.myReactiveProp = 'new value'`) triggers its setter, which in turn can invoke lifecycle hooks, enabling automatic updates and side effects. Properties without the underscore are static and do not trigger this reactive behavior.
47
+
48
+ ## 3. Configuration Lifecycle Hooks (`beforeSet`, `afterSet`, `beforeGet`)
49
+
50
+ For every reactive config (`myConfig_`), Neo.mjs provides three optional lifecycle hooks that you can implement in your class. These methods are automatically called by the framework during the config's lifecycle, offering powerful interception points:
51
+
52
+ * **`beforeSetMyConfig(value, oldValue)`**:
53
+ * **Purpose**: Intercepts the value *before* it is set. Ideal for validation, type coercion, or transforming the incoming value.
54
+ * **Return Value**: Return the (potentially modified) `value` that should be set. Returning `undefined` or `null` will prevent the value from being set.
55
+
56
+ * **`afterSetMyConfig(value, oldValue)`**:
57
+ * **Purpose**: Executed *after* the value has been successfully set. Ideal for triggering side effects, updating the UI (e.g., calling `this.update()` for components), or firing events.
58
+ * **Return Value**: None.
59
+
60
+ * **`beforeGetMyConfig(value)`**:
61
+ * **Purpose**: Intercepts the value *before* it is returned by the getter. Useful for lazy initialization, computing values on demand, or returning a transformed version of the stored value.
62
+ * **Return Value**: Return the `value` that should be returned by the getter.
63
+
64
+ ### Overriding Lifecycle Hooks: `super` vs. Full Override
65
+
66
+ When extending a Neo.mjs class, you often need to customize the behavior of inherited lifecycle hooks (like `afterSet*`, `onConstructed`, etc.). You have two primary approaches:
67
+
68
+ #### 1. Extending Parent Behavior (Calling `super`)
69
+
70
+ This is the most common and recommended approach. By calling `super.methodName(...)`, you ensure that the parent class's implementation of the hook is executed. You can then add your custom logic either before or after the `super` call.
71
+
72
+ This approach is crucial for maintaining the framework's intended behavior and ensuring that inherited features continue to function correctly.
73
+
74
+ ```javascript readonly
75
+ import Button from '../../src/button/Base.mjs';
76
+
77
+ class MyExtendedButton extends Button {
78
+ static config = {
79
+ className: 'My.Extended.Component',
80
+ // text_ config is inherited from Button.Base
81
+ // We can set a default value here if needed, or rely on button.Base's default
82
+ text: 'New Default Text'
83
+ }
84
+
85
+ // Example: Adding logic after the parent's afterSetText
86
+ afterSetText(value, oldValue) {
87
+ // Add your custom pre-processing logic here
88
+ super.afterSetText(value, oldValue);
89
+ console.log(`Custom logic: Button text changed to "${value}"`);
90
+ // Add your custom post-processing logic here
91
+ }
92
+ }
93
+
94
+ export default Neo.setupClass(MyExtendedButton);
95
+ ```
96
+
97
+ #### 2. Completely Overriding Parent Behavior (No `super` Call)
98
+
99
+ In rare cases, you might want to completely replace the parent class's implementation of a hook. This is achieved by simply omitting the `super` call within your overridden method.
100
+
101
+ **Caution**: Use this approach with extreme care. You must fully understand the parent's implementation and ensure that your override does not break essential framework functionality or inherited features. This is generally reserved for advanced scenarios where you need full control over the hook's execution.
102
+
103
+ ```javascript readonly
104
+ import Button from '../../src/button/Base.mjs';
105
+
106
+ class MyFullyOverriddenButton extends Button {
107
+ static config = {
108
+ className: 'My.Fully.Overridden.Component',
109
+ text : 'New Default Text'
110
+ }
111
+
112
+ // Example: Completely overriding afterSetText
113
+ afterSetText(value, oldValue) {
114
+ // No super.afterSetText(value, oldValue); call
115
+ console.log(`Fully custom logic: Button text changed to "${value}"`);
116
+ // The parent's afterSetText will NOT be executed
117
+ // This means that in this case you need to take care on your own to map the text value to the vdom.
118
+ }
119
+ }
120
+
121
+ export default Neo.setupClass(MyFullyOverriddenButton);
122
+ ```
123
+
124
+
125
+
126
+ ```javascript readonly
127
+ class MyHookedClass extends Neo.core.Base {
128
+ static config = {
129
+ className: 'My.Hooked.Class',
130
+ myValue_ : 0
131
+ }
132
+
133
+ beforeSetMyValue(value, oldValue) {
134
+ if (typeof value !== 'number' || value < 0) {
135
+ console.warn('myValue must be a non-negative number!');
136
+ return 0; // Default to 0 if invalid
137
+ }
138
+ return value;
139
+ }
140
+
141
+ afterSetMyValue(value, oldValue) {
142
+ console.log(`myValue changed from ${oldValue} to ${value}`);
143
+ // In a component, you might call this.update() here
144
+ }
145
+
146
+ beforeGetMyValue(value) {
147
+ // Example: lazy initialization or computed value
148
+ if (value === 0 && !this._initialized) {
149
+ console.log('Initializing myValue on first access');
150
+ this._initialized = true;
151
+ return 10; // Return a default initial value
152
+ }
153
+ return value;
154
+ }
155
+ }
156
+
157
+ export default Neo.setupClass(MyHookedClass);
158
+ ```
159
+
160
+ ## 4. The Role of `Neo.setupClass()` and the Global `Neo` Namespace
161
+
162
+ When you define a class in Neo.mjs and pass it to `Neo.setupClass()`, the framework performs several crucial operations. One of the most significant is to **enhance the global `Neo` namespace** with a reference to your newly defined class.
163
+
164
+ This means that after `Neo.setupClass(MyClass)` is executed, your class becomes accessible globally via `Neo.[your.class.name]`, where `[your.class.name]` corresponds to the `className` config you defined (e.g., `Neo.button.Base`, `Neo.form.field.Text`, or your custom `My.Custom.Class`).
165
+
166
+ **Implications for Class Extension and Usage:**
167
+
168
+ * **Global Accessibility**: You can refer to any framework class (or your own custom classes after they've been set up) using their full `Neo` namespace path (e.g., `Neo.button.Base`, `Neo.container.Base`) anywhere in your application code, even without an explicit ES module import for that specific class.
169
+ * **Convenience vs. Best Practice**: While `extends Neo.button.Base` might technically work without an `import Button from '...'`, it is generally **not recommended** for application code. Explicit ES module imports (e.g., `import Button from '../button/Base.mjs';`) are preferred because they:
170
+ * **Improve Readability**: Clearly show the dependencies of your module.
171
+ * **Enhance Tooling**: Enable better static analysis, auto-completion, and refactoring support in modern IDEs.
172
+ * **Ensure Consistency**: Promote a consistent and predictable coding style.
173
+ * **Framework Internal Use**: The global `Neo` namespace is heavily utilized internally by the framework itself for its class registry, dependency resolution, and dynamic instantiation (e.g., when using `ntype` or `module` configs).
174
+
175
+ Understanding this mechanism clarifies how Neo.mjs manages its class system and provides the underlying flexibility for its configuration-driven approach.
176
+
177
+ ## 5. Practical Examples: Models, Stores, and Controllers
178
+
179
+ The principles of class extension apply universally across all Neo.mjs class types.
180
+
181
+ ### Extending `Neo.data.Model`
182
+
183
+ Models define the structure and behavior of individual data records. While reactive configs can be used for class-level properties of a Model (e.g., a global setting for all products), properties that vary per record (like `price` or `discount`) should be defined as fields within the `fields` array. Neo.mjs provides `convert` and `calculate` functions directly on field definitions for per-record logic.
184
+
185
+ ```javascript readonly
186
+ import Model from '../../src/data/Model.mjs';
187
+
188
+ class ProductModel extends Model {
189
+ static config = {
190
+ className: 'App.model.Product',
191
+ fields: [
192
+ {name: 'id', type: 'Number'},
193
+ {name: 'name', type: 'String'},
194
+ {name: 'price', type: 'Number', defaultValue: 0,
195
+ // Use a convert function for field-level validation or transformation
196
+ convert: value => {
197
+ if (typeof value !== 'number' || value < 0) {
198
+ console.warn('Price field must be a non-negative number!');
199
+ return 0;
200
+ }
201
+ return value;
202
+ }
203
+ },
204
+ {name: 'discount', type: 'Number', defaultValue: 0,
205
+ // Use a convert function for field-level validation or transformation
206
+ convert: value => {
207
+ if (typeof value !== 'number' || value < 0 || value > 1) {
208
+ console.warn('Discount field must be a number between 0 and 1!');
209
+ return 0;
210
+ }
211
+ return value;
212
+ }
213
+ },
214
+ {name: 'discountedPrice', type: 'Number',
215
+ // Use a calculate function for derived values based on other fields in the record
216
+ calculate: (data) => {
217
+ // 'data' contains the raw field values of the current record
218
+ return data.price * (1 - data.discount);
219
+ }
220
+ }
221
+ ]
222
+ }
223
+ }
224
+
225
+ Neo.setupClass(ProductModel);
226
+ ```
227
+
228
+ ### Extending `Neo.data.Store`
229
+
230
+ Stores manage collections of data records, often using a defined `Model`.
231
+
232
+ ```javascript readonly
233
+ import Store from '../../src/data/Store.mjs';
234
+ import ProductModel from './ProductModel.mjs'; // Assuming ProductModel is in the same directory
235
+
236
+ class ProductsStore extends Store {
237
+ static config = {
238
+ className: 'App.store.Products',
239
+ model : ProductModel, // Use our custom ProductModel
240
+ autoLoad : true,
241
+ url : '/api/products', // Example API endpoint
242
+ sorters : [{
243
+ property : 'name',
244
+ direction: 'ASC'
245
+ }]
246
+ }
247
+
248
+ // Custom method to filter by price range
249
+ filterByPriceRange(min, max) {
250
+ // The idiomatic way to apply filters is by setting the 'filters' config.
251
+ // This replaces any existing filters.
252
+ this.filters = [{
253
+ property: 'price',
254
+ operator: '>=',
255
+ value : min
256
+ }, {
257
+ property: 'price',
258
+ operator: '<=',
259
+ value : max
260
+ }];
261
+ }
262
+
263
+ // To add filters without replacing existing ones, you would typically
264
+ // read the current filters, add new ones, and then set the filters config.
265
+ // Example (conceptual, not part of the class):
266
+ /*
267
+ addPriceRangeFilter(min, max) {
268
+ const currentFilters = this.filters ? [...this.filters] : [];
269
+ currentFilters.push({
270
+ property: 'price',
271
+ operator: '>=',
272
+ value : min
273
+ }, {
274
+ property: 'price',
275
+ operator: '<=',
276
+ value : max
277
+ });
278
+ this.filters = currentFilters;
279
+ }
280
+ */
281
+ }
282
+
283
+ Neo.setupClass(ProductsStore);
284
+ ```
285
+
286
+ ### Extending `Neo.controller.Component`
287
+
288
+ Controllers encapsulate logic related to components, often handling events or managing state.
289
+
290
+ ```javascript readonly
291
+ import ComponentController from '../../src/controller/Component.mjs';
292
+
293
+ class MyCustomController extends ComponentController {
294
+ static config = {
295
+ className: 'App.controller.MyCustom',
296
+ // A reactive property to manage a piece of controller-specific state
297
+ isActive_: false
298
+ }
299
+
300
+ onConstructed() {
301
+ super.onConstructed();
302
+ console.log('MyCustomController constructed!');
303
+ }
304
+
305
+ afterSetIsActive(value, oldValue) {
306
+ console.log(`Controller active state changed from ${oldValue} to ${value}`);
307
+ // Perform actions based on active state change
308
+ if (value) {
309
+ this.doSomethingActive();
310
+ } else {
311
+ this.doSomethingInactive();
312
+ }
313
+ }
314
+
315
+ doSomethingActive() {
316
+ console.log('Controller is now active!');
317
+ // Example: enable a feature, start a timer
318
+ }
319
+
320
+ doSomethingInactive() {
321
+ console.log('Controller is now inactive!');
322
+ // Example: disable a feature, clear a timer
323
+ }
324
+ }
325
+
326
+ Neo.setupClass(MyCustomController);
327
+ ```
328
+
329
+ ## Conclusion
330
+
331
+ The class extension mechanism, coupled with the reactive config system and `Neo.setupClass()`, forms the backbone of development in Neo.mjs. By mastering these principles, you can create highly modular, maintainable, and powerful applications that seamlessly integrate with the framework's core.