useRouteContext returns undefined upon full page reload #2010

Activity

1. iamchanii commented on Jul 23, 2024

   

   iamchanii

   on Jul 23, 2024

   Contributor

   More actions

   Here is a workaround:

     const router = createRouter({
       ...
     });
   
   + router.buildAndCommitLocation({});
   + // but... why?
2. tannerlinsley commented on Jul 26, 2024

   

   tannerlinsley

   on Jul 26, 2024

   Member

   More actions

   I can't remember where else we discussed this, but routeContext being used in a component is an anti-pattern if you're doing SSR. Let me explain why:

   • Hydration needs to be relatively synchronous. We can't wait for async assets before rendering

   • To accomplish this, anything that was async on the server is serialized down to the client and made ready before hydration

   • Context is not guarantied to be serializable, so we can't serialize it.

   • This means that on the initial hydration render of the app, the best "context" we could provide is the router context, which should also be isomorphic (e.g. if you supply something like a query client, it should be instantiated on both the server and the client).

   • We can't make hydration async, and we wouldn't want to either way

   • We can't make beforeLoad sync

   • We can't guaranty serialization of routeContext, and even if we could mix, we would still need to be able to wait on the async nature of it to build up the routeContext

   Proposed solution:

   • Do not use routeContext in components.
   • Possibly we remove the Route.useRouteContext hook.
   • Only use routeContext in loaders.
3. schiller-manuel commented on Jul 26, 2024

   

   schiller-manuel

   on Jul 26, 2024

   Last edited by schiller-manuel

   CollaboratorAuthor

   More actions

   This is not SSR related. just an ordinary SPA.
4. tannerlinsley commented on Jul 27, 2024

   

   tannerlinsley

   on Jul 27, 2024

   Member

   More actions

   Sorry, you are correct. This should be working for non-SSR renderings. However, the issue stands. What should we do?
5. SeanCassiere commented on Jul 27, 2024

   

   SeanCassiere

   on Jul 27, 2024

   Member

   More actions

   Removing the user access to the routeContext outside of the loader function would make it difficult for anyone using it to build something like a breadcrumbs component. Also, the route context does allow for patterns where you can in a single location permeate some options that'll be the same in the loader and in the component.

   This sort of pattern is pretty handy and IMO it would be a shame to lose.

   // src/routes/posts.tsx
   import { createFileRoute } from '@tanstack/react-router';
   import { useSuspenseQuery, queryOptions } from '@tanstack/react-query';
   
   export const Route = createFileRoute('/posts')({
       beforeLoad: ({ params }) => {
           return { // only calculate what the queryOptions were once
               postOptions: queryOptions({ queryKey: ['posts', params.postId], ... }),
               postCommentsOptions: queryOptions({ queryKey: ['posts', params.postId, 'comments'], ... })
           }
       },
      loader: async ({ context }) => {
         await Promise.allSettled([ // you can also choose not to await here, just kick off Query
             context.queryClient.ensureQueryData(context.postOptions),
             context.queryClient.ensureQueryData(context.postCommentsOptions),
        ])
      },
     component: Posts
   })
   
   function Posts() {
      const { postOptions, postCommentOptions } = Route.useRouteContext();
      const postQuery = useSuspenseQuery(postOptions);
      const postCommentsQuery = useSuspenseQuery(postCommentsOptions);
      // ...
   }

   👍React with 👍1Reacted by Roberto De Lucia
6. SeanCassiere commented on Jul 27, 2024

   

   SeanCassiere

   on Jul 27, 2024

   Member

   More actions

   If I remember correctly, for a period of time during the beta when the loaderData was dropped, the router was setup in a way to accept non-serializable content (like a queryClient, apiFetcher, etc.), but everything returned by a Route's beforeLoad function had to be serializable.

   👆🏼Would something like this be feasible here?

   • This allows us to serialize the loaded route context objects and send it down during SSR, but still allow the hydration to happen on the client yes?
   • Or maybe we have an SSR toggle that enforces the route-context into being serializable? Although this'd cause a divergence which is something we probably do not want.
7. schiller-manuel

   added a commit that references this issue on Jul 27, 2024

   tests: reproducer for #2010

   fd6a1fc
8. schiller-manuel commented on Jul 27, 2024

   

   schiller-manuel

   on Jul 27, 2024

   CollaboratorAuthor

   More actions

   reproducer in #2045
9. schiller-manuel

   added a commit that references this issue on Aug 21, 2024

   tests: reproducer for #2010

   7a143f8
10. schiller-manuel commented on Aug 21, 2024

    

    schiller-manuel

    on Aug 21, 2024

    CollaboratorAuthor

    More actions

    this is fixed in 1.49.1
11. schiller-manuel

    closed this as completedon Aug 21, 2024
12. schiller-manuel

    added a commit that references this issue on Aug 21, 2024

    tests: reproducer for #2010 (#2045)

    ...

    cf70c67