Post

Reading through this is both fascinating and horrifying. It's hard not to start feeling like working with React is like being in a relationship with a partner who's gonna blow up at you if you say things the wrong way or with the wrong tone of voice and expects you to read their mind.

Corbin Crutchley@crutchcorn.dev

Working on @tanstack.com Form's React Compiler support has taught me a lot about adapting libraries to support it. Here's what I've learned: playfulprogramming.com/posts/react-...

1 repost2 likes

Mixed thoughts here on my end. React has been remarkably consistent for its ~10 years building out its future: playfulprogramming.com/posts/react-... But yes, compiler introduced some heartburn for me. Mostly around comms and docs (learning panicThreshold came too late) Overall, net positive imo

playfulprogramming.comThe History of React Through CodeLearn React's history using pragmatic code samples and deep dives. This journey reveals the consistent design in React's APIs stemming from the very beginning.

There are two aspects: the rule & how we enforce. The rule is simple: don’t mutate stuff that crosses JSX/hook boundaries. You almost certainly follow this ~all the time, else you would have crazy bugs. What feels and is more complex is that we can’t statically catch all violations of this rule.

The parts of the post describing subtle nuances are about which specific ways of breaking immutability the compiler does/doesn’t catch. But developers don’t need to remember which way of crafting an error will be caught or not! They just need to remember the rule, which is straightforward.

I'll also add that 99% of app written code should never hit what I described in OP Were TanStack Form not multi-framework the likelyhood that I hit these would be very very low because I'd structure my code differently