You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm curious why the default strategy was to not maintain previous result state? For nearly all my applications api calls, it looks something like
const [users, setUsers] = useState(undefined)
const [loading, setLoading] = useState(false)
async function getUsers() {
setLoading(true)
try {
// to get behavior like react-async-hook, i'd add a `setUsers(undefined)` here
const users = await GetUsers()
setUsers(users)
} catch (err) {
setUsers(undefined)
}
setLoading(false)
}
What is gained by unsetting the result early? We already know when we are in a loading state so that we can choose to not render the old results if desired.
Improvement suggestions
Design questions aside, I'm wondering if
A descriptively-named option ({ maintainState: true }, { resetResultOnLoading: false }, ...) could be added to do setLoading: state => ({ ...state, loading: true }), because really, I don't want to mess with any loading states, which this appears to do at first glance
It would be great if options (like setLoading) could be more officially documented. I'm proposing using this library to my team, and I know when they see the setLoading option, they're going to be curious about what's happening there, then go to readme, and see it only within a code example.
The text was updated successfully, but these errors were encountered:
You are right that maintaining the previous state should be the default behavior, and will likely change it and document it better for a version2 with some breaking changes like this.
If you have intentions of publishing a beta before a v2, let me know here in case there are other enhancements that you have planned and need someone to test out those changes in their working application..
First off, thanks for your work this project. Super lightweight and I'm sure is going to simplify my code a lot! 🙇 🙏
Question about default strategy for state inbetween calls
I'm curious why the default strategy was to not maintain previous result state? For nearly all my applications api calls, it looks something like
What is gained by unsetting the result early? We already know when we are in a
loading
state so that we can choose to not render the old results if desired.Improvement suggestions
Design questions aside, I'm wondering if
{ maintainState: true }
,{ resetResultOnLoading: false }
, ...) could be added to dosetLoading: state => ({ ...state, loading: true })
, because really, I don't want to mess with any loading states, which this appears to do at first glancesetLoading
) could be more officially documented. I'm proposing using this library to my team, and I know when they see thesetLoading
option, they're going to be curious about what's happening there, then go to readme, and see it only within a code example.The text was updated successfully, but these errors were encountered: