Enjoying the article so far, but some things make it a bit hard to read. 1) code snippets are screen shots, and 2) some links point to an internal Google Docs page.
This is true as long as you're able to strictly enforce the container-presenter pattern, which is increasingly harder to do as an application grows in complexity.
One key difference between hooks and functions is that hooks tap into some hidden global component registry (I'm being handwavey here but this is more or less what happens). This allows side effects to be persisted and tracked between function calls.
You can probably build all this infrastructure yourself without hooks and only with plain functions. It'll involve some global store and some subscription mechanism. You'll end up with something really similar to Redux.
I've more or less driven frontend development with React at several companies over the last 4 years. While some of the complaints are exaggerated I don't think the overarching premise should be dismissed as "a meme."
> No idea what this promise chaining thing is that you're talking about.
If you have any asynchronous things going on in `useEffect`, you'll have to do something similar to that `await(0)` song and dance in tests. This specifically affects tests if you do things like update the UI by toggling loading spinners on await.
> Redux
s/Redux/higher order components. One of the motivations for hooks was that as a mechanism for logic composition, HOCs just felt awful to use. (So did render props, which everyone suddenly used for everything in a brief moment of collective insanity.)
> Only a superficial understanding of React
I think there's something in this. The fact is that good or bad, 1) hooks aren't intuitive, 2) hooks have basically doubled React's API surface area. Previously, React was so simple that a backend engineer could pick it up and get productive with it in half a week. That's much less the case these days. I've been onboarding devs to React for years, and these days there's a lot more "yeah, that's magic, you don't need to know how that works for now."
I wouldn't necessarily say it's deep equality, it's just a less verbose way of sequentially checking properties. It's not going to check every property.
At least for me, I feel I'd be using this a lot for the boring but common use case of checking for empty arrays and such:
>Google had tremendous experience with containers (they introduced cgroups in Linux) but existing internal container and distributed computing tools like Borg were directly coupled to their infrastructure.
Well, of course. Only companies with fuck-you money can afford the extra bytes spaces take up versus tabs, so it follows logically that they'd pay their developers more.