Skip to content

Clean up the logic in fragment merging

Working on !267 (merged) made me realize that the fragment merging was implemented in a more complicated way than it needed to be. Fine, it was doing what it was supposed to, but I'm not sure if many people would have been able to understand it.

This simplifies the merging a bit:

  • Previously when we added fragments to the original json tree, we were replacing the original tree with the fragment, and then calling a merge function that overwrote the fragment if any parts appeared in the original tree.
  • Now we're only updating the original tree with parts of the fragment that don't appear in the original tree.
  • There was also some confusing copying / renaming that happened inside the top level function that did all this.

Maybe this is more efficient, but it doesn't really matter, the main goal was to make the code slightly more readable.

Merge request reports