SessionProvider TS error, Hook errors

[mdconn]

I'm quite confused about something. It's a common pattern with NextJS App Router to use a Providers wrapper to put all providers.
Although the docs don't outline this common pattern, it's basically something like this:

const Providers: React.FC<{ children: React.ReactNode }> = async ({
  children,
}) => {
  const session = await nile.auth.getSession();

  return (
    <SessionProvider session={session}>
      {children}
    </SessionProvider>
  );
};

export default Providers;

This works to get some hooks functioning in niledatabase/react. But we're getting a Typescript Error ->
Type 'JWT' is not assignable to type 'NileSession'

That's one thing. The second thing is, some hooks work with this implementation, some don't.
useSession works. useMe and useTenantId both throw an error -->

No QueryClient set, use QueryClientProvider to set one

Can we clarify exactly how to pass the correct session to the SessionProvider? I know about the SignedIn and SignedOut but they cause the same issue, and there should be some more low level explanation for those who want to just use the hooks and the overall SessionProvider

[jrea]

I'll take a look at this. For the first Type 'JWT' is not assignable to type 'NileSession' is probably just a bad cast from supporting both.

The 2nd one there is a bit more nuanced, but comes from some legacy code that (clearly) isn't cleaned up. The QueryClientProvider comes from @tanstack/react-query', which use used to use a lot in the components to make it easy to hook into that lifecycle, but much of that code was removed internally.

I'll update here when I've got it fixed for the new versions.

[mdconn]

I wanted to bring something to your attention because it might be related. I just tested the signOut function. It seems to have correctly destroyed my session on the server.

When I log my session from the server with const session = await nile.auth.getSession();, I get undefined, which is expected.
As well, in my middleware.ts, where I check with const sessionToken = req.cookies.get('nile.session-token');, I also get undefined.

But, for whatever reason, when I use the client-side useSession, it seems to get stuck, and it sort of goes from "unauthenticated" to "authenticated" with an error that I can't see.. here's a picture

My workaround for now is to just use the server components in my SignIn Page but its not ideal

[jrea]

As to the original request here, you should be able to do npm install @niledatabase/server@alpha (or whatever package manager) and pick up the fixed type and fixed QueryClientProvider errors.

Re: cookie stuff - can be prefixed (depending on what you're doing), so you'll want to do something like parseToken(req.headers) (a method from @niledatabase/server) to use our internal function to get that cookie.

A lot of the errors we get from the service are surfaced though the error query param. This one in particular looks like /api/auth/session is returning HTML, which is pretty unexpected. I think you should be seeing some errors on the server side for this app for what is happening there. I think maybe NextJS is catching something incorrectly (middleware), or there's something odd going on with the proxy. Both of these should be debuggable/seen in the server logs. If not, you can always add {debug: true} to your nile instance.

Just a lot of context, not necessary, but maybe helpful.

The default behavior without a session passed to the provider is authenticated. Without a session passed as a prop, the UI must consider itself unauthenticated (it doesn't know any better until the request completes). The only meaningful way to circumvent the client-side fetch is to send the result from nile.auth.getSession() so the <SessionProvider session={session} /> can hydrate properly.

I just took a look at what useSession is doing, and while possibly unexpected... it does look generally correct (what I said above is true). I do agree, however, this can be done significantly better by syncing the provider to our internal storage layer (right now it is just using props only). I'll keep updating the alpha with the fix to use our internal Authorizer better when using the provider to sync up the storage layer, which should reduce the (un)authorized problem you're seeing here (and subsequent flicker). I

[jrea]

in revisting this and syncing up the states, it is more deterministic after the initial load (and works across tabs a lot better now), but there's no meaningful way to reduce flicker without hydration. Working client-side only is just going to have that limitation. If we don't know you're authorized, we have to assume you're not, so the error you're getting back from your /api/auth/session is an error not related to either of these.

[jrea]

released 5.0.2 officially with these changes

[mdconn]

Thanks for this fix!