feat(remix): Pass options to remix getAuth

[dvargas92495]

Type of change

• [ ] 🐛 Bug fix
• [x] 🌟 New feature
• [ ] 🔨 Breaking change
• [ ] 📖 Refactoring / dependency upgrade / documentation
• [ ] other:

Packages affected

• [ ] @clerk/clerk-js
• [ ] @clerk/clerk-react
• [ ] @clerk/nextjs
• [x] @clerk/remix
• [ ] @clerk/types
• [ ] @clerk/clerk-expo
• [ ] @clerk/backend-core
• [ ] @clerk/clerk-sdk-node
• [ ] @clerk/edge
• [ ] build/tooling/chore

Description

• [x] npm test runs as expected.
• [x] npm run build runs as expected.

Just like how the NextJS package allows passing in getAuthData options to withServerSideAuth (link), extend the Remix package's getAuth to accept options too.

I find myself doing getAuth(args).then(({userId}) => users.getUser(userId)) in several of my loaders, which this would make easier

[dvargas92495]

tagging @nikosdouvlis for review

[nikosdouvlis]

Hey @dvargas92495 , very interesting!

Remix loaders for nested routes run in parallel and so far, we don't have a good way to share state/data across loaders for the same request. In theory, if a user makes a request for a nested route, say /a/b/c every route has its own loader that uses getAuth({ loadUser: true }) we will be firing 3 separate requests. Of course, they run in parallel but it's still at least one request for every nested loader.

We didn't provide an easy way to pass { loadUser} to getAuth for this exact reason, since we don't want to make this approach easy in order to avoid the very possible performance bottleneck.

Firing the extra request explicitly by calling getAuth(args).then(({userId}) => users.getUser(userId)) is a very good alternative, because it makes apparanent that a new request will be made.

That being said, I still think that this API makes sense even if I'm a little skeptical about it. I really like having parity between the getAuth and rootAuthLoader APIs.

Do you know of any way to share state between the loaders in the context of a single request?

cc: @SokratisVidros

[nikosdouvlis]

Alternative, the user could create it's own util, eg:

import { getAuth } from '@clerk/remix/ssr.server';
import { users } from '@clerk/remix/api.server';

export const getAuthAndUser = async (params: Parameters<typeof getAuth>[0]) => {
  const auth = await getAuth(params);
  if (!auth.userId) {
    return { ...auth, user: null };
  }
  const user = await users.getUser(auth.userId);
  return { ...auth, user };
};

Not a huge fan of this solution, but maybe its something you could use in the meantime

[dvargas92495]

Remix loaders for nested routes run in parallel and so far, we don't have a good way to share state/data across loaders for the same request

Their recommendation is client side via useMatches: https://github.com/remix-run/remix/tree/main/examples/sharing-loader-data

This doesn't really work for most use cases though because you still need to authenticate each individual route to prevent a user from accessing/writing unauthorized data.

I think I have an idea for this though: using a cache server side.

Loaders from Remix pass in a context: https://remix.run/docs/en/v1/api/conventions#loader-context

Developers could typically get a requestId from their deployment to make it available in loaders. Here's me doing that from AWS Lambda@Edge: https://github.com/dvargas92495/remix-lambda-at-edge/blob/main/src/adapter.ts#L83

We could then pass this cache id to clerk:

const auth = await getAuth(args, {loadUser, requestId});
// alternatively, clerk could check args.context.requestId

Then within getAuth, if there's a requestId, Clerk caches the user object in the request id and fetches it from the cache if it's already present.

Thoughts? I'll update this PR with a POC later today

Alternative, the user could create it's own util, eg:

This is what I was already doing 😆

[dvargas92495]

Any thoughts on above @nikosdouvlis ?

[nikosdouvlis]

Any thoughts on above @nikosdouvlis ?

Hey @dvargas92495 :) Ansered here: https://github.com/clerkinc/javascript/pull/249#discussion_r879440719

[SokratisVidros]

Closing this in favor of the new @clerk/remix package.

[dvargas92495]

There's a new one?

[SokratisVidros]

Yes, with edge runtimes support.

It will be released tomorrow.

Regards,

---

Sokratis Vidros Head of Engineering @ Clerk https://www.clerk.dev/

Le mar. 29 nov. 2022 à 22:35, David Vargas @.***> a écrit :

There's a new one?

— Reply to this email directly, view it on GitHub https://github.com/clerkinc/javascript/pull/249#issuecomment-1331264014, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAKKFZWEBJECWBHROIURPADWKZSI7ANCNFSM5WGJNS6Q . You are receiving this because you modified the open/close state.Message ID: @.***>