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
Copy file name to clipboardExpand all lines: content/articles/when-a-simple-react-context-gets-out-of-hand.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -126,7 +126,7 @@ This is fairly simple. We can just throw in a `useEffect` and boom.
126
126
127
127
Now let's say for testing purposes we want to add initial{SelectedPost and SelectedComment}. Stupid simple. Or is it?
128
128
129
-
The way we currently have it set up, the useEffect will set our `initialSelectedComment` to null on the first render. OOOO no a side useEffect!!!
129
+
The way we currently have it set up, the `useEffect` will set our `initialSelectedComment` to `null` on the first render. OOOO no a side useEffect!!!
130
130
131
131
So our context then turns into:
132
132
@@ -212,7 +212,7 @@ Not a huge win IMO, but now the team is happier.
212
212
213
213
After working with React hooks for a year, I've come to the conclusion that `useEffect` in a context is probably a bad idea. (I'd love to see examples where you've made this work BTW).
214
214
215
-
A more concrete rule that I've landed on is that we should not have a useEffect in our app that relies on global state. I kind of see this a sharp knife that could easily poke your eye out. It raises the barrier to work on a project for people that don't work in the frontend day in and day out. Even for someone working in the codebase, it's something they always have to keep in the back of their mind. "If I change {X}, this callback will run, and do I need to modify it?".
215
+
A more concrete rule that I've landed on is that we should not have a `useEffect` in our app that relies on global state. I kind of see this a sharp knife that could easily poke your eye out. It raises the barrier to work on a project for people that don't work in the frontend day in and day out. Even for someone working in the codebase, it's something they always have to keep in the back of their mind. "If I change {X}, this callback will run, and do I need to modify it?".
216
216
217
217
My solution to this is to always (well prolly 95% of the time) use `useReducer` in global state and to never have a `useEffect` depend on a piece of global state.
218
218
@@ -229,7 +229,7 @@ const initialState = {
229
229
};
230
230
```
231
231
232
-
Well, that was easy enough! Defining our initial state lets us see all of our global state at a glance. Any time we want to add something to our global state, we can start by adding a sensible default to our initialState object. For example, `isLoggedIn` is initially false, and `posts` is initially an empty array.
232
+
Well, that was easy enough! Defining our initial state lets us see all of our global state at a glance. Any time we want to add something to our global state, we can start by adding a sensible default to our `initialState` object. For example, `isLoggedIn` is initially false, and `posts` is initially an empty array.
0 commit comments