Converting objects to hash signatures in JavaScript

If you’re doing this in a serious setting, use a stable JSON stringification (like json-stable-stringify) that sorts object keys, and then take the SHA of the resulting string.<p>Better collision properties, easier to implement, and a cryptographic hash to boot, just as long as you don’t have circular references and only care about the serializable “contents” of an object.

To make stuff like this work in all scenarios, you have to have to implement your comparator function in your class, but also all members in that class need to have that comparator defined as well. Then, when you call your comparator in the object you want to compare, the comparator will also call the comparators in the members, and these in their own members recursively until you get all the way to the end.<p>In addition, the containers need to have these same comparators, so all your data structures will need to be wrapped or redefined (arrays, hashmaps, etc).<p>It&#x27;s much harder than it appears on the surface. You may get cases of infinite recursion in cases of mutual references. For a quick and dirty comparison, you can convert both objects to JSON and compare those strings. In fact the JSON string, if made to be deterministic, can exactly fulfill this function of this &quot;hash&quot; which is used to compare two objects.

It&#x27;s a good practice to have a way to compare objects anyway, and it should be standardized, like __hash__ in Python or hashCode in Java.<p>Even a basic comparison between two nested arrays is work in JS, so we need articles like this for things we use day to day. It&#x27;s weird that the orgs building the standard think that a common promise API is a priority, but a decent namespace system or a way to manipulate builtin datastructures without 3rd party lib isn&#x27;t.

I was waiting for people to say something first. I was sure I was missing something. But for the love of God, that&#x27;s horrible! Not only what ermir said, but what about collision in 32 bits? It&#x27;s only 4 billion entries. I keep thinking I should do something in Node to learn, then I read stuff like this. Is this Javascript, the Good part, or the other part? I can&#x27;t tell.

I tend to just use json-stable-stringify to get a consistent representation of JS objects. Then can hash or compare that.<p>Browser:<p><pre><code> const crypto = window.crypto || window.msCrypto; &#x2F;&#x2F; IE11 return window.crypto.subtle.digest(&#x27;SHA-256&#x27;, stableStringify(obj)); </code></pre> Node:<p><pre><code> require(&#x27;crypto&#x27;) .createHash(&#x27;sha256&#x27;) .update(pwd) .digest(&#x27;base64&#x27;); </code></pre> [1] <a href="https:&#x2F;&#x2F;www.npmjs.com&#x2F;package&#x2F;json-stable-stringify" rel="nofollow">https:&#x2F;&#x2F;www.npmjs.com&#x2F;package&#x2F;json-stable-stringify</a>

This feels like cargo culting of Java&#x27;s hashCode (or similar) to me. As I understand it, hashCode is used as an optimization in the implementation of data structures like hash maps and sets, not as the primarily equality check, since collisions can occur.<p>It would be simpler, faster, and more correct (no chance of collisions) to just implement an isEqual method.

I&#x27;d prototyped this solution as well for deep object comparisons, storing the hash in a weakmap, so hashes could be garbage collected as the Objects themselves, which act as keys, are collected; this also solves any potential infinite recursion, as the same object key points to the same value, and you could terminate after a collision there.<p>That said, why are we doing this and where is our native isEqual method?

Fine but please don’t hang new methods off the Object prototype (or other built ins). We used to do that and it made a terrible mess.