Is this context architecture too much?
Hello, I've just recently started using the Context API and I seriously couldn't find what's the most mainstream way of creating and using the context, but I found this architecture pretty understandable and I've been using it, but I feel like it's too much boilerplate? What do you guys think?
13 Replies
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
I don't know. I believe, in the video, it was done so that it could just be called with a hook, avoiding importing the api and the type?
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
This is pretty much exactly what I do when I set up context hooks. My only criticism here is your naming conventions. If you are always dealing with results use the word 'results' and not 'result'.
useResult is probably a variable not a function that returns a variable
Unless you are going to have addResult in more than 4 places I wouldn't even bother with that syntactical sugar could end up being more lines of code defining it than using it.
I did check this a while back passing the setter and other functions in a hook does not cause renders to subscribed consumers only change in the state object does. Which is super handy.
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
What I mean is you can have components that only consume setResults and not results and they will never rerender when results change
Makes this pattern worth while
Well this was the case last time I checked hope it hasn't changed with react 18 anyway
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
First without context consumer components everywhere, still with this hook and a single in provider wrapping the entire app only subscribed components using this hook will be rerendered. Not only that if you pass the setter not the state object they will never re-render. It's an awesome pattern I use it everywhere
I set mine up like this too whenever I need them
Always wondered if that was a best practice thing actually
I have about 5 or 6 wrapping providers at app level and 140 components of which at least 100 of them pull something from these context hooks this way and I haven't noticed any performance issues and I get an awesome developer experience out of it. I'm sold.
I love having people to talk to with this stuff there is literally no one at work that would understand what the hell I'm talking about
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
I think as react developers we have a tendency to over optimize before it's really needed which can add complexity, a case point is people abusing memo and use memo and use callback when it's often more efficient to trust react without them. Until it becomes a problem I wouldn't try and architect solutions.
Every product is different obviously you do what is right for you in the context of the original question I'm a big fan of this pattern it has served me well.
Got it, thanks guys. Sorry I've been busy and couldn't check it earlier