Support "functional updates"

[AskAlexSharov]

const [conditions, setConditions] = useQueryParams({})
setConditions(previousState => {
   return {...previousState, someParam: someValue}
})

Here is how React.useState supporting it: https://reactjs.org/docs/hooks-reference.html#functional-updates

[pbeshai]

Can you explain the motivation for this? If it's just for keeping the remaining values, setQuery does this by default (using the 'replaceIn' update type).

e.g.

const [query, setQuery] = useQueryParams({ foo: NumberParam, bar: StringParam });
// query = { foo: 1, bar: 'abc' }
setQuery({ foo: 2 });
// now query will be { foo: 2, bar: 'abc' }

To get the whole object replaced, you can specify a different update type:

const [query, setQuery] = useQueryParams({ foo: NumberParam, bar: StringParam });
// query = { foo: 1, bar: 'abc' }
setQuery({ foo: 2 }, 'replace');
// now query will be { foo: 2 }

Available update types are: replace, replaceIn (the default), push, pushIn

[davidwallacejackson]

In theory, this would be good for implementing any state updates that depend on previous values, e.g. setQuery(prev => { foo: prev.foo + 1 }. I'm not sure how much of a problem this really is in practice, because (I think?) param updates are handled synchronously. So you can probably do setQuery({ foo: params.foo + 1 }) without consequence -- but I'm not really sure...?

In either case, it might be nice to support it just for API parity with setState. I know I've cultivated a habit of always using function updates when depending on previous states, and intuitively I just expected to do the same thing with useQueryParams.

[kqr]

Here's a somewhat contrived but still clear use case for functional updates. Take the classic counter component example, like so:

function Counter() {
  let [count, setCount] = useState(0);
  return <div>
    <p>Count: {count}</p>
    <button onClick={() =>
      setCount(count + 1)
    }>Increment</button>
  </div>;
}

This has, as you say, no observable bugs relating to state management.

Now pretend this is running on a computer where incrementing a number is a very expensive operation (or pretend it's doing something more complicated/expensive in the first place.) We can model this with a timeout:

function SlowBuggyCounter() {
  let [count, setCount] = useState(0);
  return <div>
    <p>Count: {count}</p>
    <button onClick={() =>
      window.setTimeout(() => setCount(count + 1) , 500)
    }>Increment</button>
  </div>;
}

This will have a noticeable bug: if you click the increment button multiple times in rapid succession, it will still only increase by one. It's easy to see why. The count state will not be updated until 500 ms after the click. This is probably not what the user expected.

If we instead use the "functional update" style, we get the expected behaviour: three rapid clicks results in the counter being incremented by three.

function SlowCounter() {
  let [count, setCount] = useState(0);
  return <div>
    <p>Count: {count}</p>
    <button onClick={() =>
      window.setTimeout(() => setCount(count => count + 1) , 500)
    }>Increment</button>
  </div>;
}

---

Note that it's not obvious that one or the other is "better" in general: sometimes you want the update to be based on the current visible state, rather than the future current state. But in this case, with an increment button, it is fairly clear the expected behaviour is that the number should be equal to the amount of clicks, lest a user will be very frustrated when any sort of transient latency/lagging causes the counter to lose their clicks.

In other words, both types of update need to be available in the API, because the library cannot know which is most relevant in any given situation.

[pbeshai]

Ok I'll take a look