Closed aliang8 closed 7 years ago
I'm not exactly sure why getPath
has to be incorporated into _matchNode
. Couldn't we leave it as a separate function? If not, then yes I am waiting for _matchNodes
to be refactored.
I'm not exactly sure why getPath has to be incorporated into _matchNode.
In the case of
1 + --1 --> 1 + 1
The replacement node is 1
. If we search for 1
in the output AST we could get either the first 1
or the second 1
. matchNode
returns the matchedNode
which will be replaced. In this example there is only one --1
node which means finding the path for the matchedNode
would work. There could be a more complicated scenario such as
(1 + --1) + (1 + --1)
Since matchNode
only returns one of the --1
nodes we can't simply search for it again using traverse
. We need to use the same search algorithm which matchNode
used to find the node in the first place, namely _matchNode
. Since _matchNode
is traversing nodes already, we just need to keep track of the path it's traversing. The devil is in the details though and that code is pretty gnarly. I started working on it last night, but it's going to take some time to get it to a place that's good.
Gnarly it is. I spent some time trying to go through it, but there was too much going on to follow. 😢
TODO:
replacement
occurs multiple times in the result