Now that useState only re-renders if changed why now add optional "reducer" parameter?

[Rui Fortes]

This is a little inconsequential but, nevertheless...
Couldn't useReducer be replaced by simply allowing for an optional reducer after initialState?
The returned "setState" function would be the "dispatcher" if "reducer" was provided

Again...what I'm I missing here?

[Lenz Weber-Tronic]

So, you want to introduce a breaking change for hundreds of thousands developers that just got used to an API for... what benefit exactly?
Cramming two methods into one doesn't even make it more readable, it adds more mental load to using the API.
And considering that useState is a special case of useReducer, if you wanted to eliminate one of the two, you'd have to eliminate useState;)

[Rui Fortes]

Well...it wouldn't be a breaking change because useState would work as before without if no reducer was supplied.

Granted it might be easier to see that a reducer is used to set state using a specific "useReducer" hook than checking if the second argument is used (although the reducer function would probably be defined somewhere else and a name like "somethingReducer")

On other side it would be easier to understand that the two are really the same thing (setState is just a special type of reducer with one action) has there would only be one thing.

And besides useState being the only one that could be extended without breaking the api it wouldn't make much sense keeping the one with the more specific name.
The reducer is just a special type of state changing function and actually I don't even know if that name is appropriate has there's already the more common reducer function that takes a collection and returns a single value.

My intent was not simple minimalist indulgence but to understand if there was something else preventing this unified hook that I'm not aware

[Lenz Weber-Tronic]

Removing useReducer would definitely be a breaking change. Adding this without removing useReducer would be pretty pointless, wouldn't it?

[Rui Fortes]

I admitted from the start it was a little inconsequential but... again, it could make the concepts more concise was useReducer would just be a sugar hook as useCallback is for useMemo(() => () => ....)

And by the way... a different useCallback that would really be useful would be one that would always be on the most recent scope without changing reference to avoid triggering re-rendering the components that use it but...that's another issue

[dan]

Hi, thanks for your suggestion. RFCs should be submitted as pull requests, not issues. I will close this issue but feel free to resubmit in the PR format.