Although I agree that there's a lot of magic in the hooks API, and that magic is Bad, I think there are some characteristics that alleviate these concerns for me.
The first is that we should consider the amount of magic we're living with today. We're not supposed to define callback props inline. When writing event handlers, we're supposed to remember to add a constructor to our component, and to bind our callbacks to `this` in them.
All that is magic: things that aren't obvious from the syntax, but which require understanding how things work behind-the-scenes. For all the magic hooks introduce, they also allow you to do away with some.
The second point is that we should consider why magic is Bad, and whether that still applies with hooks.
Magic is bad because it leads to your code behaving unexpectedly, and when that happens, you cannot reason about your code in order to find the bug - you have to resort to reading the documentation.
Yes, hooks have some magic caveats - only call them in function components and from other hooks, always call them in the same order - but given the use cases of hooks I have seen so far, complying with these caveats is natural.
In other words: the use cases for hooks do not seem to include wanting to call them inside loops, or nested functions. Hence, hooks will do what you expect, and should not hinder your ability to reason about the code.
Of course, it's still early days, and we'll see whether that assumption holds. For now, though, I'm leaning towards looking forward to the addition of hooks. Stateful logic is messy, especially in Javascript, and hooks seem like a relatively clean way to deal with that.
The primary concern I still have is a naming convention (`use<HookName>`) being a naming _requirement_. This feels eerily like Angular.js's custom parsing of stringified functions to determine what dependencies to inject.
Things like that are what pressured the Angular team into doing their rewrite, when Javascript added official syntax to do the things they wanted to do.
That said, if and when such syntax arises, it is probably possible for React to gradually transfer to that, and the React team has so far been good about making it manageable to do so painlessly.
Besides, as a TypeScript user, I expect tslint will even be able to warn be about incorrectly naming a hook :)
