useDogProviderState will never throw because even if there is no DogDataProvider above the component, React.useContext(DogDataProviderContext) will return the default value initState
If anyone is interested, I rewrote the Flexible Compound Components example with functional components instead of classes: sandbox
Thank you for pointing this out. I have updated the article with changes to Provider Pattern and added examples for Compound Components and Flexible Compound Components with functional components.
Actually the purpose of useDogProviderState is to make sure that the consumer of the DogDataProviderContext will be under the DogDataProvider in the React tree in order to consume the value provided from the provider. They would not want something like: const App = () => <Profile /> :D
Actually there's a discussion about this on Twitter: twitter.com/kentcdodds/status/1125...
Thanks for this! I have just recently began building a project which basically uses the Compound Component pattern exclusively. Of course it might be overkill, but it was useful for me for learning purposes. Its hard to see the real value of Compound Components until you actually get your hands dirty and try building them out, but it gives you such granular control over the component and exposes a much more readable API to work with.
Great article and thanks for taking the time, really nice read.
This could inevitably cause performance problems, because the passed in object to the value prop will be re-created every time a child component re-renders even if the values in the object haven't changed. DON'T DO THIS
Do you have any real evidences of any issues here?
Before reading this, I had a problem implementing infinite scroll with react-virtualized.
Now, I get a insight from this article :)
Thank you for leaving a post.
Alexi, great article, very timely for me as this is just where I am at in my react learning even though I'm a seasoned (old) developer.
Also, the RadioImageForm is very timely because I have also been looking for how to accomplish exactly what that does. Your code doesn't mention any license for the samples in the article. Is this available under any open source licensing?
About this opinion about Provider Pattern vs state management library "there is no need to over-engineer the problem. Introducing a state management library creates a lot of repetitive boilerplate code, complex flows that other developers need to learn", I would say Provider Pattern is a complex flow and have many edge case and you had to do it carefully, or you have a nightmare with re-render without knowing where is the cause
useDogProviderStatewill never throw because even if there is noDogDataProviderabove the component,React.useContext(DogDataProviderContext)will return the default valueinitStateIf anyone is interested, I rewrote the Flexible Compound Components example with functional components instead of classes: sandbox
Thank you for pointing this out. I have updated the article with changes to Provider Pattern and added examples for Compound Components and Flexible Compound Components with functional components.
Actually the purpose of
useDogProviderStateis to make sure that the consumer of theDogDataProviderContextwill be under theDogDataProviderin the React tree in order to consume the value provided from the provider. They would not want something like:const App = () => <Profile />:DActually there's a discussion about this on Twitter: twitter.com/kentcdodds/status/1125...
This is a wonderful article, lots of examples and notes.
Thank you for your efforts, I learned a lot of patterns.
Thanks for this! I have just recently began building a project which basically uses the Compound Component pattern exclusively. Of course it might be overkill, but it was useful for me for learning purposes. Its hard to see the real value of Compound Components until you actually get your hands dirty and try building them out, but it gives you such granular control over the component and exposes a much more readable API to work with.
Great article and thanks for taking the time, really nice read.
awesome, l learned a lot from this article.
Do you have any real evidences of any issues here?
Before reading this, I had a problem implementing infinite scroll with react-virtualized.
Now, I get a insight from this article :)
Thank you for leaving a post.
Nice article
Alexi, great article, very timely for me as this is just where I am at in my react learning even though I'm a seasoned (old) developer.
Also, the RadioImageForm is very timely because I have also been looking for how to accomplish exactly what that does. Your code doesn't mention any license for the samples in the article. Is this available under any open source licensing?
About this opinion about Provider Pattern vs state management library "there is no need to over-engineer the problem. Introducing a state management library creates a lot of repetitive boilerplate code, complex flows that other developers need to learn", I would say Provider Pattern is a complex flow and have many edge case and you had to do it carefully, or you have a nightmare with re-render without knowing where is the cause
Wow this is like a all in one guide! Amazing write-up!