distinctUntilChanged with objects

[turanofff]

I noticed that distinctUntilChanged operator provides default comparator which only works with primitives.

function defaultCompare(a: any, b: any) {
  return a === b;
}

Official documentation https://rxjs.dev/api/index/function/distinctUntilChanged does not seem to outline the fact that this approach won't work when Observable emits objects. It will only compare object references. Given that the best practice is always emit new object and not mutate it, distinctUntilChanged would become useless if custom comparator is not provided in this case. Additionally, I think it is counterintuitive for some developers who didn't pay too much attention to how this operator works.

I also understand that there is distinctUntilKeyChanged operator to work with objects, though it would only work if there's a need to compare objects based on specific key.

Based on all mentioned above I have two possible solutions to improve the situation:

1. Make comparator mandatory when Observable emits objects
2. Provide default comparator for objects:
   a. May use something like fast-deep-equal to compare previous value with the current one.
   b. If it is undesired to use a 3rd party library, then I think it would be possible to write a method to compare objects in scope of the library.

I would be happy to contribute in order to improve the situation.

[turanofff]

It would be great to hear why or why not the idea doesn't make sense @demensky or @voliva?

[voliva]

It's more consistent to have the same equality for every type, which by convention is usually Object.is (kind of equivalent to ===, except Object.is(NaN, NaN) === true)

Having distinctUntilChanged by default change so that when the value is an object it changes to a deep comparison feels arbitrary. And why not a shallow comparison? It just doesn't feel as good as a "primitive operator".

If you want some specific behaviour you can supply a custom equality function already, or you can easily create your custom operator for your project that uses deep equality by default based on it.

[josepot]

Official documentation https://rxjs.dev/api/index/function/distinctUntilChanged does not seem to outline the fact that this approach won't work when Observable emits objects.

The documentation indeed indicates that by default, distinctUntilChanged uses reference equality. In many functional programming paradigms, including React, the same object reference is used for signalling that nothing has changed.

It will only compare object references.

That's correct, as per the official documentation.

Given that the best practice is always emit new object and not mutate it

Such an opinionated statement would require for at least a few reputable references. Most functional programming paradigms advise returning the same reference when nothing has changed, and only using a new reference when there is a change. I.e: immutable data-structures.

distinctUntilChanged would become useless if a custom comparator is not provided in this case.

It's essential to use the operator as intended. If you have unique requirements, providing a custom comparator is the right approach.

Additionally, I think it is counterintuitive for some developers who didn't pay too much attention to how this operator works.

Understanding the documentation and adhering to best practices is crucial.

Make comparator mandatory when Observable emits objects

This would imply a breaking change that would impact many existing projects that are using the library as intended. The current default behaviour aligns with established practices.

Provide default comparator for objects

There is a default comparator in place, and it aligns with standards in the industry. Libraries like react-redux and React itself (the setter returned by the useState hook) also uses reference equality, for instance. The reference equality comparison is a commonly accepted default.

May use something like fast-deep-equal to compare previous value with the current one.

While deep comparisons could be useful in some (few IMO) scenarios, they're not always suitable. Considerations like class instances (dates, maps, sets, etc), which as I'm sure you know: are objects, also objects with circular references, and performance implications come into play. For those needing deep comparisons, a custom comparator can be provided.

If it is undesired to use a 3rd party library, then I think it would be possible to write a method to compare objects in scope of the library

RxJS has already written a method to compare objects which is in scope of the library, which is the widely accepted default comparator function.

[turanofff]

Thanks for the answers! It now makes perfect sense