personally I find the default hooks that React provides lacking for things like data fetching and navigation. I would not want to write those things in hooks myself if I was focusing on a project

there are 3rd party hooks, like swr and react-query, which help with data fetching

I haven't used them with clojurescript yet but that's what I would look at in a green field project

for things like navigation, I would use https://reactrouter.com/

Hey lilactown thank you for your answer ! That's interesting, indeed I've heard about react-query already and you are right that may be a good idea for data-fetching. I forgot about it but I'm taking note 🙂 And would you use a global state for your application? Let's say if you have an auth state with all the informations of the currently logged in user?

it's hard to answer your question because it contains within it ambiguities. i.e. there's a difference between "auth state" and "all of the informations of the currently logged in user"

a way to think about state, where to put it, what kind of container to use, is to think about the "lifetime" of the data - i.e. should this data be invalidated when the component unmounts, or when the user reloads the app, or when I navigate to a new screen in the app...

so authorization: the lifetime of e.g. a bearer token is tied to the users session so will probably persist for at least as long as the user is on the page. we may need to update it periodically depending on some token refresh schedule, but not often. we can easily store this either in global state of the page, refreshing when needed, or in local state of the root component and shared via context.

all the information of the currently logged in user: sounds like it could change fairly often, probably in accordance to user actions and based on remote events. should be refreshed often, so as to show the user the most up to date view, but we also shouldn't invalidate or evict the data as soon as it's no longer on screen, as fetching new data may take time. so we shouldn't tie the lifetime of the data to one component. I would store it in some global cache that is managed through some hooks that understand how to populate and subscribe to it, i.e. react-query

for an example of data that I would store in local component state, take an example of whether a tooltip should be shown, or an accordion collapsing/expanding. in this case, the data that controls whether we show or hide some content shouldn't outlive the component, so it makes sense to store in local state

hope that helps! 😅