Indeed, no hooks mentioned on that page, though. Also, on first glance, that looks like trivial integrations.
Ah, I also forgot to mention, what I'd like to see is more documentation on how to hide an imperative API behind a more declarative React/Angular etc. API. That's not always trivial but often what you want.
I think it's especially important because while you often can find ready-made wrapper for popular pure JS libraries they are usually abandoned (and thus don't keep up with the latest versions) or have some flaw that bites you sooner or later. My current recommendation is to write your own wrapper unless the wrapper is an official one of the authors of the underlying JS library. Naturally, that's not always feasible for complex libraries, but matter of fact you don't always need the full functionality of that library so you only have to wrap what you need.
I completely agree -- I've been bitten a few times using React wrappers that turn out to have subtle flaws or are unmaintained. Generally I just write my own wrapper with some clunky combination of hooks to manage the lifecycle of data.
One common pattern I end up using for a lot of imperative calls is a "useAsyncFunction" hook which runs any async function, returns state for loading, error, and the result of that function.
Unfortunately each library handles DOM manipulation, configuration options, callbacks, instantiation, etc. in its own way, and so I don't think there's any generalized solution.
Ah, I also forgot to mention, what I'd like to see is more documentation on how to hide an imperative API behind a more declarative React/Angular etc. API. That's not always trivial but often what you want.
I think it's especially important because while you often can find ready-made wrapper for popular pure JS libraries they are usually abandoned (and thus don't keep up with the latest versions) or have some flaw that bites you sooner or later. My current recommendation is to write your own wrapper unless the wrapper is an official one of the authors of the underlying JS library. Naturally, that's not always feasible for complex libraries, but matter of fact you don't always need the full functionality of that library so you only have to wrap what you need.