-
|
Update: We’re excited to announce Next.js 13, which includes the new Inside the |
Beta Was this translation helpful? Give feedback.
Replies: 52 comments 184 replies
-
|
This is just an initial restriction as we want to make sure we provide the right abstraction for it in _app. For example we need to figure out what would happen if someone decides to add The restriction will be lifted at a later point. |
Beta Was this translation helpful? Give feedback.
-
|
We would also love to have this feature in place! Thank you for your great work! |
Beta Was this translation helpful? Give feedback.
-
|
plus 1 for this in 2022. I switched for my use case to use json file for this info but it seems like a pretty big deal to a lot of people |
Beta Was this translation helpful? Give feedback.
-
|
Any updates on this for 2022? Code wise, it's quite against DRY atm having to add this in all pages |
Beta Was this translation helpful? Give feedback.
-
|
2023 :D |
Beta Was this translation helpful? Give feedback.
-
|
@camposcristian @marketsystems The update is linked below: #10949 (comment) |
Beta Was this translation helpful? Give feedback.
-
|
Same here. I understood that "This is just an initial restriction", but: If I had a shared component in |
Beta Was this translation helpful? Give feedback.
-
|
I'm having the exact same issue trying to fetch a menu from WP as a headless CMS. I really need SEO on my navigation so I'm forced to generate it statically and make it persistent across all the different page templates (on a large project they can be ~50). Not having getStaticProps available on _app.js forces me to run the fetcher on every single page file to be able to use getStaticProps. In my case this is a great harm because most of my projects are based on dynamic navigations coming from headless CMSs. |
Beta Was this translation helpful? Give feedback.
-
|
Perhaps decoupling App.getStaticProps from App.getServerSideProps would help get a fix out for everyone with issues here? Then the server-side issue could be figured out later? (I get the sense you're thinking getServerSideProps should maybe only run for pages that would already server-side render?) In the meantime, here's how I work around the problem:
With this, I bootstrap static pages, but end-users still get the benefit of up-to-date data. This only works because I currently only need it for settings. It'll fall flat if I try this with a/b testing, features flags, or anything like that. |
Beta Was this translation helpful? Give feedback.
-
|
@mikestopcontinues I'm interested about what you did there. I opened another discussion that might be related: #18000 Basically, I need to pre-fetch data from an Airtable API and store those in a file which is then used by all my pages, instead of fetching the API from each page separately (which is what I do now). I'm confused as to how Since the |
Beta Was this translation helpful? Give feedback.
-
|
@Vadorequest Here's a minimal version of all three files: `next.config.js`const fs = require('fs-extra');
const db = require('./libs/dbApi');
const tempDir = path.resolve(process.cwd(), '.tmp');
const settingsProm = db.readSettings().then((data) => {
return fs.ensureDir(tempDir).then(() => fs.writeJson(`${tempDir}/settings.json`, data));
});
module.exports = {
async redirects() {
// NOTE: This can go in any async config func.
// You really just need it to await before Next starts the dev server.
const {redirects} = await settingsProm;
return redirects;
},
};`pages/_app.js`import {SettingsProvider} from 'src/App/useSettings';
import settings from '.tmp/settings.json';
export default function App({Component, pageProps}) {
return (
// NOTE: settings should eventually be pulled from getStaticProps()
<SettingsProvider value={settings}>
<Component {...pageProps} />
</SettingsProvider>
);
}`src/App/useSettings.js`// NOTE: You don't have to use constate.
// Regular React.createContext will do the same thing.
import constate from 'constate';
import useSWR from 'swr';
import db from 'libs/dbApi';
const SettingsContext = ({value}) => (
// NOTE: If you use SWR, `revalidateOnMount` is important.
useSWR('/db/settings', db.readSettings, {
initialData: value,
revalidateOnMount: true,
revalidateOnFocus: false,
revalidateOnReconnect: false,
}).data
);
export const [
SettingsProvider,
useSettings,
] = constate(SettingsContext); |
Beta Was this translation helpful? Give feedback.
-
This is possible with the help of this library. This will include the props declared in config file of this library, at _app level. Configuration (common-props.config.js)can be like: So this data will be available in _app.js by using useCommonProps hook, |
Beta Was this translation helpful? Give feedback.
-
|
It looks like that I.e. Once I move my code from the |
Beta Was this translation helpful? Give feedback.
-
|
Since |
Beta Was this translation helpful? Give feedback.
-
Something like that would work |
Beta Was this translation helpful? Give feedback.
-
|
Sweet, yes that works! :) |
Beta Was this translation helpful? Give feedback.
-
|
That approach still works with our browser-side code elimination: https://next-code-elimination.now.sh/s/QVaH-3mLA which makes it possible to use server-side deps in getStaticProps/getStaticPaths |
Beta Was this translation helpful? Give feedback.
-
Sadly this is not working for me though, it keeps throwing unable to load library error, the browser is trying to load server side libraries |
Beta Was this translation helpful? Give feedback.
-
|
How can SSG be used for other page extensions like MDX (using I'm using an |
Beta Was this translation helpful? Give feedback.
-
|
@timneutkens When the restriction for using In my case that'd be very helpful since we would want to do some static fetching (e.g. language translations for page content) during build time with This follows the same line of thought as #11424. |
Beta Was this translation helpful? Give feedback.
-
|
This is actually useful to keep our codebase |
Beta Was this translation helpful? Give feedback.
-
|
I've read through everything here but I'm still a little fuzzy on what exactly the tradeoff on using If it's only that treeshaking isn't done I can understand why this feature has been deprioritised. But if fetching data in |
Beta Was this translation helpful? Give feedback.
-
|
Yes and at that point there isn't much utility over just re-fetching the global data you need on every page's Right now I'm fetching global data in |
Beta Was this translation helpful? Give feedback.
-
If it helps, you could use vercel to view the preview/build output and review the impact on optimization. It outlines which pages are SSG, SSR, or Static. |
Beta Was this translation helpful? Give feedback.
-
|
I could be wrong, but what I take from this is |
Beta Was this translation helpful? Give feedback.
-
|
@ryan-reach In my project this only appears to work for pages that have |
Beta Was this translation helpful? Give feedback.
-
|
@jensmeindertsma I believe by using getInitialProps in _app you are opting out of automatic static optimization which I understand to mean that you must explicitly call getStaticProps in each page.
https://nextjs.org/docs/advanced-features/automatic-static-optimization |
Beta Was this translation helpful? Give feedback.
-
|
I'm implementing dark mode and I need to run a script when a page is visited to determine the user theme before rendering. I'd like to optimize this script using A long time ago when this const script = minify(rawScript);
export default function Home() {
return (
<>
<h1>Hello</h1>
<script dangerouslySetInnerHTML={{__html: script}} />
</>
);
}Please, please, please, tell me if the above approach has issues that I'm not aware of! Now, the export default function Home({ script }) {
return (
<>
<h1>Hello</h1>
<script dangerouslySetInnerHTML={{__html: script}} />
</>
);
}
export async function getStaticProps() {
const script = await minify(rawScript);
return {
props: {
script,
}
}
}This approach has a downside: Furthermore, this also means the script is included in the I feel like Also, I feel like I have a large gap in my understanding because I don't know why I would love to hear your thoughts on this, and what you can recommend me 🙏 |
Beta Was this translation helpful? Give feedback.
-
|
@jensmeindertsma hmm, you can make async calls in |
Beta Was this translation helpful? Give feedback.
-
|
You can do this request in |
Beta Was this translation helpful? Give feedback.
-
|
Does this work with static generation? I assume you mean using lifecycle hooks in the Document component? |
Beta Was this translation helpful? Give feedback.
-
|
Yes that’s what I meant, not using next export so not sure how it would work exactly |
Beta Was this translation helpful? Give feedback.
-
|
if the problem is to minimize external api requests -the solution is to combine getting page and global data in one graphql request |
Beta Was this translation helpful? Give feedback.
-
|
Maybe it's the to implement this, due to the recent NextJS 10 release? Most i18n implementations will use the getStaticProps to fetch .json files and provide them as static information. Like export const getStaticProps = async (context) => {
const locale = context.locale || context.defaultLocale;
const { default: table = {} } = await import(`locales/${locale}.json`);
return { props: { table } };
};Currently, this needs to be at the bottom of every page. |
Beta Was this translation helpful? Give feedback.
-
|
I'm trying to do the same thing. It redundant to have to add this to every page. |
Beta Was this translation helpful? Give feedback.
-
|
Is there currently any workaround to get some static data into the App component or a non-page component that might be used by App? I have dynamic routes and would like to show the pages in the website's navbar, but that's only possible if i can pass the page names/ids to App and that child component, which i would normally use |
Beta Was this translation helpful? Give feedback.
-
|
@FunctionDJ did you find a workaround for achieving this? |
Beta Was this translation helpful? Give feedback.
-
Nope, i would have come back otherwise. I've been seeing some workarounds here, but none of them seem good enough to be worth trying instead of just loading stuff multiple times, or simply doing things by hand for the time being. |
Beta Was this translation helpful? Give feedback.
-
|
I'm sure all projects when reaching a certain size will need to include data for some component that appears in different pages. To fetch and attach this data to each generated page is wasteful both in time and goes against DRY. The issue has an accepted answer but no solution and has been ranking very high among the RFCs for almost a year now, is it being worked on? |
Beta Was this translation helpful? Give feedback.
-
|
Also, does the lack of updates on this issue have anything to do with the upcoming Server Components integration? I can imagine Next making dramatic architecture simplifications as a result, though I would really really hate to wait that long to get this piece sorted. |
Beta Was this translation helpful? Give feedback.
-
|
I've also needed solutions around this so I've created two different libs in this global-data-esque space. I've needed both for my own projects but sharing them here in case you find them useful. next-plugin-preval — pre-evaluate async functions and import them as JSON (truly de-duped across bundles)repo linkThis lib ships its own webpack loader that matches any You can import them in Its API looks like this: // header-data.preval.js
import preval from 'next-plugin-preval';
import db from 'your-db';
async function getHeaderData() {
const headerData = await db.query(/* query for header data */);
return headerData;
}
export default preval(getHeaderData());// header.js
import headerData from './header-data.preval';
const { title } = headerData; // available as static data, deserialized from JSON
function Header() {
return <header>{title}</header>;
}
export default Header;It's pretty simple to understand but since it's a bundler-level optimization, it will not work with ISR or even SSR. Once it leaves the build, there is no refreshing it. next-data-hooks — `getStaticProps` as react hooks (nice for organization)repo link
This is how that looks: // header.js
import { createDataHook } from 'next-data-hooks';
import db from 'your-db';
// step 1: write a `getStaticProps` implementation (don't export it though)
const getStaticProps = async (context) => {
// (you don't have to return `props` though)
return await db.query(/* ... */);
};
// step 2: pass it into this function
const useHeader = createDataHook('Header', getStaticProps);
function Header() {
// step 3: use it your component.
// the data will be there synchronously at first render
const { items } = useHeader();
return // ...
}
// step 4: add the `dataHooks` static prop
Header.dataHooks = [useHeader];
export default Header;The idea is to propagate these things via the // layout.js
import Header from './header';
import Footer from './footer';
function Layout() {
return // ...
}
Layout.dataHooks = [
...Header.dataHooks,
...Footer.dataHooks,
];
export default Layout;You'll have to see the docs for the full story but hopefully, you can see enough of the pattern to make sense of it. Note that this doesn't actually de-dupe the header data from being fetched on every page. This lib's primary goal is organization, not performance. |
Beta Was this translation helpful? Give feedback.
-
|
Is there a timeline for when this will be released? Would be really useful for SSG apps to have global data. There isn't currently a good workaround if you want to stick with SSG. |
Beta Was this translation helpful? Give feedback.
-
|
please give me a solution for SSR. I am googling and there's no concrete answer. I don't care about SSG |
Beta Was this translation helpful? Give feedback.
-
What is your problem? Have you tried to use useSWR? |
Beta Was this translation helpful? Give feedback.
-
|
In my case, it would be a great solution to have. Cause the website I am working on has data that are not gonna be changed or may change frequently. Having getStaticProps in the _app can lead to a great developing experience. Cause the website I am working on has a lot of redundant data from page to page. I am more of like thinking to fetch all the data from _app and then use context API or Redux to access them where I needed. |
Beta Was this translation helpful? Give feedback.
-
|
I cannot believe this was the problem. Been trying for hours.. hope there is a nice solution soon, it will be much better |
Beta Was this translation helpful? Give feedback.
-
|
Yeah I am also going to put my voice forward to say that the above response from @leerob doesn't actually address the issue or explain why it's not possible. Is there any plan to allow for a global place to get app data statically? |
Beta Was this translation helpful? Give feedback.
-
|
The first sobering moment in my honey-moon phase with nextJS. Compared to everything next can do, this would seem like a basic feature. |
Beta Was this translation helpful? Give feedback.
-
|
It is; for some reason, for the Next team, it isn't |
Beta Was this translation helpful? Give feedback.
-
|
Don't worry on March 11, 2020 they said "The restriction will be lifted at a later point." So I imagine it will happen any day now. |
Beta Was this translation helpful? Give feedback.
-
|
Same feeling, NextJS looked so promising until I encountered this limitation. |
Beta Was this translation helpful? Give feedback.
This comment was marked as spam.
This comment was marked as spam.
-
|
Hi everyone! Dropping in from the next.js team to let you know that we have heard the feedback here loud and clear and we are actively discussing the best way that we can solve for this. Same for layouts support - it's something we have actively staffed and are working on right now. As soon as we have something that we are confident enough to commit to publicly, we will share it 😁 |
Beta Was this translation helpful? Give feedback.
-
|
Another thought since the Next team seems to be working on this feature now: I think Here is a use case: I'd like to build a configurable app which has some optional pages. Whether or not a page exists depends on the existence of a (let's say) corresponding YAML file containing content data. If an optional page exists, the navbar should have a corresponding item. Now how would I manage the navbar items? For instance, each page YAML file could contain information about its associated navbar item label and the path could be derived from the YAML filename. But that's only possible with |
Beta Was this translation helpful? Give feedback.
-
|
I imagine component-level static props/data seems more challenging than static page props because page components aren't called directly by a user and thus there's no mix of injected static props and user-provided props. Perhaps an API similar to Gatsby's |
Beta Was this translation helpful? Give feedback.
-
|
I think you could set up a system like this as-is, by exporting both a component and a data-fetching function from your component file, yeah? I put together a somewhat similar concept that can be utilized within nextjs here, if that's helpful. |
Beta Was this translation helpful? Give feedback.
-
|
https://nextjs.org/docs/advanced-features/react-18/server-components isn't this basically even better? You can use React Suspense to fetch data on the server side, in any component |
Beta Was this translation helpful? Give feedback.
-
|
@rasco not if you're using static pages. |
Beta Was this translation helpful? Give feedback.
-
|
That's awesome, thanks for the update.
…On Tue, Apr 26, 2022, 8:04 PM Jeff Escalante ***@***.***> wrote:
Hi everyone! Dropping in from the next.js team to let you know that we
have heard the feedback here loud and clear and we are actively discussing
the best way that we can solve for this. Same for layouts support - it's
something we have actively staffed and are working on right now. As soon as
we have something that we are confident enough to commit to publicly, we
will share it 😁
—
Reply to this email directly, view it on GitHub
<#10949 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABTB7SP75A5SNNQYJHTO7YTVHCVDRANCNFSM4LFHTLQA>
.
You are receiving this because you commented.Message ID: <vercel/next.
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
I did this and it works, will i have some problem doing this? export async function getStaticProps() {
const settings = await getSettings();
if (!settings) {
return { notFound: true,}
};
return {
pageProps: { settings }};
}
function MyApp({ Component, pageProps }: AppProps) {
useEffect(() => {
console.log(pageProps.settings)
},[]);
return (
<Layout>
<DefaultSeo
title={pageProps.settings ? pageProps.settings.meta_title : '' }
description={pageProps.settings ? pageProps.settings.meta_description : ''}
/>
<Component {...pageProps} />
</Layout>
)
}
export default MyApp |
Beta Was this translation helpful? Give feedback.
-
|
@Manimall |
Beta Was this translation helpful? Give feedback.
-
|
@leogersen just read the docs - https://nextjs.org/docs/advanced-features/custom-app - and i told you that your answer is NOT a solution at all, it's incorrect, you can't use getStaticProps in |
Beta Was this translation helpful? Give feedback.
-
|
@leogersen did you try to build your app?? |
Beta Was this translation helpful? Give feedback.
-
|
@Manimall I know it's not supposed to work, I've read the documentation, this code is in production and working well, my goal is to find out why it's working and what side effects it might have, I'm not encouraging anyone to do the same. |
Beta Was this translation helpful? Give feedback.
-
|
Ok, i have got your position |
Beta Was this translation helpful? Give feedback.
-
|
There are three potential solutions that can help people with this problem today:
I can provide example for every solution if anyone's interested. |
Beta Was this translation helpful? Give feedback.
-
|
@raRaRa would be great!!!! |
Beta Was this translation helpful? Give feedback.
-
|
I am interested in these examples!
That would be great.
…On Fri, May 6, 2022, 8:25 AM Jón Trausti ***@***.***> wrote:
There are three potential solutions that can help people with this problem
today:
1. Use file system cache to share data between pages.
2. (OR) Use in-memory cache with node's globalThis to share data
between pages. Note that globalThis is only available in Node version
>= 12.0.0.
3. Use Higher order function with higher order component to reduce the
friction of writing getStaticProps for every single page.
I can provide example for every solution if anyone's interested.
—
Reply to this email directly, view it on GitHub
<#10949 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABTB7SJCBOTU7KMHHCVVLP3VIU2U5ANCNFSM4LFHTLQA>
.
You are receiving this because you commented.Message ID: <vercel/next.
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Here's an example of higher order function (HOF) with higher order component (HOC) and caching in-memory with the Let's start with the higher order function. This is only applicable if you are used to writing getStaticProps function for every single page with the same data fetching code, which can cause code duplication and more friction when adding more pages. So to fix this we could use something called "Higher order function". Here's an example of a higher order function where we always fetch shared data such as header data. We will call the higher order function Alright, next In a page component you would only need to call the HOF (Higher order function) if you don't need any additional data fetching for the page. Otherwise if you need to fetch additional data you would do this: This code will make your life much easier when you are writing endless getStaticProps for the same data. Next we also want to use shared layout component that uses this shared header data. To do this we will write a higher order component called withPage. It's really simple: So now when you write a page component, you can simply do this: The higher order component will wrap the HomePage component with Now you have shared getStaticProps and layout combined. However, data fetching will still occur for every single page (multiple API calls, etc.), so how can we solve that in some neat way? That's where caching will come in. As you saw in our HOF above, we called a function called For caching I thought in-memory caching would not be possible, since each page is rendered in isolation. My co-worker then told me about something called
And luckily for us, the So now data can be shared between pages without having to spam some API for new data every time, unless the cache has expired. I can also provide the disk cache solution if anyone's interested, but the I hope this helps anyone else who wants to solve this problem "today" without too much hassle. Maybe the NextJS team can also use this as an inspiration for a potential solution! :) |
Beta Was this translation helpful? Give feedback.
-
|
Happy to share the Layouts RFC is finally out: https://twitter.com/vercel/status/1528839321070993409 🥳 |
Beta Was this translation helpful? Give feedback.
-
|
That is awesome.
What is the usual timeline between an RFC and when it is released for
consumption?
…On Mon, May 23, 2022 at 2:59 PM Lee Robinson ***@***.***> wrote:
Happy to share the Layouts RFC is finally out:
https://twitter.com/vercel/status/1528839321070993409 🥳
—
Reply to this email directly, view it on GitHub
<#10949 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABTB7SKXCICBEL5TDHSKN2DVLP5UZANCNFSM4LFHTLQA>
.
You are receiving this because you commented.Message ID: <vercel/next.
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
This is possible with the help of this library. This will include the props declared in config file of this library, at _app level. Configuration (common-props.config.js)can be like: So this data will be available in _app.js by using useCommonProps hook, |
Beta Was this translation helpful? Give feedback.
-
|
The |
Beta Was this translation helpful? Give feedback.
-
|
It doesn't support server side code only yet, IF you need it, you can submit an issue here |
Beta Was this translation helpful? Give feedback.
-
|
Update: We’re excited to announce Next.js 13, which includes the new Inside the |
Beta Was this translation helpful? Give feedback.
-
|
And that's the spirit. Postpone until the problem disappears by itself. Time is the ultimate cure. 🥷 |
Beta Was this translation helpful? Give feedback.
-
|
that's great news! |
Beta Was this translation helpful? Give feedback.
-
I would assume any Promise would work, but I haven't tried it yet. Update: After looking closer at the documentation, yes, any Promise can be used. If you do not use |
Beta Was this translation helpful? Give feedback.
-
|
Following up: the App Router is now stable with 13.4! |
Beta Was this translation helpful? Give feedback.
and others
Update: We’re excited to announce Next.js 13, which includes the new
app/directory (beta) with support for nested layouts, colocation of data fetching, streaming, Server Components by default, and much more.Inside the
app/directory, there is a powerful new way to fetch data with React’suse()hook and the extended Webfetch()API. This allows you to colocate data fetching directly inside components for the most flexibility, including inside layouts.