pub fn apply(doc: &Document<'_>, edits: &[Edit]) -> Result<String, Error>Expand description
Apply edits to the source of doc and return the edited JSON.
The output is re-parsed before it is returned. Since every replacement payload is one JSON value by construction, and a value is legal wherever another one was, this should not be able to fail; it is kept as a backstop on the splicing, and on the payload builders in a release build where their own assertion is compiled out.
Edits interact, and the rules are not symmetric:
| Case | Outcome |
|---|---|
| Two removals of the same element | Removed once |
| A removal of an element inside another removed element | The ancestor’s span covers it |
| A replacement of an element that is also removed | The removal wins |
| A replacement of an element inside a removed element | The removal wins |
| Two replacements of the same element, same text | Replaced once |
| Two replacements of the same element, differing text | Error::Duplicate |
| A replacement of an element inside another replaced element | Error::Conflict |
| A removal of an element inside a replaced element | Error::Conflict |
A removal absorbs any edit inside it because the bytes go away either way, so nothing an inner edit intended is lost. A replacement cannot absorb one: its payload was written without knowledge of the inner edit, so applying it would discard that edit silently.
Two replacements asking for the same text are one edit proposed twice, not a disagreement:
a day_of_week list can be both unsorted and repeating, and the same sorted list resolves
either warning. Only replacements that disagree about the text are an error.