How to share data/instances between loaders?

[lunsdorf]

Hello all. I'm using remix with express and do user authentication via oauth2. Everything is written in typescript. Right now, all authentication logic (routes, session, etc.) is implemented in remix. As I don't have any data storage at hand, the id and refresh tokens are stored as encrypted cookies. Basically this setup works all fine. However, for nested routes, each loader basically needs to do the same things: parse the cookie first, decrypt the id token next, maybe fetch a new id token using the refresh token that has also be decrypted and than write that new (encrypted) id token back to the response header. As this also happens when rendering the initial HTML on the server, I would like to put it somewhere, so that I only have to do it once per request.

So far, I tried three separate things:

• do it before remix takes over using the getLoadContext function (this is why I witched to express in the first place). unfortunately, this doesn't work so great, since you cannot really share code between the app and the server, due to the way the server-part of the app is bundled (the server is written in typescript as well and also needs to be transformed).
• authenticate, read/refresh tokens in express and make the id token accessible using getLoadContext. this works better, but doesn't work so great with remix' routing. At least I couldn't find a good way to POST to the sign-in/-out redirect URLs as I have to do it inside of a handler function.
• the first loader that needs the id token ensures it is valid (refetching, writing new cookie) and than stores the id token in the loader context object. This works OK and is the current solution. However, it is a bit dangerous, since it happens somewhere in between and relies on the fact, that promises in JS are basically resolved in sequence.

Long story short: what is the best way to share (per-request) data/instances between loaders?

I think this all wouldn't be a problem, if I could define the getLoadContext function somewhere under remix' control, e.g. inside entry.server.tsx … Please tell me I didn't overlook it in the docs :-).

Sorry, if this is a duplicate. I couldn't find something similar, but realized a lot of discussions around loaders and sharing state and stuff.

[sergiodxa]

It's not possible to share data between loaders, this is because:

1. On a document request (SSR), they run all at the same time in parallel, so you couldn't share data between two or more loaders.
2. On a client-side navigation, they are requested in parallel too.
3. On a client-side navigation, if you deployed to serverless they may even run on different machines
4. On a client-side navigation, Remix may not call all the loader, if you are on /parent/child1 and navigate to /parent/child2 because /parent didn't changed Remix will only call the loader of child2.

Because of all of this, specially the last one, each loader should run all the logic it needs, if a loader needs the access token and refresh token you will need to do it on that loader too.

What I recommend is to:

1. Move it to the Express server so you can do it once per request, but while on SSR it will means you share data between loaders, on client-side navigation you will still do it once per loader because each loader is a request.
2. Create a helper function getToken, pass the request and parse the session, read the access and refresh tokens, refresh the access token, and return the new access/refresh tokens, and don't forget to store them on the session and commit the cookie.

[lunsdorf]

OK, I thought this is what getLoadContext is for. Do you have any insides, why this has to be defined outside of remix, and not e.g. in entry.server.tsx? I understand that it is not guaranteed when an individual loader runs.

The way you suggest is basically the way it is implemented at the moment. Maybe I can tweak it a little more. I mark this discussion as answered … By the way, your blog really helps getting started with remix 👍

[sergiodxa]

The getLoadContext method is a way to let the HTTP server pass data to the Remix app, that's why it's outside entry.server, because that file is the entry point of the server-side part of the Remix app, not the whole server.