Export RemixEntryContext

[nickjs]

Problem

Remix's nested routing is amazing, but unfortunately doesn't work if you use multiple React renderers, (legacy) portals, or anything else where a potential <Outlet> or <RemixRoute> loses access to React Context. For example, almost anything on this list isn't usable with Remix routing: https://github.com/chentsulin/awesome-react-renderer

It's possible to work around this by manually "replaying" the Remix and react-router contexts inside the new React renderer scope, but unfortunately this doesn't currently work because RemixEntryContext isn't exported from @remix-run/react.

Desired code

// myroute.ts
import { RemixEntryContext } from '@remix-run/react';
import { UNSAFE_LocationContext } from 'react-router';

import { Canvas } from '@react-three/fiber';

export default function Index() {
  const location = React.useContext(UNSAFE_LocationContext);
  const entry = React.useContext(RemixEntryContext);

  // <Canvas> creates an entirely new React rendering scope;
  // everything inside Canvas' children don't have access to any of the existing Context objects/providers/values,
  // so rendering an Outlet or anything that uses react-router's hooks will throw.
  // The details of <Canvas> are not important, the important thing is that there are many potential use cases where context will be lost.

  return (
    <Canvas>
      <UNSAFE_LocationContext.Provider value={location}>
        <RemixEntryContext.Provider value={entry}>
          <Outlet />
        </RemixEntryContext.Provider>
      </UNSAFE_LocationContext.Provider>
    </Canvas>
  );
}

What happens right now

UNSAFE_LocationContext works fine, but RemixEntryContext isn't exported from remix-react/index. You can try to import it from @remix-run/react/components (where it is exported), but something goes super wonky with either ESM or the compiler and it always returns undefined if you do this, meaning the Outlet will throw. Using patch-package to export the exact same RemixEntryContext from the index does work, but that's not a good long term solution for anyone who wants to publish a package based on this approach.

Proposed fix

Export RemixEntryContext from @remix-run/react.

Yes it's an implementation detail that may/will change in the future, but without it we are cutting off a whole class of potential use cases for Remix. In my opinion, it's fine if you change the API later on and these use cases break. Or at least, the burden is not on you--maintainers of Remix--to make sure they don't break.

1. It's tied to a published npm version, so anyone taking advantage of the exported context will know exactly how, when, and where it breaks. TypeScript will make it even more immediately apparent.
2. As long as whatever context <RemixRoute> consumes remains exported, regardless of what it's called or what value it actually provides, developers with these advanced use cases will be able to update their code to make it work without tying themselves to the value itself.

One final point: any future Remix Dev Tools will almost certainly require access to the same context :)

[nickjs]

@sergiodxa Mind expanding on why you're opposed?

[nickjs]

EDIT: RemixRouteContext also needs to be bridged

[kiliman]

There are lots of changes being made to React Router at the moment. Perhaps this should be something that RR makes easier for Remix to provide.

[agcty]

I second exposing the RemixEntryContext. I am not familiar with the changes that are being made to the react router but whatever the API looks like after the changes, exposing RemixEntryContext and RemixRouteContext is incredibly powerful as you can use remix data hooks within different renderers.

[meshakeeb]

I also support of exposing it with it we can create more functionality similar to Metas and Links