RFC: (Route exit transitions) Custom component for wrapping TemplateContext.Provider array #56594

evankirkiles · 2023-10-08T20:56:36Z

evankirkiles
Oct 8, 2023

Goals

Allow users to provide a component which takes the OuterLayoutRouter's route-keyed array of Templates as children, as we claim to do in the docs for templates.

Background

Current Behavior

Currently, page exit transitions are not supported in appDir. There's no way for libraries like framer-motion placed in layout.tsx to monitor the changing array of keyed TemplateContext.Providers—e.g. templates—which is something we previously claimed could be done in layout.tsx, and is currently implied by the docs:

Instead, there is the necessary intermediary of OuterLayoutRouter, which handles caching of each subroute. The DOM looks (abstractly) like this:

<...USER.Layout >  {/* This is your custom layout  */}\
   {/* Some user components  */}
  <OuterLayoutRouter> {/* The OuterLayoutRouter for the parallel route  */}
    {styles /* If the root layout, e.g. with <html>, other styles go here */}
    {preservedSegments.map(() => (  {/* As of Next.js 13.4.X, only one segment is preserved at a time.  */}
       <TemplateContext.Provider key="....">
        {templateStyles}
         <USER.Template>
           <RenderTemplateContextValues> {/* This renders the contents inside the template */}
         </USER.Template >
       </TemplateContext.Provider>
    )}
  </OuterLayoutRouter>
  {/* Maybe some more user components and parallel routes w/ their own OuterLayoutRouters  */}
</...USER.Layout >

As the layout.tsx gets an opaque OuterLayoutRouter view of any slots it provides, there's no way for us to keep a previous route around past its lifetime in order to animate it out. And, as template.tsx is mounted for every route, we of course can't manage the route's own lifecycle there, either.

Motivation

I think I speak for a lot of web designers / developers when I say that this is probably one of the largest issues keeping me on the pages directory—the ability to use route exit transitions for a smoother user experience. It would be a massive boon for the appDir to have this functionality implemented, especially if taking into account appDir's ability for parallel routing... A glue component or something of the sort providing an easy drop-in for scoped exit transitions at each parallel route's slot would be a game-changer.

Proposal

Somehow, we need to bridge the gap from userland code to the keyed array of TemplateContext.Providers if we want to persist exiting routes as is usually done with framer.motion. My immediate idea is just to add a new type of client component called a Glue component, placed in a glue.tsx file, which can be inserted inside the OuterLayoutRouter at the correct position:

<...USER.Layout > 
   {/* Some user components  */}
  <OuterLayoutRouter>
    {styles}
    <USER.Glue > {/* <--- Placement of new "Glue" client component  */}
       {preservedSegments.map(() => 
          <TemplateContext.Provider key="....">
            {templateStyles}
            <USER.Template>
              <RenderTemplateContextValues>
            </USER.Template >
          </TemplateContext.Provider>
       )}
    </USER.Glue >
  </OuterLayoutRouter>
  {/* More user components  */}
</...USER.Layout >

This would enable the following structure, assuming a user uses framer-motion's <AnimatePresence /> as their Glue component:

<Layout>
   {/* Implicit @children slot */}
   <AnimatePresence>
      {/* The entering route */}
      <Template key"segment|hi|c">
         <Page />
      </Template>
      {/* The exiting route persisted by AnimatePresence */}
      <Template key"__PAGE__">
         <Page />
      </Template>
   </AnimatePresence >
   {/* Some other slot, say @sidebar */}
   <AnimatePresence>
      {/* The entering route */}
      <Template key"segment|hi|c">
         <Page />
      </Template>
      {/* The exiting route persisted by AnimatePresence */}
      <Template key"__PAGE__">
         <Page />
      </Template>
   </AnimatePresence >
</Layout>

Example

Draft PR with the above: #56591

The above proposal works with very minimal code changes, though with some current quirks related to how parallel routes that aren't the implicit @childrenslot are keyed:

Screen.Recording.2023-10-08.at.3.05.00.PM.mov

Note how the @sidebar slot also receives exit transitions—though, confusingly, the transition occurs only when moving from the root @sidebar/page.tsx (where we have TemplateContext.Provider key="page$") to any sub-path in @sidebar/[segment]/page.tsx (where we haveTemplateContext.Provide key="children", and routing happens further down the tree). This doesn't happen for the implicit @children slot, where the root page is keyed with __PAGE__ and following segments are keyed with segment| {whichever segment you navigated to} | c. This would need more investigation before the glue component can be used reliably.

WARNING
Also, changing routes while a route is still in the exit transition also seems to break the AnimatePresence component here. I am unsure why, as this feature is supposed to work out-of-the-box. Next.js provides the correct child DOM node, but the rendered child of AnimatePresence falls out of sync and never exits, the internal state of "exiting" child keys being wrong.

Concerns

I understand that adding in a new file component is a huge thing to do. However, with the way "use client" works, and the client-side-only nature of any Glue component, making it its own file separate from layout.tsx and template.tsx for now was the quickest way to get the PoC out.

An alternative approach could be to simply add this Glue component as a custom export of template.tsx, turning the file into what I feel like it ultimately should be—custom wiring between a route and its parent layout. Then, the default export of template.tsx would be remounted on every page navigation, whereas some export const Glue = function() { } would persist across templates much like layout.tsx does. However, this would cause issues with styling, as the styles from template.tsx are rightfully loaded in the child tree of the Glue component, where the template is, and so wouldn't be accessible from whatever HTML element(s) Glue is. And again, the template.tsx would then have to be a client component.

I also don't like doing the same from the other end, e.g. layout.tsx, because I think it'd be better to leave the door open to more granular templating, e.g. different Glue components for different parallel routes with their own template.tsx's, or some other more slot-based approach. Also, this'd force your layout to be a client component with "use client" as well.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

RFC: (Route exit transitions) Custom component for wrapping TemplateContext.Provider array #56594

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{editor}}'s edit

{{editor}}'s edit

Uh oh!

Replies: 0 comments

Select a reply

Uh oh!

RFC: (Route exit transitions) Custom component for wrapping TemplateContext.Provider array #56594

Uh oh!

Uh oh!

evankirkiles Oct 8, 2023

Goals

Background

Current Behavior

Motivation

Proposal

Example

Concerns

Replies: 0 comments

evankirkiles
Oct 8, 2023