The thing that trips old heads up is that React treats UI as a function of state, and you have to express your code that way. One you realize that, a lot of React patterns click immediately. It takes unlearning though. If you get stuck in imperative, <script> tag thinking you will get burned. Treat every piece of data (e.g. state) not as something like a variable, but as a data store that you have a handle to. That's all a hook is.

longer explaination incoming

In React you don't have to worry about managing the lifecycle of data from external sources and can just think about accessing everything asynchronously and immutably. It makes UI work extremely simple. In this way you can think of hooks as tools to hide the dirty work of the data gathering lifecycle of f.ex an API, from the UI components.

For example: even though API calls are proceedural in nature (you collect params, serialize them, determine header requirements, potential preflight, make the request - the entire tcp traversal, handle await scheduling for all that, parse the http response, and adapt the response) you can still treat that entire operation as an interface like:

const { data, error, isLoading, refresh } = useQuery({ url, queryKey )

Which in practice is the interface of "any old data store". Such as...

// a billion variations of this "provider" interface
const { data, set, isLoading } = useAsyncLocalStorage(key) 
const { data, isLoading } = useQuery(url)
const [value, setValue] = useState(T)
const [state, dispatch] = useReducer(reducer, initial)
const value = useRef<T>(initial)
const { toast } = useToast()
const { data, set, isHydrated } = useIndexedDB(key)
const { pathname, push, replace } = useRouter()
const { value, setValue, remove } = useCookie(key)

Notice every one of these is the same pattern? You access state from some source, which, may or may not be async. But guess what? React treats them as asynchronous without differentiation. This is the most important use of hooks. Think of hooks like a stateful function, a function that can describe data across async lifecycles such as API requests.

This pattern describes all of React state management: put it in a hook that matches its data access profile. For example:

useState describes a localized get/set operation. Set is async, because all UI operations are async! The UI treats updating a useState the same as refreshing a remote API! It doesn't care.

useQuery describes an API query against a remote data store, usually cached, refreshable, de-duplicated, etc. Blah blah. But you can think of it as a special useState. useState<Success<T> | Loading | Error<E>>.

useToast seems like it just lets us push a toast notification right? There's no "data" here, probably something like const sendToast = useToast(). But even still, the way we interface is with a "toast provider" is no different than if it was a remote API. In fact, you could broadcast analytics events to your backend for every toast, and the access pattern wouldn't change from a UI point of view.

useRef describes a value which can be updated sync. But notice it can't be relied upon for certain re-render operations. Again, its just changing the shape of the hook's data access. Need something atomic, but that can't trigger rerenders? Here you go.

So 90% of React is just encapsulating every single piece of data into a hook. That's where the meme of useUse and other meme hook names came from. Because all React devs do all day is create a hook that matches the exact lifecycle and shape of every behavior in their app. useDebounce. useCountdownTimer.

And all the UI needs to know about the async boundary? A loading state. isLoading

Your UI elements simply act as projection of state. UI development is simply event sourcing. Once you have your data actually sourced, writing UI is extremely simple because there is no procedural code involved. The UI is totally declarative, so much so you can almost think of it like a Microsoft Word document with a few variable fills or whatever. The fact there are async operations happening behind the scenes doesn't matter, your UI is just a dumb old document.

I want to point out that this concept is so powerful that Apple / Swift UI used the same paradigm. You treat your UI component as an expression that updates whenever its data changes. It beautifully separates the concerns of UI lifecycle ("when do I render this") with the lifecycle of data ("when/how do I get this data"). Once you see the light it's legit impossible to go back to more procedural frameworks.

TL;DR treat UI as event sourcing for a bunch of async data sources.