[nosefurhairdo]

Re: excessive useEffects, this article from React docs is great: https://react.dev/learn/you-might-not-need-an-effect

Re: unrefactorable, large components, you probably want to break these down into smaller pieces. This talk ("Composition is all you need") is an excellent guide on the topic: https://youtu.be/4KvbVq3Eg5w?si=1esmAtrJthois1uf

Re: performance, people overstate the performance overhead of VDOM. Badly performing React applications are virtually always due to bad implementations. React Scan is an excellent tool for tracking down components that need optimizing: https://react-scan.com/

Re: getting other people on the team to write good code, this is the biggest struggle IMO. Frontend is hard because there's a lot of bad ways to solve a problem, and co-workers will insist that their changes work so why invest more time into building things correctly. I've only found success here by first writing an entire feature with good patterns and pointing to it as reference for other teams. People are more willing to make changes if they find precedent in the codebase.

[overgard]

Definitely good points, thanks for the links. While I try to practice all of these, I think what tends to happen on large codebases is just a bit of entropy. Like, these are all good practices that are either a little obscure or a little less convenient, and so they don't tend to be used. I dunno, it's kind of like in OO code when people just keep letting classes grow. I think the subtle difference though is most IDE's are quite a bit better at refactoring classes than components though. Hopefully that changes. (I know you can use AI for refactoring, but I prefer doing it mechanically.. more predictable and also just not burning tokens)