Load route/page based on API response, rather than by URL (as not known prior to API call)

[cpotey]

Summary

Hi there!

I've got a django backend that we're trying to use headlessly now, but it currently means that I don't know the route (within Next) prior to calling the API - so can't split the code out like the docs assume.

If I call the API to get any page's data (using the slug) i.e. apiendpoint.com/with-path/about-the-company - it will return data in that response about what component/template/layout (or ideally, Next.js route folder) we will want to use { pageType: "AboutPage", ...}

Currently this URL to view this page would be mysite.com/about-the-company - but we have tonnes of sub-directories, and every single page with completely different page types is currently only accessible to call on this one with-path endpoint.

---

What's the best way to handle this situation within Next (App router ideally), as apiendpoint.com/with-path/whatever-the-URL-is will need to be called on every single page to return the data from the backend, and somehow make sure code-splitting will still be achieved?

Is it just a case of having at the very top level of the /app having a [slug].tsx file, and then inside that a huge list of ifs passing through the API data for every component to should render that page, based on the API response?

if (API.pageType === "AboutPage") {
 return <AboutPage data={API} />
} 
if (API.pageType === "BlogPage") {
 return <BlogPage data={API} />
} 
 ...

The alternative is we to do a load of 301 redirects (which feels risky?), and make each page template a different API endpoint - so that each route is its own thing apiendpoint.com/about/about-the-company, apiendpoint.com/blog/article-two etc - which would match up far more with how Next.js expects things currently, as each "pageType" would be a separate route in Next.js

Hope that makes sense! Thanks in advance

Additional information

No response

Example

No response

[Dragate]

Stumbled upon the same use case. Did you find any solution?

We want to convert a project to next's app router, however there are urls with the same structure that map to different views/layouts. To give an example, here are some dynamic urls that are all under /[slug]:

• /food (category)
• /moto (category)
• /health (category)
• /terms-of-use
• /contact-us

Those that are of type category have a different presentantion than the 2 last ones. With pages router, depending on the response of the CMS, the appropriate components were returned (using conditions). We would like to avoid that with app router for better performance and cleaner code.

We thought of creating different routes (e.g. /[slug] & /category/[slug]) for each type of presentation and using the middleware that asks the CMS for its type, which would rewrite to the other route if necessary. However, we would like to avoid using fetch in middleware (especially when the CMS is a gigantic wordpress database).

[cpotey]

This is proving to have issues with HMR (seemingly due to the dynamic import) - which could be a bug with Next.js...

I'm going around in circles with this a bit, I wonder if the middleware might be the better way for this? - but I think that might mean the pages might have a new URL.

So I call endpoint.com/with-path/article-title -> some middleware sees that this has pageType: "Article" on the response, and redirects it over to a new article/page.tsx instead of using [...slug]

But at point the URL is no longer, site.com/article-title, it would be site.com/article/article-title (I think!), so would be a no-goer.

I'm going to go back to the drawing board on this one a bit more

[Dragate]

Middleware's rewrite (not redirect) should be able to handle this. Aside from the data fetching issue inside a middleware, we also are concerned about the SEO of the new page because that page becomes also routable/public from the new url. Setting the canonical to point to the original page (the one where the rewrite was initiated) should solve this theoretically. It all sounds too hacky, For now, we're leaning on the dynamic imports approach.

[cpotey]

@Dragate Does parallel routes solve this issue at all?

I haven't personally looked into this yet (unsure if you have given up on this too!) - but I might try and spend a bit of time investigating at some point soon see if it's viable

[Dragate]

We tried parallel routes and yea, they help wth the issue. Frankly though, we wasted too much effort/time trying to make them work. They work quite well when they're at the end of the route (near the page file) but when they're placed near the root of the app, they're a nightmare to deal with.

To be more specific, when placed in a layout near the top of the router, it's probable that it encapsulates most of the routes the site provides. We needed to provide a default file for every single of those pages so the router knows how to render that slot for each of them. This helped a lot with the initial issue but at the same time made the filesystem quite bloated.

Alternatively, we tried the example provided in the documentation with a catchall route in the parallel route to reduce the bloat issue but it wasn't working as we wanted it to. It was working well on reloads but not on client-navigations. For example, I could reload on /food category and render slot 1 in the layout, as well as reload on /new-promotion-123 general-purpose page and render slot 2 of the same layout. But when I navigated from /food to /new-promotion-123 it did not switch slot from 1 to 2. It remained as slot 1. Kinda expected since layout maintains state for routes it encapsulates.

At the end, we kept the parallel routes at the most-nested layout that did encapsulate only the routes that needed this logic of dynamic markup based on API response and removed the rest.

At the same time, we wanted to define dynamic markup for the top-level layout from data that was coming from pages 2-3 levels down. Since in our use case the general-purpose pages are far less than the categories, we thought it might be a good compromise to do the API call on the page itself and conditionally redirect (when it's a general page) to the same page with extra an query parameter that the top-level layout and its slots could access from the searchParams prop. Turns out it produces more hassle than we imagined since using searchParams opts into dynamic rendering and you have to manually set cache options to maintain somewhat fast html serving.

[cpotey]

Thank you so much for the write up, really helpful!

[jdortegar]

I'm dealing with the same problem trying to render different views for the same segment, any news ?

[cpotey]

Unfortunately, nope. I haven't got a good solution.

Using parallel routes is about as close as I got, as it makes code splitting work (rather than loading all the components included in the catch-all route) - but it's a bit of a weird setup. And I have some issues on route change, with it loading the browser halfway down the page - due to the amount of parallel route slots (I think).

For now though, just doing a switch statement to load the component based on the API response still. Simpler, but the code-splitting is an issue.

[jackkemmish]

Hi there @cpotey , I've come for exactly the same reason so glad it's just not me that's had this issue.

We use a CMS, and the pathname could be anything, so like you, I am checking for a page type in the response to load in the correct "Page component" if I can call it that, whilst in a catch all segment, so thanks for the idea for dyanmic import solution for now.

The main issue i'm having now is we have a ResourceListPage type which needs server side pagination/sorting/filtering, and because of this it now makes all the possible routes miss SSG :(

I wonder if you've had a similar issue for this and how you might have worked around it?

Thanks,
Jack

[cpotey]

I don't fully know your setup there, but all of my "page components" are rendered server-side fine.

This is a slimmed down version of what I'm doing in my catch-all / [...slug]/page.tsx at the moment.

// importing all the page components
import Article from './article/Article';
import Brochure from './brochure/Brochure';
import Bundle from './bundle/Bundle';
import InterviewTool from './interview-tool/InterviewTool';
import NewsTopic from './news-topic/NewsTopic';
import News from './news/News';
import Policy from './policy/Policy';
import ResourceHub from './resource-hub/ResourceHub';
import TabbedArticle from './tabbed-article/TabbedArticle';
import Topic from './topic/Topic';
...

// creating the page component, and fetching the data from the endpoint
export default async function Page({
  params,
  searchParams,
}: {
  params: { slug: string[] };
  searchParams: { [key: string]: string | string[] | undefined };
}) {
  const slug = params.slug.join('/');
  const data = await getPageOrPreview({ slug, searchParams });

  return <PageTypeComponent data={data} />
}

// rendering out the correct component based on the data.meta.type
const PageTypeComponent = ({ data }: { data: Page }) => {
  switch (data.meta.type) {
    case 'main.Article':
      return <Article data={data as ArticlePage} />;
    case 'main.TabbedArticle':
      return <TabbedArticle data={data as TabbedArticlePage} />;
    case 'main.Topic':
      return <Topic data={data as TopicPage} />;
    case 'main.BrochurePage':
      return <Brochure data={data as BrochurePage} />;
    case 'interview.InterviewTopic':
      return <Topic data={data as TopicPage} />;
    case 'interview.InterviewTool':
      return <InterviewTool data={data as ArticlePage} />;
    case 'main.ResourceHubPage':
      return <ResourceHub data={data as ResourceHubPage} />;
    case 'main.Bundle':
      return <Bundle data={data as BundlePage} />;
    case 'policy_bank.Policy':
      return <Policy data={data as PolicyPage} />;
    case 'main.News':
      return <News data={data as NewsPage} />;
    case 'main.NewsTopic':
      return <NewsTopic data={data as NewsTopicPage} />;
    default:
      return <>Page: {data.title}</>;
  }
};

It works, but the negative side is that all of the components/css/js from these page components are all bundled into this route. So say you're loading the <News /> page component, ALL of the others' files are also included in that route.

The only way I've seen to get around this so far is by utilising parallel routes (but haven't got too far with it yet, because it's a large refactor that I haven't had time for yet).

