Comments (10)
I am returning to this, as this is more possible than I initially thought.
Question to everyone: Would you be willing to go through a breaking change if it meant that everything was compatible with JSONPatch? This would mean you would have to update some of your code, but it shouldn't be much more than some find and replace since the formats are very related, and it would allow for more integration without a compatibility layer. Also, this would make patching much easier since the libraries already exist (although I still might fully release Micropatch for the same reason I made Microdiff, but for JSONPatch patching).
from microdiff.
@Julienng There is an implementation of patching functionality, although it is currently only on GitHub, not NPM (https://github.com/AsyncBanana/micropatch).
I could make it accessible through a subpath, although I could also just release a new major version with json-patch and continue maintaining v1 (although there is not much maintenance needed to do the library being compact and dependency-less).
Currently, I do not have a branch with json-patch, although it would be trivial to implement.
from microdiff.
That could be done, but it would require a breaking change and might come at a bit of a performance cost because of the value handling (the value can be an array or object instead of just going a level deeper).
from microdiff.
I am not an existing user but my frontend basically necessitate a diff library that output JSON-Patch given that libraries on the backend commonly expect (or generate) this format.
I think this breaking change is for the greater good as it allows standardization and interoperability with a wider ecosystem.
from microdiff.
I am little confused about what you mean. I am not talking about adding patching functionality for Microdiff. What I am saying is that Microdiff would output JSON Patch statements. For example, if oldValue was included, the output could be:
[
{ "op": "replace", "path": "/baz", "value": "boo" , "oldValue": "qux"},
{ "op": "add", "path": "/hello", "value": ["world"] },
{ "op": "remove", "path": "/foo" , "oldValue": "bar"}
]
As for use cases, it is anything that needs the past value, as getting it from the path and the old object can be slow and annoying. For example, the old value would be helpful if you built a diff viewer.
About the config, I am leaning towards that, but the code would be made much larger and potentially slower.
from microdiff.
I am looking at doing this again. However, a feature some people rely on in Microdiff is the oldValue
property, which does not exist in JSON Patch. I could add oldValue
while otherwise keeping compatibility with JSON Patch. This would still be compatible with most things and would be simple enough to filter out if there is an incompatible library.
Another option would be to add a JSON Patch config option. This would allow for perfect JSON Patch compatibility while still making it possible to see the past value for those who need it and could even allow for no breaking change (although I would probably still release a new major version for other things). However, I try to minimize the configuration, as each config option increases size and decreases performance.
What do you think?
from microdiff.
I would personally vote for the config but it's your codebase, do as you please :)
to be clear what you mean is: for the given input
{
"baz": "qux",
"foo": "bar"
}
and following patch
[
{ "op": "replace", "path": "/baz", "value": "boo" },
{ "op": "add", "path": "/hello", "value": ["world"] },
{ "op": "remove", "path": "/foo" }
]
microdiff would output:
{
"oldValueBaz": "qux",
"oldValueFoo": "bar",
"oldValueBaz": "???"
"baz": "boo",
"hello": ["world"]
}
instead of
{
"baz": "boo",
"hello": ["world"]
}
? What's the exact format
I believe in most cases those oldvalues would need to be filtered out (cpu time and increase network payload size and libraries incompatibility) although emitting them might be very useful for debugging and some validations/custom logics. I'm not aware of other use cases but maybe there are.
from microdiff.
Hello, I think keeping "oldValue" is reasonable if any other key is compatible with json-patch.
One other way would be to expose a patch and a reverse patch, so you can apply / reverse some diff changes.
Maybe making json-patch available through a new file to import might help to avoid config / breaking changes.
import { diff, patch, reversePatch } from "microdiff/json-patch"
from microdiff.
I'm going to play with microdiff and json-patch soon by transforming the result to a patch.
Do you have a branch with json-patch? I might play with microdiff locally and try to implement something
from microdiff.
+1 for this! Love your micro library :)
from microdiff.
Related Issues (20)
- Recreation from diff HOT 8
- Does not handle object changes within array HOT 2
- How about having index path for array be a number instead of a string? HOT 2
- Is it possible to see the old value? HOT 2
- Question: any recommendation on how to visualize the output? HOT 7
- Possible optimization: hashing HOT 2
- UMD bundle HOT 2
- support for NaN values HOT 1
- Ineficient change detection HOT 1
- Community Exchange Introduction/Tracking HOT 6
- Add templates for issues HOT 2
- Update README.md HOT 2
- Add Code of Conduct HOT 2
- get array removals as "DELETE" HOT 7
- ➕ Feature - Export DIFFERENCE Type so it can be imported in Ts projects HOT 2
- Inconsistent diff Behavior for Object-derived Type Changes HOT 2
- Extend the diff function with rich types not included in the base JS language. HOT 1
- Cannot use 'in' operator to search for ... in null HOT 5
- Circular references HOT 9
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from microdiff.