4. Typically simplifies useEffect by removing unnecessary dependencies
5. Centralizes state writes, which is often easier to understand
6. Elegantly handles related state (Note you can also use objects with useState to compose data that changes together)
7. Can easily store the entire state tree in localStorage
8. Can pass dispatch down to avoid passing many callback funcs on props
9. Can easily log all actions since they're centralized
10. Moving state management to a separate file makes the component easier to understand.
useReducer decouples update logic from describing what happened. This helps remove unnecessary dependencies from effects and avoids re-running them more often than necessary.
If you find yourself passing multiple callbacks down via props, consider refactoring to useReducer.
Then you can just pass dispatch down instead. 👍
• • •
Missing some Tweet in this thread? You can try to
force a refresh
1. You don't have to return an HTTP 400 and force the user to update their browser. The API can reply with a successful request instead (like an HTTP 205), or include an "x-stale-ui" header in the response to notify… twitter.com/i/web/status/1…
As a consultant, I work with dozens of teams. I see massive differences in developer output.
Here's an example on the same team:
Dev 1: 45 PRs/month
Dev 2: 1 PR/month
I did code reviews. Dev 1 had higher code quality too.
And yes, stats can be gamed. So, I don't recommend managing based on stats. But when stats are wildly lopsided, there's often a root cause worth exploring.
In this case, the dev who completed 45 PRs had many PRs that were more complex than the 1 PR merged by the other dev.
A related law:
Price's law: 50% of the work is done by the square root of the number of employees.
So:
If you have 10 employees, 3 do 50% of the work.
Continuous integration:
✅ No PRs
✅ No branches
✅ No gating code reviews
✅ Commit directly into trunk
Frequent Integration:
✅ Small PRs
✅ Simple, short-lived feature branches
✅ Code review before merge
✅ Merge branches ~daily
Frequent integration is often good enough.
For many teams, "frequent integration" is the sweet spot.
Doing code reviews before merge assures reviews actually happen. (you can pair, but few devs do consistently, and outside reviews are useful when pairing too)
Integrating work approximately daily is frequent enough.
In summary, truly Continuous Integration is rarely practical. That's why it's rarely practiced.
It requires a very mature team:
Fast CI
High trust
Frequent pairing
Robust feature flags
Superb test coverage
Consistently high code quality