Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remix #248

Open
phryneas opened this issue Mar 22, 2024 · 1 comment
Open

Remix #248

phryneas opened this issue Mar 22, 2024 · 1 comment

Comments

@phryneas
Copy link
Member

First the good news: streaming SSR with the suspense hooks and Remix works.

All the setup for that is in this diff: phryneas/remix-apollo-stream-example@bc43efe

That said, supporting loaders is another beast.
I'll add my thoughts in this thread.

@phryneas
Copy link
Member Author

Thoughts on Loaders

Loaders run independently of React.

  • on a SSR request, they run before streaming SSR happens in handleRequest.
    • as I understand it, they don't even need to run in the same process/host
  • on later page navigation, they run on the server, but no more SSR happens

As a result, our current "inject into the stream" approach won't work - we have no way of sharing an AC instance reliably between handleRequest and loader, and oftentimes there's not even a handleRequest

=> each loader should create their own instance of Apollo Client and createQueryPreloader.

const loader = () => {
  const preload = createQueryPreloader(makeClient())

  const result1 = preload(query1)
  const result2 = preload(query2)

  return defer({
    result1,
    result2
  })
}

Now, right now preload creates a queryRef - that's hardly feasible in this case, since it can't be transported over the wire.

So we probably need to wrap createQueryPreloader (apollographql/apollo-client#11719) to have a completely different functionality in SSR.

It could create a value like

{
  query,
  variables,
  resultPromise
}

which would then be picked up by an (also wrapped) useReadQuery that would simulate an ongoing request (simulating the request start sooner would be great, but is probably not possible).

Currently, the defer implementation doesn't support promises that are not on the top level yet.

We'd probably need buy-in from the Remix team here to be able to make according changes on their side - once we have fleshed out this story more.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant