You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Take the following example:
Expected: [1, 2, [:a, :b, :c], 4]
Actual: [1, 2, [:a, :x, :c], 4]
We *could* display this diff like this:
[
1,
2,
- [:a, :b, :c],
+ [:a, :x, :c],
4
]
However, it would be much more helpful to show a diff like this:
[
1,
2,
[
:a,
- :b,
+ :x,
:c
],
4
]
In order to do this, the first step is to treat groups of operations
which consist of a delete followed immediately by an insert as a
"change". (So in this case, the fact that we are deleting `[:a, :b,
:c]`) and adding `[:a, :x, :c]` is a change.) From there, we modify all
diff formatters so that they look for these change operations. If we
encounter one, we can then run a diff on the deleted (or "left") value
and the inserted (or "right") value. This will spit out a new set of
operations, which we can then run through whatever diff formatter is
appropriate for the two values. There's some trickery involved here,
particularly when it comes to hashes and objects, but that's the
10,000-foot view.
One thing to note is that in order to do that last step, we have to add
a diff formatter factory which looks at the values being diffed and
figures out which class to use. Out of necessity I've extended this
strategy to the other types of classes we have as well. Also a part of
this change was adding a new type of classes called "operation
sequences". This is a collection of operations that knows how to format
itself.
0 commit comments