Change convention of setter to `mutateState` instead of `setState`

[jvliwanag]

In order to help reading code that mixes useState and useMutative, it might be helpful to change the convention to mutateX. If this is a welcome change, I can submit a pull request that changes the docs and usage in code to this new convention.

Example:

const [enabled, setEnabled] = useState(true);
const [fancyState, mutateFancyState] = useMutative({...});

[unadlib]

hi @jvliwanag , do you mean to modify the examples and the jsdoc examples in the code?

The related performance tests are here. In terms of performance, we have reason to believe that useMutative can fully replace useState, and thus, we do not recommend mixing useState with useMutative. Do you have a special reason for mixing them?

[jvliwanag]

Yes, just the docs and examples.

Still new with mutative style hooks. Most of my code is expectedly on useState. I find useState sufficient and in fact preferrable over useMutative for fine grained states storing simple primitives — a boolean, a string or just a number, or even a js object but modified as a whole.

For complex states though, this is where i find useMutative really shines.

That said, as a reader of the code if I encounter a variable named “setFoo”, just reading the name alone doesn’t tell me how to invoke it. Am i supposed to pass a function that returns the entire state (which is expected if it came from useState), or am I supposed to pass a function that modifies the param (which is expected if it came from useMutative). Sure, i can trace back the code which hook was used or i can force my editor to reveal the typescript type — but i’d rather be able to tell quickly from the variable name. As such, on my own code, i use the “mutateFoo” convention to quickly tell it’s from useMutative.

[unadlib]

Perhaps you also know that useMutative() also supports updating primitives. However, there is some truth in what you say, pull request welcome.