Releases: neomjs/neo
list.Base: afterSetFocusIndex() honor the mounted state
form.field.ComboBox: when showing the picker, the list focus & selected index should be in sync
data.RecordFactory: performance boost for creating records
While it is definitely not "best practises" to create massive amounts of records inside your UI at once (you would pull ranges from a backend), a framework should handle it as fast as possible.
To get the numbers up this drastically, I needed to move the fields creation outside of the record constructor and into the class generation. The API for records is the same as before, however the internal structure how data gets stored did change.
For nested data, you can change specific leaf nodes without overriding other siblings (it will get merged):
record.set({user: {firstname: 'Tobias'}})
You can also still trigger bulk updates => multiple fields getting into the same update cycle:
record.set({user: {firstname: 'Tobias', lastname: 'Uhlig'}})
You can still use the shortcut around the set() API to change root level fields, but this can no longer work for nested fields directly. Examples:
record.country = 'Germany'; // Internal setter, will trigger a change event like before
// No longer supported!
record.annotations.selected = false; // this shortcut syntax did work in previous versions, but no longer matches the internal structure
// Instead use the API:
record.set({annotations: {selected: false}})
// In case you want a direct field access to trigger the field change event, you can also use this shortcut (outside the API):
record['annotations.selected'] = false;
Records now provide a JSON export:
To see the editing inside an example app:
https://neomjs.com/examples/table/nestedRecordFields/index.html
Smarter vdom update aggregation for colliding updates
- See: #6244
- Portal App polishing
grid.View: added support for a column buffer range
collection.Base: performance improvement
Buffered Data Grid with 5M cells example
Critical Rendering Paths for run-time updates
I am very excited on this one!
Screen.Recording.2025-01-13.at.00.23.51.mov
Optimising critical rendering paths
While neo.mjs is focussing on high performance apps, which often run inside envs with fast internet connections, it also should not ignore users with slow network connections.
When analysing the initial paintings inside throttled envs, I realised that it can happen that widgets try to get painted before their related CSS files got loaded. Please watch the 2 short (30s) videos so see how drastic this change is.
-
Non-optimised critical rendering paths:
https://youtu.be/pUPLUUeuxZo -
Optimised critical rendering paths:
https://youtu.be/rwH1ATOgkyI
Enjoy the new version!