I agree about that specific patterns post being a bad example... but if you google for "react patterns" you won't be starved for examples of more terrible drivel. That's just what's out there, people repeat it ad nauseam. So _good luck_ to anyone who really does want to learn the right thing. From that standpoint, that article is as good or bad as most others out there (old man shakes fist at dev.to).
Even the venerable libraries like useQuery introduce as many surprises as they do benefits. The complexity cost of understanding what is going on under those 20 LOC is quite high – you need to understand "stable values" (which is only relevant to React components), re-renders and how they're triggered, maybe need to understand how graphql fragments are collated into one query document... maybe need to know when useRef is the right way to memoize over useMemo.
I agree with the author, that it feels insane. I would even add to the insanity the lack of quality when searching for help, and the weird rabbit holes that GPT can send you down if you don't already know what "good" looks like.
Yes, it's bad code, and aren't we all having fun laughing at the anonymous dev who wrote it.
However, I've seen this kind of code in the wild, and I'd be shocked if you hadn't, too. _Who_ wrote it matters a lot less than the fact that _so many people_ write it. I think that React has optimized for developer velocity, but the primitives make it so easy to shoot yourself in the foot, that in a large codebase with lots of devs, it becomes hard to avoid.
I was one of the Ello devs (mobile, then web, then backend, then all of it).
My guess is that you'll have some diehard fans early on - Ello did, and they stayed to the end (thanks!) and they'll bemoan every single change - just roll with it, trust yourself but also listen to them.
If you get some success you will have a spammer problem (esp porn), but if you limit (better: don't have) public feeds maybe you can avoid the worst of this. Mutual follow makes sense as a way to limit the blast radius of bad actors, but then people will get spammed by friend requests. It SUCKS. Maybe you punish accounts that blast lots of requests but get very few follows back. We did something like this.
Actually one idea that I think would work well: once you have a "this is a spam account" determination, hide those spam accounts from real users, but let them engage with other spam accounts. This will cost you some compute time, but it will give them the feeling that they are being successful without distracting users.
Even the venerable libraries like useQuery introduce as many surprises as they do benefits. The complexity cost of understanding what is going on under those 20 LOC is quite high – you need to understand "stable values" (which is only relevant to React components), re-renders and how they're triggered, maybe need to understand how graphql fragments are collated into one query document... maybe need to know when useRef is the right way to memoize over useMemo.
I agree with the author, that it feels insane. I would even add to the insanity the lack of quality when searching for help, and the weird rabbit holes that GPT can send you down if you don't already know what "good" looks like.