Great article, it's not easy to find a complete overview of this topic so it's a very valuable resource ❤️
You made me discover the useContextSelector idea and it's a pretty neat one ! In the other hand, it would be pretty easy to make a mistake in the selector & miss some important updates.
To my eyes, it justifies using redux for application wide, frequently changing contexts and something like react-query for payload management.
About creating specific "CustomProvider" and "custom hooks" to manage the context, some third-party libraries have their own "createContext" util that does both at the same time in a generic way, see chakra-ui createContext util for instance 👍
Last but not least, you end your article with "atom state management" libraries option, what's your take on using those ? Would you do it in your own codebase ?
Thank you again for your thoughts & explanations 🙏
Developer: javascript, typescript, React, ... I love to discover new things, exploring code of libraries and understand how things work.
Fan of creative hobbies :)
I think I'm missing something about "the missing updates" you're talking about, because, for me, the component get the right data and subscribe to its changes thanks to the right selector and useContextSelector, and will be notify to changes corresponding to this data. So if it misses updates, it would probably mean there are problems in the code otherwhere that do not update the data. Am I missing something ?
Ah nice, I didn't know that some library were providing their own "custom hooks". Thanks for the info.
Yep I would also use a library for data fetching like react-query / swr, ... And would definitely give "atom state management" a try when I want to share data between sibling components. In next articles, I will show how to use some of them and talk about their implementations :)
I took more time to read the use-context-selector API, no you are not missing anything - I was 🤭. I thought the second parameter was to define a "key" that would be used to decide when to re-render, but it is instead really a value selector.
Looking forward your next articles then ! :)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Great article, it's not easy to find a complete overview of this topic so it's a very valuable resource ❤️
You made me discover the useContextSelector idea and it's a pretty neat one ! In the other hand, it would be pretty easy to make a mistake in the selector & miss some important updates.
To my eyes, it justifies using redux for application wide, frequently changing contexts and something like react-query for payload management.
About creating specific "CustomProvider" and "custom hooks" to manage the context, some third-party libraries have their own "createContext" util that does both at the same time in a generic way, see chakra-ui createContext util for instance 👍
Last but not least, you end your article with "atom state management" libraries option, what's your take on using those ? Would you do it in your own codebase ?
Thank you again for your thoughts & explanations 🙏
Thank you :)
I think I'm missing something about "the missing updates" you're talking about, because, for me, the component get the right data and subscribe to its changes thanks to the right selector and
useContextSelector, and will be notify to changes corresponding to this data. So if it misses updates, it would probably mean there are problems in the code otherwhere that do not update the data. Am I missing something ?Ah nice, I didn't know that some library were providing their own "custom hooks". Thanks for the info.
Yep I would also use a library for data fetching like
react-query/swr, ... And would definitely give "atom state management" a try when I want to share data between sibling components. In next articles, I will show how to use some of them and talk about their implementations :)I took more time to read the use-context-selector API, no you are not missing anything - I was 🤭. I thought the second parameter was to define a "key" that would be used to decide when to re-render, but it is instead really a value selector.
Looking forward your next articles then ! :)