How to publish reusable functionality

[moltar]

I'm failing to create a mental model for publishing reusable functionality as an npm package.

Let's say I have a set of routes and React components that implement an auth, that should be reused across multiple apps.

It may include sign-up, password reset, sign-out, etc... The typical boilerplate many apps have.

This would be opinionated, and specific, so not really something like remix-auth.

Think org-specific or, perhaps, service-specific set of functionality that goes hand-in-hand together.

What's the best way to achieve that?

Where's the "line in the sand" of the contract between the publisher and consumer?

Thanks!

[alexanderson1993]

I guess it depends on how you want to organize it. The nice thing is that the API for Remix itself is pretty straightforward:

• loader
• action
• A default exported component

(among other things, but we'll just stick with those three)

So one level of abstraction would be having your package export those, and then have each app create the routes as needed. Something like this:

// /app/routes/sign-up.tsx
export {default, loader, action} from '@my-org/pre-built-remix/sign-up'`

That's it. That's the module.

Naturally, you could make it so you export components and functions which are used in the modules, like so:

// /app/routes/sign-up
import {SignUpForm, signupLoader, signupAction} from '@my-org/pre-built-remix/sign-up'

export async function loader(args) {
  // Do other stuff here
  return {signUpResult: await signupLoader(args)}
}

export async function action(args) {
  // Do other stuff here
  return {signUpResult: await signupAction(args)}
}

export default function SignUp() {

  return (<div>
    <SignUpForm />
  </div>)
}

You could take it even further the other direction by exporting a function which is used in the routes config to automatically add some pre-built routes that would be the same for every app that uses your package.

Lots of options, I don't think there's an official "line in the sand" - it depends on how willing your consumers are to adopt the approach you choose. If it's a package intended to tightly unify an individual org, then you could probably get away with a lot. If you're looking for broad adoption, then people will likely prefer for you to give small building blocks that they can intersperse in their own application logic and component tree.

Hopefully this gives you some ideas.

[alexanderson1993]

Fabulous! I think that's a great idea.

[kiliman]

Be wary of HOFs like createSignup. Since loaders and actions should only be part of the server bundle, a function like createSignup is a side-effect, which means the code and its dependencies will end up in the client bundle.

// mypackage.tsx
import { useLoaderData, useActionData } from "@remix-run/react";

function loader() {
  console.log("this is a server function");
  return {
    message: "message from loader",
  };
}

function action() {
  console.log("this is a server function");
  return {
    message: "message from action",
  };
}

function Component() {
  const loaderData = useLoaderData();
  const actionData = useActionData();
  console.log("this is a server/client function");
  return (
    <div>
      <pre>{JSON.stringify(loaderData, null, 2)}</pre>
      <pre>{JSON.stringify(actionData, null, 2)}</pre>
    </div>
  );
}

export function createPackage() {
  return {
    loader,
    action,
    default: Component,
  };
}

// routes/test.tsx
import { createPackage } from "~/mypackage";

const { loader, action, default: Component } = createPackage();
export { loader, action, Component as default };

When your app is built, it generates the following client bundle:

// build/client/assets/test-xxx.js
import{j as e}from"./jsx-runtime-DM6QP6at.js";
import{e as t,f as s}from"./components-t4r8Wo_B.js";
import"./index-DjCiwJfw.js";
function r(){return console.log("this is a server function"),{message:"message from loader"}}
function a(){return console.log("this is a server function"),{message:"message from action"}}
function i(){const n=t(),o=s();return console.log("this is a server/client function"),e.jsxs("div",{children:[e.jsx("pre",{children:JSON.stringify(n,null,2)}),e.jsx("pre",{children:JSON.stringify(o,null,2)})]})}
function c(){return{loader:r,action:a,default:i}}
const{default:m}=c();
export{m as default};

As you can see, your loader and action functions are included in the client bundle.

To work around this, you can use the serverOnly$ function from vite-env-only:

// mypackage.tsx
import { serverOnly$ } from "vite-env-only";

// ... same code as before
// wrap loader, action with serverOnly$
export function createPackage() {
  return {
    loader: serverOnly$(loader),
    action: serverOnly$(action),
    default: Component,
  };
}

You'll see that the client bundle will no longer include the server-only functions. serverOnly$ replaces the expression with undefined which results in void 0.

return{loader:void 0,action:void 0,default:r}

import{j as n}from"./jsx-runtime-DM6QP6at.js";
import{e as o,f as a}from"./components-t4r8Wo_B.js";
import"./index-DjCiwJfw.js";
function r(){const e=o(),t=a();return console.log("this is a server/client function"),n.jsxs("div",{children:[n.jsx("pre",{children:JSON.stringify(e,null,2)}),n.jsx("pre",{children:JSON.stringify(t,null,2)})]})}
function i(){return{loader:void 0,action:void 0,default:r}}
const{default:u}=i();
export{u as default};

[moltar]

@kiliman Ohh, great point!! Totally didn't think of that.

And thanks for the tip on serverOnly$. Does that work with Vite only? What about the "legacy" (if we can already call it that) mode?

[kiliman]

serverOnly$ only applies to Vite. For the legacy compiler, you'd have to use explicit exports like a typical route module.

// mypackage.tsx
import { useLoaderData, useActionData } from "@remix-run/react";

export function loader() {
  console.log("this is a server function");
  return {
    message: "message from loader",
  };
}

export function action() {
  console.log("this is a server function");
  return {
    message: "message from action",
  };
}

export default function Component() {
  const loaderData = useLoaderData();
  const actionData = useActionData();
  console.log("this is a server/client function");
  return (
    <div>
      <pre>{JSON.stringify(loaderData, null, 2)}</pre>
      <pre>{JSON.stringify(actionData, null, 2)}</pre>
    </div>
  );
}

// routes/test.tsx
import { loader, action, default as Component } from "~/mypackage";
export { loader, action };
export default Component;

[mtakac]

@alexanderson1993 How would you go about achieving something like this?

You could take it even further the other direction by exporting a function which is used in the routes config to automatically add some pre-built routes that would be the same for every app that uses your package.

Our applications are inside of an NX monorepo and they all need to share a package defining some routes. I am not able to figure out how to do that.

My initial approach was to define custom routes with defineRoutes in the package and then import it to my application's vite.config, but that doesn't seem to work.

I also cannot simply declare the routes in my application, because they need to point to the files from the packages.

We previoulsy done something similar with react-router where package would explore routes and application would then render these routes, but I am not able to find a way how to achieve this in Remix.