> Also, that loading boolean seems unusually variable for a constant.

Like any other constant, it never changes during the lifetime of its scope (a single function invocation) but can be different during different invocations. (The initialization by the useState function, though, is somewhat magical, involving external knowledge of whether this invocation is rendering a new instance or rerendering an existing one.)

So where the article says

  loading // true
  setLoading(false)
  loading // false

they mean that it will become false in the next invocation of the render function, I hope?

That's exactly what the setter function returned by useState does, it sets the value returned the next time the corresponding useState is run for the same component (it is order based, which is why hooks must be run in a constant order.)

They basically invented a new programming paradigm. You’re not familiar with it so it doesn’t make sense. But it actually more closely matches what’s really going on, so it’s more straightforward to someone familiar with how React works. The class-based API did not closely match how React actually works and so led to various common bugs which don’t occur anymore with the hooks API. You do have to learn the paradigm, but having done that you understand a lot more what you’re doing. This would probably be clearer if it were just a new programming language instead of being shoehorned into Javascript—then it wouldn’t seem so weird to be learning a new paradigm.

> But it actually more closely matches what’s really going on, so it’s more straightforward to someone familiar with how React works. The class-based API did not closely match how React actually works and so led to various common bugs which don’t occur anymore with the hooks API.

I see this said a lot, so what's really going on that the class API obfuscates?

It isn’t perfect but this is probably the best explanation that I know of https://overreacted.io/a-complete-guide-to-useeffect/