i think i might have first heard this from Ryan Florence. the idea is that code is often garbage, but react components are nice because they divide that garbage into boxes that are individually replaceable.

it's easy to delete a react component, to fork it, to inline it, or to rewrite it from scratch. generally you only need to reason about the code locally. as long as your component tree design (where the state lives and how it flows down) models reality well, the specifics of the code inside every box don't matter much. worst case, some monster 10 kloc component sucks, and eventually somebody rewrites it. for the rest of your codebase, it's just a collective shrug.

this is also my philosophy applied to slop code.

i think it is completely true that slop is fucking with quality everywhere. i think that's bad. but i've also been able to make incredible progress on things i wouldn't bother picking up before.

so i'm trying to find a balance.

what generally seems to work well for me is to try to create broadly sensible layers with the right constraints on them, but then allow slop within those layers. some slop is okay, but some is not:

• i care about how data flows through the system, what's derived from what, inputs and outputs, anything that gets stored

• i care about the final experience. noticeable bugs, bad perf, and inconsistent behavior are bad and need looking into

• i care about misuse of fundamental abstractions. if it's doing react wrong or database wrong etc, that's bad

other than that, i don't care that much what's in the boxes. it could be overly verbose, it could be under- or over-abstracted, it could be inelegant or amenable to cleanup, it may be just kind of dodgy. but if it works well at the leaves and it is constrained at the edges, i'm just not too worried about the middle management.

if it's easy to rewrite and it doesn't hurt the user, it's fine.