Open LeaVerou opened 6 months ago
Could also be a variant of option 1 where we accept a generic flattened array, e.g. ["left", "right"]
, or a nested array, e.g. [["children", "key1"], ["children", "key2"]]
, or we could also allow the wildcard key to signal check all properties in this object, for example, [["children", "*"]]
would mean all subproperties of children
are children
Could also be a variant of option 1 where we accept a generic flattened array, e.g.
["left", "right"]
, or a nested array, e.g.[["children", "key1"], ["children", "key2"]]
, or we could also allow the wildcard key to signal check all properties in this object, for example,[["children", "*"]]
would mean all subproperties ofchildren
are children
Yeah, the more I think about it, the more I like this idea. For convenience, we should also support arrays as the value, not just functions.
E.g. the Mavo.Node
use case would be:
childPaths: [["children", "*"]]
the DOM Node use case would be:
childPaths: [["childNodes", "*"]]
While having a nested array with a single element is a bit unwieldy, it's very explicit, and in most cases there's only one.
Yeah, the more I think about it, the more I like this idea. For convenience, we should also support arrays as the value, not just functions.
Yeah we can definitely do this. I'll start iterating on this and have a PR up today or tomorrow
Btw I think the function that applies such a path to an object and returns the result is really useful and we should expose it as one of our helpers rather than having it as an internal util.
Btw I think the function that applies such a path to an object and returns the result is really useful and we should expose it as one of our helpers rather than having it as an internal util.
Yeah I was planning on adding that along with a find path function
Problem
In #16 we converted our hardcoded
{ node, property, index }
parent pointer structure to a more flexible{ node, path[] }
schema. However, we did not change our internals much to really support arbitrary paths. We still assume children are found by:getChildProperties()
is specified, we follow all properties on a node, and callisNode()
on them to see if they are child nodes. This only goes 1-2 levels deep: values that are obtained by following one property, or array values if that one property is an array.getChildProperties()
is specified, we follow these properties and do not callisNode()
, we just filter by existence.Currently, this assumes a specific structure that may be overfit to Treecle’s AST beginnings. I suspect in the wild there are two common ways to represent tree data structures:
children
for Mavo Nodes,childNodes
for DOM Nodes)Currently, the API only supports providing a function that takes a node and returns a list of properties. As an example, this is how this setting is specified in vastly:
This appears to be overfit to 1. Yet, I suspect 2 may even be more common. How do we allow both to be specified without making either more complicated due to the existence of the other?
Ideas
getChildProperties()
togetChildPaths()
, handle bothstring[][]
andstring[]
?We don't want to complicate 1 to cater to 2, but what if we could do both? If the function returns an array of strings, they are single properties. If it returns an array of arrays, they are paths.
The problem is, we don’t necessarily have specific child properties in 2, often once you get from the node to its children, everything in that data structure is a child.
Wildcards? JSON Paths?
Basically, we want a way to say
children/*
for these cases. What if we handle/
and*
in properties specially?But then we’re basically creating a path microsyntax, and restricting the potential syntax of actual real properties accordingly. OTOH, that's basically JSON Path syntax, which is quite well established.
The advantage of something like this is that we can still handle properties like Vastly’s in exactly the same way.
Not a huge fan of any of these ideas, so I’ll continue brainstorming.