Add custom store comparer option

[PFight]

Proposal

Add option to createStore method, that will change comparision logic of the store value. Docs says:

Store is updated when it receives a value that is not equal (!==) to current one and to undefined

But sometimes it not convinient to use only reference comparision, but there is need to add some deep comparision.

Use case

I have a simple struct { x, y }. I need to operate with these two values simulatenously, i.e. set bot values simulatenously, and notify listeners when boths values updated. Ofcourse, I can create 3 store - $x, $y, and combine it to $point. But I do not need to process x and y separately and do not need to notify separately for changes of x, and changes of y, so creating 3 stores instead of one is syntax overhead (I will need to create also 2x dublicting events). That's why I preffer create single store $point with complex object { x, y }, but then, I got need to write code like this to prevent :

function setPoint(x, y) {
    let oldState = $point.getState();
    if (oldState.x !=x && oldState.y != y) {
         setPointEvent({ x,  y});
    }
}

Or also code like this: setPointEvent(...point);

It's quite awfull.

[zerobias]

Just return undefined if you don’t need to update store

const move = createEvent()
const position = createStore({x: 0, y: 0})
  .on(move, (position, {x, y}) => {
    if (position.x !== x && position.y !== y) {
      return {x, y}
    }
  })

[PFight]

The problem is that position.x !== x && position.y !== y check, which I should add to every event for the store. It would be better to define this check once, and write reducers without such problems (and errors, when you forgot to write this check somewhere).

[zerobias]

I was going to suggest you to merge events to apply them at once, but maybe your suggestion really make sense. Thus we need to understand how it should looks like.

The term "store comparator" looks like it something about comparisons between stores, but it more an "update filter".

Then it might look like that:

const position = createStore({x: 0, y: 0}, {
  updateFilter: (update, current) => update.x !== current.x
})

position.on(move, (_, upd) => upd)

move({x: 0, y: 0})
// no reaction
move({x: 1, y: 2})
// position → {x: 1, y: 2}

1. move called
2. position update
   1. check if update from move is not undefined
   2. updateFilter called with move payload and current position state
   3. if updateFilter return truthy value, then update position with move payload

[zerobias]

If you remove strict equality check you introduce concept of mutability and this is orthogonal feature: store might be mutable (that is, accept same value multiple times in a row) but not have updateFilter and vice versa store might be immutable (as usual) and do have updateFilter.
Even more, these features look mutually exclusive: when you call updateFilter(foo, foo) you inevitable return false, aren't you?

[zerobias]

And introduction of mutability actually leads to vast amount of issues and edge cases: if your store accepts same value several times in a row, then its mapped store should update accordingly, thereby becoming mutable too. The same thing applies to combine, in which case it becomes very odd thing with several immutable and a few mutable ways to update

[PFight]

No, replacing strict equality check is needed not for introducing mutability, but to introduce deep check. So, different objects can be equal, because equal its fields. It is the problem, described from the beginning.

[zerobias]

In reverse: you should introduce mutability to remove strict equality check, even more, strict check not affect your ability to use deep equality anyway

Btw, I already implemented the feature using exactly your case as a reference, so it’s works as expected: https://github.com/effector/effector/blob/master/src/effector/__tests__/store/index.test.ts#L277

[flux627]

Any idea when this will be released on NPM? I tried yarn linking from a local build but couldn't get it to work.

EDIT: Was able to get the local build to yarn link, but I'm still interested when it will be released to NPM.

[PFight]

The another case:

let point = { x: 1, y: 1 };
move(point); // position -> { x: 1, y: 1 }
point.x += 1;
move(point); // reference is the same, but because of updateFilter change detected, and position -> { x: 2, y: 1 }

[zerobias]

Store values should be immutable, mutations are not supported. Even more, in this case updateFilter will return false, as you'll compare an object with itself

[victordidenko]

Doesn't this solved by mapped store?

• You don't process x and y separately
• You will not create 2 dublicting events
• You will write condition just once

const move = createEvent()

const $prepoint = createStore({ x: 0, y: 0 })
  .on(move, (_, curr) => curr)

const $point = $prepoint.map(
  (curr, prev) =>
    !prev || curr.x !== prev.x && curr.y !== prev.y
      ? curr
      : prev
)

$point.watch(_ => console.log('$point.watch:', _))

move({ x: 0, y: 1 })
move({ x: 1, y: 0 })
move({ x: 1, y: 1 })

will ouptut

$point.watch: {x: 0, y: 0}
$point.watch: {x: 1, y: 1}

[zerobias]

Issue with store.map for filtering updates is that we will mess with two stores instead of single one, for example we must use original store in sample target

[zerobias]

updateFilter released in effector 21.8.0, thanks for insightful conversation!