Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

New Equality function type signature breaks with a lot of equality functions

See original GitHub issue

Thanks for the great library! Just a heads up and something I think worth considering; adding the index to the equality callback causes a lot of commonly used equality functions to break.

For instance the most popular one, shallowEqual has as a third parameter a custom comparison function: shallowequal(value, other, [customizer], [thisArg]). Same is true for the lodash deep comparison function.

Of course it is not a huge problem to change this in our code, but it breaks a lot of existing code like this: memoizeOne(params, shallowEqual)

Issue Analytics

State:
Created 5 years ago
Comments:5 (4 by maintainers)

Top GitHub Comments

1reaction

alexreardoncommented, Dec 16, 2018

Based on your feedback I think I will role it back. I’ll have more of a think about how to move forward On Sun, 16 Dec 2018 at 9:35 pm, Alex Reardon alexreardon@gmail.com wrote:

I was unsure about this one but I had no data to back up my unease On Sun, 16 Dec 2018 at 9:34 pm, Alex Reardon alexreardon@gmail.com wrote:

Oh snap. Perhaps we should role this back. Thoughts? On Sun, 16 Dec 2018 at 9:04 pm, Edo notifications@github.com wrote:

Thanks for the great library! Just a heads up and something I think worth considering; adding the index to the equality callback causes a lot of commonly used equality functions to break.

For instance the most popular one, shallowEqual has as a third parameter a custom comparison function: shallowequal(value, other, [customizer], [thisArg]). Same is true for the lodash deep comparison function.

Of course it is not a huge problem to change this in our code, but perhaps something to consider since it breaks a lot of existing code like this: memoizeOne(params, shallowEqual)

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/alexreardon/memoize-one/issues/47, or mute the thread https://github.com/notifications/unsubscribe-auth/ACFN7T1r-SSS0X8bXYckICSRnYMia8dsks5u5hrJgaJpZM4ZVH1o .

0reactions

nihgwucommented, Dec 17, 2018

From my perspective, a library should not be aware of the implementation of other libraries

The HOC idea is awesome, but it complicates the usability IMO, I agree we should roll back #42 as it breaks current usage suggested by the README

Top Results From Across the Web

The Eq type class - CIS194

This class brings equality to the world . Type classes. In last week's homework, you have developed a working implementation of Sokoban.

Documentation - TypeScript 3.7

For that reason, TypeScript 3.7 introduces a new concept called “assertion signatures” which model these assertion functions. The first type of assertion ...

Typeclasses: Polymorphism in Haskell - Andrew Gibiansky

A function with that type signature cannot check whether one value of type a is equal to another value of type a !...

function declaration - JavaScript - MDN Web Docs

The function declaration defines a function with the specified parameters.

Why does Haskell hide functions with the same name but ...

So Haskell never makes any decisions based on the fact that a given type does not have an instance for a given typeclass....