How do we help the community better understand "side effects" and consequences beyond "rules"?

[markerikson]

I just responded to a couple different discussion threads were people were very unclear about what might happen with the idea of "side effects" in the wrong spot:

• https://www.reddit.com/r/reactjs/comments/nzbbef/isnt_this_tutorial_by_tanner_linsely_wrong/ : writing to a ref while rendering in a useClickOutside hook
• useReducer's dispatch should return a promise which resolves once its action has been delivered react/react#15344 (comment) : potentially doing side effects in a useReducer reducer to avoid dealing with useEffect

In both cases, they understood that "side effects in renders or reducers" is wrong, but they didn't have a good understanding of what problems could happen and why. It's like there's a big box marked "SIDE EFFECTS 💣", and they assumed that the instant the box was poked, the entire app could explode. Instead, it's a lot more nuanced - stuff won't immediately break, might not have anything break, or it could be a subtle bug down the road.

I'm not sure how to explain this or get people to think about the potential implications here. The rules exist for good reason, and in a lot of ways those blanket prohibitions exist to help warn people off even if they don't understand the nuances. Still, it feels like people would benefit from having some explanation and guidance for how to actually think their way through potential problems here.

(Yes, I realize the real problem here is the word "think".)

[jbachhardie]

I've had this conversation a lot with developers, some of whom don't even have a good intuition of what counts as a "side effect". I've found an approach similar to the one you've taken in those responses useful: "you have to assume these functions could execute more than once per change, so you can't view the fact that it's executing as evidence that a change has happened and it should behave the same way with the same input no matter how many times it executes". A lot of the time this leads to the follow-up of "why did React decide to do this? Why not have things execute strictly once per change?" and you have to get into the UX advantages of cascading updates and interruptible renders but whether they end up thinking this is a worthwhile thing to have to worry about they at least have the useful heuristic of "I have to be OK with this happening any number of times at any time"