Add tests to cover hooks, and fix extraneous hook call #73
+181
−3
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There were no tests at all for the hooks, and hooks are about to get weird with the upcoming twoPass system, so I thought I'd add some to cover the status quo! However, this unearthed some bugs and questions.
So, three commits here:
skip
, because...beforeAttributeUpdated
hook was erroneously getting called twice on additions and updates, with the second call claiming aremove
mutation, which was definitely not happening. The change to thesrc
in this PR is reflecting that fix.afterNodeMorphed(oldNode, newContent)
is being called with BOTH arguments essentially being the same. On one hand, this is surprising. I'd naively expect it to show me the before and after states, especially given the argument names. However, since the first argument is the node itself, and its after it's been morphed, it does make some sense for both arguments to be the same. So, is this a bug, or desired behavior? Maybe we just need to change the names of the arguments? Or just pass one(node)
argument?Lastly, two questions:
beforeAttributeUpdated
event. Should we add a correspondingafterAttributeUpdated
event? Pushing this to its logical conclusion, it would be easy to imagine expanding this toAttributeAdded
AttributeUpdated
andAttributeRemoved
, as well. Has any downstream software ever wanted any of these?beforeAttributeUpdated
, I expected to see the value of the attribute in there, but I do not, just the name. Should we add it?