Avoid using global variables

[lukejagodzinski]

Hi, I have a question whether you have some pattern to avoid using global variables. Recently, I'm trying to avoid passing global variables around and unfortunately that's the advices way of doing it in Remix. For example, when you use Prisma, you supposed to import it from another file where it's already initialized. What I would like to do is something like this:

const appFactory = (deps) => {
  const prismaClient = prismaFactory(deps);
  const expressServer = expressServerFactory({ ...deps, prismaClient });
  
  return {
    run: () => expressServer.listen()
  };
}

const app = appFactory({ /* ... pass all deps for the entire app */ });
app.run();

The expressServerFactory function would also define all the routes and pass prismaClient to each route handler factory function as a dependency. This way, I have zero global variables and code that is super easy to test, mock and replace modules without affecting the rest of the code.

However, the routes convention used in Remix kinda makes it impossible. I've seen that you can define your routes in the config file but it's outside of the src directory so I can't use this pattern.

Using global variables maybe is easy and tempting to use but it's programming antipattern.

Do you guys know how to apply this pattern in Remix?

[sergiodxa]

If you are using Express you can pass a context object to the loaders and actions on every request from the Express server using the getLoadContext, see https://remix.run/docs/en/v1/other-api/adapter#createrequesthandler, this context is accesible in any loader or action.

[lukejagodzinski]

Ok cool, I will try that. Thanks!

[lukejagodzinski]

It's actually really bad solution. The server/index.js file is written in JS and I want to share code written in TS. I think the best thing would be to have more control over the context object in the Remix server.

[ccssmnn]

You can write it in TS and add a separate build step to generate the final JS file to start the server.

[lukejagodzinski]

I could, but should I? If the Remix framework supports TS, then it would be nice if it also supported it in config/setup files.

[ccssmnn]

Remix is TS. What you build is a Remix HTTP Handler that you can use. Remix ends here. You then use adapters (or implement your own) to plug in the Remix HTTP Handler into a server framework of your choice. That could be a Vercel Function, a Cloudflare Worker, an Express server. But that is not Remix anymore.

In the case of Express, you use the Remix HTTP Handler via the Express Adapter. When you want to build your express server with TS, you are free to do so. Build some of your routes with Express, handle other ones or everything else with the Remix Handler. It's completely your choice. You may need to change the Remix server build, to match the compiled output of your express implementation.