Following edges in a generic way

[adamjanicki2]

One issue in the current code is the fact that we are assuming in the ported code that properties can be accessed as edges to lead to children (i.e. parents module is no longer correct because it assumes paths are properties and indices which isn't necessarily true anymore), but what we need is something in the config to define how to follow edges. If an author has their own custom node classes, then using the property/index parent paths that we used in vastly are no longer correct.

We need some type of config that authors set that tell us how to follow an edge from a parent to a child. By default, it should be some way of accessing properties, i.e.

function followEdge(node, ...what else goes here?) {
    return node[prop];
}

but an author could make a custom one like

function followEdge(node, ...what else goes here?) {
    return node.children[prop]; // or however their node class stores children
}

It's pretty tricky; I can't figure out immediately what the function needs to look like exactly, but this infrastructure will be needed before we do anything else in the library. What do you think @LeaVerou?

[adamjanicki2]

I think we need to evaluate the tradeoff between flexibility and extra work for authors; is it worth letting them use their own custom node type if they'll have to supply non-trivial config functions (such as how to follow edges and how to return their children)? Do we know if this is a use case we need to account for?

[LeaVerou]

Another tradeoff is also that we shouldn't be doing a ton of extra effort to support this broader set of use cases. It's ok to scope them down a bit, especially if it's possible to expand in the future.

I think it's fine to assume that to get from a parent to a child you follow a property and maybe an index. There is already some customization there in the sense that authors can optionally restrict which properties are examined for that (which vastly uses).

That said, does it actually simplify our code to keep property and index separate? (not a rhetorical question, I don't have time to look rn). If it doesn't simplify it much, we could just have a single path property with an array. If the only way in which it simplifies our code is that it lets us do path.property, we could potentially get the best of both worlds by making paths instances of a Path object that has a property getter.

I think we need to evaluate the tradeoff between flexibility and extra work for authors; is it worth letting them use their own custom node type if they'll have to supply non-trivial config functions (such as how to follow edges and how to return their children)? Do we know if this is a use case we need to account for?

This is correct when such a tradeoff exists, but I don't think there is such a tradeoff at play here, since they'd only be specifying that config iff they have a custom situation (in which case implementing the whole thing themselves would be more effort). Otherwise, the defaults would work just fine.

[adamjanicki2]

I highly support the idea of making paths arrays of properties/indices, especially since we can implement a broader path function which returns a path between two nodes as an array, as well as a function that takes a node and a path and returns the node at the end of the path

[adamjanicki2]

Making as closed, will pursue general paths in a separate issue