Nice article and working on refactoring a simple app away from prop drilling.
In your example, you're only managing a single state attribute but to use another example, what if I needed to track 15 attributes/object in global state. Is the expectation that I would need to declare the 15 object properties and associated update functions in both the user context and the user provider? Are there other techniques where I could create a single object and then update that object on a property by property basis (aka nested object compared to a single object property)?
I know there's a valid reason, I'm just failing to grasp why we have to define the UserContext props and methods in the UserContext object. Is that essentially enforcing the structure that get's implemented in the provider? Basically wondering why there is this "write twice" approach.
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.
Hey Sunny,
Nice article and working on refactoring a simple app away from prop drilling.
In your example, you're only managing a single state attribute but to use another example, what if I needed to track 15 attributes/object in global state. Is the expectation that I would need to declare the 15 object properties and associated update functions in both the user context and the user provider? Are there other techniques where I could create a single object and then update that object on a property by property basis (aka nested object compared to a single object property)?
I know there's a valid reason, I'm just failing to grasp why we have to define the UserContext props and methods in the UserContext object. Is that essentially enforcing the structure that get's implemented in the provider? Basically wondering why there is this "write twice" approach.