Feature Request: could setState mirror react.setState functionality?

[njsaeli]

Unless I am mistaken,

Currently React.setState will accept either the new state or a function which accepts the old state and return the the new state, while the react-hookstore version of setState will only accept the new state, as well as having the optional callback.

could the react-hookstore version be adjusted to allow for the function to be accepted in place of the state value?

Based on what I've looked at in the source code, the only thing preventing this from working seems to just be a typing issue? Unless i'm missing something I believe hookstore is using the react.setState everywhere under the hood.

[jhonnymichel]

Sounds reasonable. Let me see if I can do it in the next few days.

[jhonnymichel]

Hi @njsaeli for now, please use a store with a reducer to achieve the desired goal, it's actually not that simple to mimic the react API

[kristapsPelna]

@jhonnymichel @njsaeli I have been working on an alternative for react-hookstore that fits my clients needs a bit better.
https://www.npmjs.com/package/usestore-react
It doesnt have reducers, but is built with TypeScript, so typings out of the box, 100% test coverage, conventional commits with an always up to date CHANGELOG.
setState works the same as from React useState (accepting newState or a function that returns the newState).
Has a reset function for the store, a scoped useStore, etc.
It also allows the defaultState to be undefined unlike react-hookstore.
It does behave a bit differently with accessing a store that doesnt exist, because it will create it instead of throwing an error. As this way you can easily dynamically create stores for dynamic ids.
It also has inverse subscription order (last to subscribe is first to render) to avoid issues when a top level route rerenders and then some components that were unmounted got rendered that caused noop warnings/errors with React.

Feel free to check it out.

[jhonnymichel]

That's very cool. A lot of decisions I wish I made for react-bookstore. the truth is I made this project in very early hooks days and that's why it got attention, but I personally never used it in big projects and that's why there are a lot of design flaws because I never felt the pain they caused.

But it's nice to see that the project inspired improved solutions like yours. I'm specially curious about the last bit: how the inverse subscription order can guard against noop errors. Gonna take a close look to that 👍

[kristapsPelna]

@jhonnymichel Regarding the subscription order, here is a simple example:
Parent has a child. Both use the same hook. Parent does a check to render child or not based on the store data.
With regular order what you get is:
Parent subscribes as its being rendered, then child subscribes.
Store updates and triggers rerenders. Parent rerenders, conditionally now doesnt render the child at all. Child renreder triggered by the store update and we get a noop warning because we are trying to render an unmounted child.

With the inverse order we dont get the noop, because the deeper the child, the earlier it gets the rerender, and the parents that can conditionally not render them (or change router route) get a rerender after them.