| In my experience React codebases turn into this mess for two reasons: - front-end devs don't know how to think declaratively and think in terms of state transitions instead of realizing intent - back-end devs build a classic REST-like API which provides zero affordances to drive a proper reactive front-end. React-query is a good solution to the wrong problem. It's basically an elaborate and ornate footgun that allows you to stretch guess-based cache invalidation to its limits. Each piece of data has to be tagged with front-end only query keys, and cache invalidation requires you to re-implement and repeat your business logic optimistically in all the individual `onMutate` and `onSettled` handlers. The actual problem to be solved is how to reliably sync data to a front-end and mutate it safely. Doing this well requires you to architect your data so it is syncable in the first place. You should separate sources of truth from derived data, you should use uniform APIs for CRUD manipulation, you should probably version your records, you should express mutations as universal patches, and so on. Cache invalidation should only require substituting one globally addressable record with another one, and/or telling the front-end to refetch it from the source. If you are doing complex data surgery or traversals, you're doing it wrong, because that's what the reactive rendering is supposed to do for you. Anything else is a trap for juniors. |
There is a thing among park rangers where “if people are taking this shortcut despite the signs and fences, then it’s the trail that’s wrong, not the people”.
More software engs should think this way instead of “educating harder should solve incompetence”.
It’s not that people are incompetent. The trail is wrong.