Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature: Pre-registration/optional flattening of required NodeState configurations #7260

Open
etrepum opened this issue Feb 28, 2025 · 0 comments · May be fixed by #7258
Open

Feature: Pre-registration/optional flattening of required NodeState configurations #7260

etrepum opened this issue Feb 28, 2025 · 0 comments · May be fixed by #7258
Labels
core Reconciler, DOM, Selection, Node, Events, Composition enhancement Improvement over existing feature

Comments

@etrepum
Copy link
Collaborator

etrepum commented Feb 28, 2025

Description

The initial version of NodeState implemented in #7117 only offers ad-hoc state for nodes, this means that when a node is deserialized from JSON it does not assign any meaning to that value until it is first read with $getState.

For many custom nodes going forward, it is expected that most of the node's internal state (beyond the base class) will be represented with NodeState as it requires much less boilerplate and can even be more efficient than implementing it by hand. It makes sense for the nodes to be able to declare in advance what state they require so that full serialization and other features can be enabled prior to instantiation (pre-registration).

NodeState by default serializes everything into a nested object in the serialized node JSON, but for efficiency and backwards/forwards compatibility reasons (refactoring the implementation of a class from __properties to NodeState) it may make sense to lift specifically configured keys to the root of the serialized node JSON.

Impact

This is basically a prerequisite for #7259, but it is also the last remaining piece to make NodeState first class and on par with implementing __properties directly. What I would not like to see is for people to manually write some boilerplate code to implement this flattening on a one-off case when it can be a built-in feature with simple configuration.

@etrepum etrepum added the enhancement Improvement over existing feature label Feb 28, 2025
@etrepum etrepum added the core Reconciler, DOM, Selection, Node, Events, Composition label Feb 28, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core Reconciler, DOM, Selection, Node, Events, Composition enhancement Improvement over existing feature
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant