What is a proper approach for keeping initial site config for App Router? #69381

develos-dr · 2024-08-27T18:38:03Z

develos-dr
Aug 27, 2024

Hello everybody!

I have a question about what is a proper approach for loading and keeping the site initial configuration. My project have some config that is fetched from database on side load. This needs to be loaded once and data are immutable. Those are things like white labelling or translations.

I prepared a next API that combines all requests and then i call this api just to get all the data in one call. So we have an AppContext that is used in a root Layout.

export default function RootLayout({
  children,
}: Readonly<{
  children: React.ReactNode;
}>) {
  console.log("Render Layout", Date.now());
  return (
    <html lang="en">
      <body>
            <AppProvider>
              {children}
            </AppProvider>
      </body>
    </html>
  );
}

Above root layout and below the context provider. Here we load all the data on server type component and as props we initialize layout.

const AppProvider = async ({
  children,
}: {
  children: React.ReactNode;
}) => {
  const data = await fetch(`api/initialize`);
  const { 
    appSettings, 
    languages, 
    translations, 
    styles, 
    publicPages, 
    entryPages, 
  } = await data.json() as AppInitializeType;

  return (
    <AppContextProvider
      appSettings={appSettings}
      languages={languages}
      translations={translations}
      styles={styles}
      publicPages={publicPages}
      entryPages={entryPages}
      profilePages={profilePages}
    >
      <ReactQueryProvider>{children}</ReactQueryProvider>
    </AppContextProvider>
  );
};

export default AppProvider;

And also AppContextProvider file as well:

"use client"
import { createContext, useContext, useState } from "react";
import { AppSettingsType, Dictionary, LanguageType, PageBase, PageType, TranslationsType } from "../types";
import { DEFAULT_LANG_CODE } from "../constants";
import React from 'react';

const useAppSettingsState = (appSettings: Dictionary) => useState<Dictionary>(appSettings);
const useLanguagesState = (languages: LanguageType[]) => useState<LanguageType[]>(languages);
const useTranslationsState = (translations: Dictionary<TranslationsType>) => useState<Dictionary<TranslationsType>>(translations);
const useStylesState = (styles: Dictionary<Dictionary>) => useState<Dictionary<Dictionary>>(styles);
const usePublicPagesState = (pages: PageType[]) => useState<PageType[]>(pages);
const useEntryPagesState = (pages: PageBase[]) => useState<PageBase[]>(pages);
const useProfilePagesState = (pages: PageType[]) => useState<PageType[]>(pages);

export type AppContextType = {
    appSettings: Dictionary,
    languages: LanguageType[],
    translations: Dictionary<TranslationsType>,
    styles: Dictionary<Dictionary>,
    publicPages: PageType[],
    entryPages: PageBase[],
    profilePages: PageType[],
};

export const AppContext = createContext<AppContextType |null>(null);

export const AppContextProvider = ({ 
    children, 
    portalUrls: initialPortalUrls,
    appSettings: initialAppSettings,
    languages: initialLanguages,
    translations: initialTranslations,
    entryPages: initialEntryPages,
    publicPages: initialPublicPages,
    profilePages: initialProfilePages,
    styles: initialStyles
}: ProperType) => {
    const [ appSettings ] = useAppSettingsState(initialAppSettings);
    const [ languages ] = useLanguagesState(initialLanguages);
    const [ translations ] = useTranslationsState(initialTranslations);
    const [ styles ] = useStylesState(initialStyles);
    const [ publicPages ] = usePublicPagesState(initialPublicPages);
    const [ entryPages ] = useEntryPagesState(initialEntryPages);
    const [ profilePages ] = useProfilePagesState(initialProfilePages);

    return (
      <AppContextType.Provider value={{
        appSettings: appSettings,
        languages: languages,
        translations: translations,
        profilePages: profilePages,
        publicPages: publicPages,
        entryPages: entryPages,
        styles: styles,
      }}>
          {children}
      </AppContextType.Provider>
    );
  };

BUT i see some weird behavior. So i generate page dynamically. I have some kind of renderer which base on current route path generate page. All works good, so to handle that in main app folder i have [[...slug]]/page.tsx

export default function Home() {
  console.log("Render AppRenderer", Date.now());

  return (
    <AppRenderer/>
  );
}

As you might noticed i have two console logs, one in root layout and one in Page.tsx. The thing is that whenever i change a page i check the logs in Client and in Next itself. As for client it looks good

then for next itself not.

Render Layout 1724781787488
 GET /api/initialize 200 in 1238ms
Render Layout 1724781787488
 GET /api/initialize 200 in 1238ms
 GET /[object%20Object] 200 in 3571ms
Render AppRenderer 1724781790914
Render Layout 1724781790917
 GET /api/initialize 200 in 838ms
 GET /_next/static/chunks/lucide-react.js.map 200 in 1697ms
 ✓ Compiled in 8s (6982 modules)
Render AppRenderer 1724783562522
Render Layout 1724783562526

Whenever i change the page on client side i have whole layout generated on "backend" so i got a lot of additional api calls (to my backend C# api) to fulfill the context. Also what is weird for me it looks like it generate layout also for files like /GET /_next/static/chunks/lucide-react.js.map 200 in 1697ms/.

Am i doing it wrong? What is a proper approach for such things in app router. I can understand that we need to generate everything for first request but is there a way to somehow share user context from client side? Why we need to load it even for resources files?

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

What is a proper approach for keeping initial site config for App Router? #69381

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{editor}}'s edit

{{editor}}'s edit

Uh oh!

Replies: 0 comments

Select a reply

Uh oh!

What is a proper approach for keeping initial site config for App Router? #69381

Uh oh!

Uh oh!

develos-dr Aug 27, 2024

Replies: 0 comments

develos-dr
Aug 27, 2024