You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now we have a Document model, which doesn't get us much other than being able to know that we're at a "root" node in the tree. With #2495 there's a benefit to being able to further eliminate the need for .object properties, so we can remove it.
What's the expected behavior?
Based on #2757, we'd change things to remove the idea of a Document model. And instead put its properties directly on the Value. So you'd have:
constvalue={nodes: [...],data: {},
...
}
(The data property technically already exists, so we're simplifying by getting rid of the arbitrary distinction between document.data and value.data which is currently confusing anyways.)
We'd still need to be able to express the concept of a "fragment". But this can be handled by a simple array of nodes, instead of a separate object.
(In the further future we may need to be able to determine whether the edges of a fragment are "open" or "closed", to better handle insertion logic when nodes should be merged. But we can handle this case when we get there, by using an object with extra properties.)
The text was updated successfully, but these errors were encountered:
Do you want to request a feature or report a bug?
Improvement.
What's the current behavior?
Right now we have a
Document
model, which doesn't get us much other than being able to know that we're at a "root" node in the tree. With #2495 there's a benefit to being able to further eliminate the need for.object
properties, so we can remove it.What's the expected behavior?
Based on #2757, we'd change things to remove the idea of a
Document
model. And instead put its properties directly on theValue
. So you'd have:(The
data
property technically already exists, so we're simplifying by getting rid of the arbitrary distinction betweendocument.data
andvalue.data
which is currently confusing anyways.)We'd still need to be able to express the concept of a "fragment". But this can be handled by a simple array of nodes, instead of a separate object.
(In the further future we may need to be able to determine whether the edges of a fragment are "open" or "closed", to better handle insertion logic when nodes should be merged. But we can handle this case when we get there, by using an object with extra properties.)
The text was updated successfully, but these errors were encountered: