Node instance in multiple parentNode.children about unist-util-parents HOT 3 CLOSED

There are several things possible in JavaScript, that should not happen in unist trees.

One example is the one you point out now, but also for example cyclical references:

var child = {type: 'child', children: []}
var parent = {type: 'parent', children: [child]}
child.children.push(parent)

I believe the unist documentation explains this:

unist relates to JSON in that compliant syntax trees can be expressed completely in JSON.

And furthermore:

Any value in unist must be expressible in JSON […] This means that the syntax tree should be able to be converted to and from JSON and produce the same tree. For example, in JavaScript, a tree can be passed through JSON.parse(JSON.stringify(tree)) and result in the same tree.

If a child were to exist in multiple places in a tree, and it would be passed through JSON, it would instead result in two separate objects, copies of each other.

I hope that this explains that nodes in unist trees must be unique objects, which can occur exactly once?

Interested in hearing what your reasoning for this is!

from unist-util-parents.

Wouha ! Thanks a lot for this ! 💗 💗

I read this some times ago, but not catching all the implications...
Thanks for pointing this out !!
Maybe a side note on cyclical objects and objects references in docs can be useful ? (If I'm not the only one to not get that...).

Are you not afraid of perf / memory usage in case of big trees with many repeating objects ?

I currently work on "graph style" data (RDF / semantic data), with many repeating objects.
As it's a graph, each node N1 can have multiples nodes that link to this N1 (aka "parents")
My goal is to provide some "views" of this graph materialized by "Unist trees extractions".

Theses trees extractions are then far more usable than the "graph" one (and benefit of all Unist tools).
Thinking on this going, I started a draft of an "under the hood" process that generate trees from a graph...
I don't still really know where this going, but I will be happy to share more on this with you if interested.
Thanks a lot

from unist-util-parents.

Maybe a side note on cyclical objects and objects references in docs can be useful ? (If I'm not the only one to not get that...).

Would you be into a PR, to clarify that? We can work on the perfect wording there?

Are you not afraid of perf / memory usage in case of big trees with many repeating objects ?

unified / unist trees are used in many projects that I know of that work on huge documents. In almost all cases, basic objects (nodes) are fine, parsing can be improved a bit (micromark), but generally, performance bottlenecks are in plugins and how trees are walked / modified!

I don't still really know where this going, but I will be happy to share more on this with you if interested.

Yes, please do! Sounds interesting!

from unist-util-parents.