For example recently I wanted to use a promises in React app. I mean: promises are as native to JS as it gets. Surely React should have first-class support for promises.

Nope.

So I started to write custom hook. usePromise. Like useEffect, but for promises.

Well, it would not be hard. But apparently React likes to call useEffect twice for dev mode. So I need to have a reliable cancellation. How do we cancel stuff in web? With AbortController, right. Does React heard about AbortController? Nope. So I need to integrate AbortSignal within my usePromise hook. I read famous Dan Abramov article, I read other articles, I spent days tinkering around this thing, I wrote several implementations.

All of those implementations are faulty.

Here's my latest one: https://pastebin.com/WBctCBpc. Technically it works. But it contains unpure reducer function. It's not broken in current React version. But who knows how react dev mode will torture my reducer in the next version.

I have to admit that I enjoyed toying with this stuff. But it definitely counter-productive to business values.

Now I know that this is all solved and I should just use react-query or something similar. Well, I have my reasons to avoid it. But my point still holds: React is hard, React is not well integrated with JS and Web. And probably React will get better in the future. I've heard about suspension stuff which might just be what I need, but it's not there yet.

Context was never a systematic answer. Even today the docs say:

  Apply it sparingly because it makes component reuse more difficult.

  If you only want to avoid passing some props through many levels, component composition is often a simpler solution than context.

And IIRC older docs would be even more harsh at recommending not to use context.

If you are building the average mobile app it is often really clear when you are writing code what needs to be updated in the UI when a piece comes in.

If you are building something more like Adobe Photoshop or Eclipse the user has the ability to open up property sheets and create other UI elements that could be affected by data structures anywhere in the application. In that case you need some systematic answer such as components registering to get notifications when something happens but you can run into some pretty bad problems such as having to hang on to references which keep the garbage collector from working as expected. My first SPA was a knowledge graph editor in GWT that I managed to get correct (though it probably leaked memory a little) and since then I haven't known whether to laugh or cry about the state of SPA frameworks.

As for the manuals I think the React manuals are some of the worst in the business. I have no problems finding answers in the Java manual or the Python manual or the Postgres manual or many others but the React manual baffles me.