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.
- package/ServiceWorker.mjs +2 -2
- package/apps/form/view/FormPageContainer.mjs +2 -3
- package/apps/portal/index.html +1 -1
- package/apps/portal/view/home/FooterContainer.mjs +1 -1
- package/apps/portal/view/learn/ContentComponent.mjs +18 -11
- package/learn/README.md +9 -14
- package/learn/guides/Collections.md +436 -0
- package/learn/guides/CustomComponents.md +256 -14
- package/learn/guides/ExtendingNeoClasses.md +331 -0
- package/learn/guides/Forms.md +449 -1
- package/learn/guides/Layouts.md +246 -1
- package/learn/guides/Records.md +286 -0
- package/learn/guides/form_fields/ComboBox.md +241 -0
- package/learn/tree.json +8 -3
- package/package.json +1 -1
- package/resources/scss/src/apps/portal/learn/ContentComponent.scss +9 -0
- package/src/DefaultConfig.mjs +2 -2
- package/src/form/field/ComboBox.mjs +6 -1
- package/src/vdom/Helper.mjs +7 -5
@@ -1,45 +1,287 @@
|
|
1
1
|
## Introduction
|
2
2
|
|
3
|
-
Neo.mjs is
|
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
|
-
|
12
|
+
This guide will walk you through the process.
|
7
13
|
|
8
|
-
##
|
14
|
+
## Choosing the Right Base Class
|
9
15
|
|
10
|
-
|
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
|
14
|
-
|
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
|
-
|
19
|
-
|
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
|
-
|
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
|
-
|
38
|
-
|
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.
|