It would look a bit like this, I think (I don't know better, but from an early exploration it seemed to work)

[...slug]/layout.tsx

export default function Layout({
  children,
  article,
  brochure,
  bundle,
  interviewTool,
  news,
  newsTopic,
  policy,
  resourceHub,
  tabbedArticle,
  topic,
}: {
  children: React.ReactNode;
  article: React.ReactNode;
  brochure: React.ReactNode;
  bundle: React.ReactNode;
  interviewTool: React.ReactNode;
  news: React.ReactNode;
  newsTopic: React.ReactNode;
  policy: React.ReactNode;
  resourceHub: React.ReactNode;
  tabbedArticle: React.ReactNode;
  topic: React.ReactNode;
}) {
  return (
    <>
      {children}
      {article}
      {brochure}
      {bundle}
      {interviewTool}
      {news}
      {newsTopic}
      {policy}
      {resourceHub}
      {tabbedArticle}
      {topic}
    </>
  );
}

Example parallel route component (Article for example) - there will be one of these for each of the page components

[...slug]/@article/page.tsx

export default async function Article({
  params,
  searchParams,
}: {
  params: { slug: string[] };
  searchParams: { [key: string]: string | string[] | undefined };
}) {
  const slug = params.slug.join('/');
  const data = (await getPageOrPreview({ slug, searchParams })) as ArticlePage;

 // THIS IS THE IMPORTANT BIT
 // This will render nothing unless the data returned is correct
  if (data.meta.type !== 'main.Article') {
    return null;
  }
  
  return (
    <>
      <h1>{data.title}</h1>
      ...  everything else
    </>
  );
}

[...slug]/page.tsx

export default async function Page({
  params,
  searchParams,
}: {
  params: { slug: string[] };
  searchParams: { [key: string]: string | string[] | undefined };
}) {
  const slug = params.slug.join('/');
  const data = await getPageOrPreview({ slug, searchParams });

  if (!data) {
    notFound();
  }

  return (
    <>
    </>
  );
}

I'm unsure if this is terrible unperformant, but haven't dug into it yet.

I wouldn't use this as any form of "good" code, it's more some discovery into things - because it seems this pattern isn't common and I've not had any response from anyone about how best to go about all of this.

[jackkemmish]

Hi @cpotey,

Thanks for the info, really helpful!

I think the conditional route is the way to go for now. I'm a little apprehensive around parallel route, read it can be quite tricky to use/have some kinks.

But happy for you to prove me wrong 😉

Yeah it's a shame there's no one who seems to have had this issue either. All the docs point to everything being split out under a specific path e.g. /shop/ for example 😕

Thanks again!

Jack

[Dragate]

It works, but the negative side is that all of the components/css/js from these page components are all bundled into this route. So say you're loading the page component, ALL of the others' files are also included in that route.

I'm wondering if importing each page component through next/dynamic would improve bundle size. If I understood it correctly, it should instruct to create a separate bundle for each dynamic import and if the component isn't used, that bundle shouldn't be included (at least in the initial load).

[cpotey]

@Dragate Just had a test of that this morning! From what I can see it doesn't separate anything still when using next/dynamic.

I used next/bundle-analyzer to have a look, and the bundles were identical on my [...slug] catch-all route. From what I can tell, code-splitting only happens by route within Next, and because all of these components/files/js/css are loaded into that one catch-all route, it's just all getting bundled together. It doesn't know how to split further than that.

I've dug into the built CSS/JS files, and there's a page.js file (amongst other related ones), which contains all of the logic/interactivity etc of all the page components in here - so there's defo no splitting here (as I can see things related to my Interview Tool page component, when viewing on the Article page component/Topic page component etc). Similarly with CSS, I can see all the styles/classNames related to these other page components on this route when digging into the files, not just the one that I'm on.

I might have to go back to parallel routes soon and see how I get on there, because it's only digging into the built files you realise quite how much unused code gets loaded on each page within this catch-all route. This problem/file sizes will only grow as more page components get added in the future.

[Dragate]

I used next/bundle-analyzer to have a look, and the bundles were identical on my [...slug] catch-all route. From what I can tell, code-splitting only happens by route within Next, and because all of these components/files/js/css are loaded into that one catch-all route, it's just all getting bundled together. It doesn't know how to split further than that.

That's unfortunate. Thanks for looking into it!