Just updated to 9.4 to use getStaticPaths and getStaticProps because I'm trying to get around this issue #3294 but now I get the following errors when I do yarn build.
Error occurred prerendering page "/blog/post/[id]". Read more: https://err.sh/next.js/prerender-error:TypeError: Cannot read property '0' of undefined
Setting fallback to false gives me no build errors.
const Post = ({posts}) => {
const post = posts[0];
const router = useRouter();
if(router.isFallback) {
return (
<Layout>
<CenterContent>
Loading ...
</CenterContent>
<Footer />
</Layout>
)
}
return (
<Layout>
<CenterContent>
<article>
<Header>
<h1>{post.title.rendered}</h1>
</Header>
{post.better_featured_image
? <Figure>
<ImageResponsive {...post.better_featured_image} />
</Figure>
: null}
<Main dangerouslySetInnerHTML={{__html: post.content.rendered}} />
</article>
</CenterContent>
<Footer />
</Layout>
);
}
export async function getStaticPaths() {
const res = await fetch(${process.env.blogApiLive}/posts);
const posts = await res.json();
const paths = posts.map(post => /blog/post/${post.slug});
return { paths, fallback: true }
}
export async function getStaticProps(context) {
const res = await fetch(${process.env.blogApiLive}/posts?slug=${context.params.id});
const posts = await res.json();
return { props: {posts} }
}
Am I missing something?
On a side note, in this release, fetch is now included but when I run yarn build without something like node-fetch or isomorphic-unfetch I get this error
ReferenceError: fetch is not defined
at getStaticPaths (C:\projects\originnext\.next\server\static\DuTV4FL6_E6-lnBspZfBz\pages\blog\post\[id].js:2790:15
So it seems like a package to do fetch is still required?
You're accessing a post before checking if you need to render the fallback:
const post = posts[0];
Move this code to after the if branch.
Also, that fetch bug was fixed on the latest next@canary version.
@Timer Hey Joe, I think you pointed out the correct answer to the problem. Nevertheless, Im wondering if Next is trying to render a page that doesn't even exist during build ("/blog/post/[id]")?
The getStaticPaths is rightly defining all possible paths at this point, but at build time there's this weird path ("/blog/post/[id]") that has a render attempt, breaking the build process.
This means that, in order to skip that attempt, we'd need to check if the props are ok, even though we know the props are ok for the paths we listed in getStaticPaths.
Just wondering if you have any thoughts on this or if that's just how things are for the time being. Thanks!
@Timer Hey Joe, I think you pointed out the correct answer to the problem. Nevertheless, Im wondering if Next is trying to render a page that doesn't even exist during build ("/blog/post/[id]")?
The getStaticPaths is rightly defining all possible paths at this point, but at build time there's this weird path ("/blog/post/[id]") that suffers a render attempt, breaking the build process.
This means that, in order to skip that attempt, we'd need to check if the props are ok, even though we _know_ the props are ok for the paths we listed in getStaticPaths.
Just wondering if you have any thoughts on this or if that's just how things are for the time being. Thanks!
I am experiencing this issue right now. What would be the solution for this?
@Joshanity17 I ran into the same issue and was able to fix it with a one-liner:
// setup
export async function getStaticProps(context) {
const data = await ...
return {
props: {
data
}
}
}
// the page component
export default function MyPage({ data }) {
if (!data) return null // this is the one-liner check
// rest of actual component code
}
@Joshanity17 I ran into the same issue and was able to fix it with a one-liner:
// setup export async function getStaticProps(context) { const data = await ... return { props: { data } } } // the page component export default function MyPage({ data }) { if (!data) return null // this is the one-liner check // rest of actual component code }
This ones work. But ain't sure what's the catch with this kind of workaround.
Since the introduction of Next.js v10, I鈥檝e removed the workaround code. fallback: 'blocking' works well for me.
Most helpful comment
@Timer Hey Joe, I think you pointed out the correct answer to the problem. Nevertheless, Im wondering if Next is trying to render a page that doesn't even exist during build ("/blog/post/[id]")?
The getStaticPaths is rightly defining all possible paths at this point, but at build time there's this weird path ("/blog/post/[id]") that has a render attempt, breaking the build process.
This means that, in order to skip that attempt, we'd need to check if the props are ok, even though we know the props are ok for the paths we listed in getStaticPaths.
Just wondering if you have any thoughts on this or if that's just how things are for the time being. Thanks!