walkUp function
#20
walkUp function
#20
Conversation
✅ Deploy Preview for treecle ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
|
Added in a call to |
| if (ret !== undefined) { | ||
| return ret; | ||
| } | ||
| assertParentPointers.call(this, node, "Cannot walk up the tree from a node with no parent pointer."); |
There was a problem hiding this comment.
Can we print something more useful? Since we check on every node, it would help debugging to know which node actually failed.
| */ | ||
| export default function walkUp (node, callback) { | ||
| while (node) { | ||
| const ret = callback(node); |
There was a problem hiding this comment.
Currently even in a tree with zero parent pointers you get the callback executed once. Is that what's best for the use cases that use this? Not a rhetorical question, I don't know. We need to look at the code using this function to see what would work well for these use cases.
There was a problem hiding this comment.
The main issue I see is the fact that we could execute an arbitrary number of callbacks before running into an error in the case where some ancestor node n nodes away doesn't have parent pointers set. The best option might even be to walk up the entire tree before executing any callbacks, and asserting parent pointers, and then after completing the first walk up, doing a second pass where you execute the callback. But of course, this also has a performance increase factor of 2, but might be worth it! Of course, if the callback didn't do any sort of mutation, then it would be safe to call before discovering an error, but I don't think we can count on that. I'd probably lean toward the above idea (walking up twice). What do you think @LeaVerou?
| import copy from "./utils/copy.js"; | ||
|
|
||
| const tree = copy(trees[0]); | ||
| updateParents(tree); |
There was a problem hiding this comment.
Might want to have some throws tests too, for when we don't have parents. Or should that just be handled in the parents tests?
A part of use cases discussed in #11