What do you think about keeping this context 'pure' meaning it doesn't really dictate UI at all? Then we could expose isLoading and isError and the consumer could handle those UI changes. Benefit would be keeping our UI all in one place so folks opening up that page component can see how it's handled at first glance, without having to dig into the context.

Not sure if I got it. I don't see too much value on having it pure since the value, from what I see, is to have a provider that handle that in one single place but maybe I'm missing something. I based this provider on https://kentcdodds.com/blog/authentication-in-react-applications

I think in that example, he's showcasing functionality instead of organization, but I'm happy to talk it through in Discord. It's also not a blocker.

Interesting. I'm usually agnostic about where to put these, but I don't know if I've ever seen a provider render a spinner. But I see that Kent really does it intentionally:

  // 🚨 this is the important bit.
  // Normally your provider components render the context provider with a value.
  // But we post-pone rendering any of the children until after we've determined
  // whether or not we have a user token and if we do, then we render a spinner
  // while we go retrieve that user's information.```

Hmm, I could see that. I was looking at his comment below:

The key idea that drastically simplifies authentication in your app is this:

The component which has the user data prevents the rest of the app from being rendered until the user data is retrieved or it's determined that there is no logged-in user

So I figured the component is the consumer of the context, and it should have something like this:

const {isLoading} = useAuth()

if {isLoading} return <Loader/>

return (
 <App />
)

I guess this is an argument for colocation, kind of similar to what we were discussing with long files. But just because it isn't a pattern I've seen before doesn't mean it's wrong! I'm happy to keep the loaders in the context.

But just because it isn't a pattern I've seen before doesn't mean it's wrong!

I agree 100%. In this case, I just think would be too much to have another component to handle the spinner. If at some point it starts to do more and more stuff, I think would make sense to split it.