deep-object-diff icon indicating copy to clipboard operation
deep-object-diff copied to clipboard

Typescript definitions

Open nikolayg opened this issue 6 years ago • 8 comments

Hey guys,

I've created some more accurate Typescript definitions for deep-object-diff. I would be happy if you merge them, so I can use them directly from the npm module :)

nikolayg avatar Jul 12 '19 07:07 nikolayg

Coverage Status

Coverage remained the same at 100.0% when pulling 71b28b81e3c18c054943cfdfe414d6390e9c36bf on nikolayg:master into 6296889cfc0e54f08b0077460c9bf75f2febfa9f on mattphillips:master.

coveralls avatar Jul 12 '19 07:07 coveralls

Awesome @nikolayg, thanks for this :)

@mattphillips would be awesome to get this merged, please :)

pzi avatar Oct 24 '19 03:10 pzi

+1

jtabone16 avatar Jan 08 '20 18:01 jtabone16

@nikolayg thanks for it). It would be great to see the changes in the next release.

It is interesting why PR is still not merged.🤔

diyorbek avatar Aug 03 '20 08:08 diyorbek

I'm not sure that it works this way. The originalObj and updatedObj could be fully unrelated and therefore typing both to T doesn't work. At least it's one possible scenario for diffing. I think a proper typings are possible, but 1. very hard to achieve 2. brings not much typesafety to the table.

Bessonov avatar Sep 25 '20 22:09 Bessonov

friendly ping @mattphillips

naseemkullah avatar Apr 12 '21 19:04 naseemkullah

I'm not sure that it works this way. The originalObj and updatedObj could be fully unrelated

@Bessonov I agree with you. This looks safe enough to me though, since each property of T gets exposed as optional, meaning that consumers will have to check that those values exist before using them. I'm not sure how this works in the case of adding properties though.

I've not searched the space much, but I imagine it's fairly uncommon to compare objects of two different types. In my own code at least, if I'm expecting a field to have been added to an object, that field would at least be defined on the type of the original as optional (potentially undefined). If the field exists on the new object, then great! I still need to check that it's undefined though since the original object is of the same type, and defines that field as optional.

AverageHelper avatar May 03 '21 16:05 AverageHelper

I don't think these type defs are actually accurate, they don't recurse on Arrays and they error on the example usage in the project readme as shown in screenshot.

Screenshot 2022-11-12 at 12 47 45

I've taken a quick stab at writing some more advanced type definitions here: https://github.com/mattphillips/deep-object-diff/pull/88. If anyone wants to test drive them on a project and provide any issues/feedback on that PR that would be greatly appreciated.

mattphillips avatar Nov 12 '22 13:11 mattphillips