Docs/feedback june batch

[icyJoseph]

Addressing feedback from:

• missing function reference Docs: the checkIsAvailable() function is missing #77190
• Error boundaries: Thrown Error in Client Component is not triggering Error Boundary #42525
• RedirectType: Docs: unclear RedirectType #59160
• generateMetadata can be included into static builds: Docs: generateMetadata - can we generate its output statically? Docs don't mention this. #80499

Also the headings here, https://nextjs.org/docs/app/guides/local-development are not properly nested

[gmoniava]

Resolving generateMetadata is part of rendering the page. If the page can be pre-rendered and generateMetadata doesn't introduce dynamic behavior, its result is included in the page’s initial HTML

I hope it is ok to make a comment here.
Maybe in the above text it will be helpful to mention what kind of dynamic behavior you meant.
Because even in your first example on the linked issue, you have:

export async function generateMetadata({ params }: { params: Promise<{ slug: string }> }) {
  const { slug } = await params;
  const { uuid } = await fetch("https://httpbin.dev/uuid").then(res => res.json())

  return {
    title: slug,
    description: uuid,
  };
}

So maybe someone can assume since we are reading slug, this is dynamic behavior - which AFAIK it is not.

[icyJoseph]

So maybe someone can assume since we are reading slug, this is dynamic behavior - which AFAIK it is not.

That's the nuanced part here... defining generateStaticParams is the key - that's what I am missing on this PR, or rather, I thought If the page can be pre-rendered was clear enough.

On second thought, I think this can stay that way.

[gmoniava]

So maybe someone can assume since we are reading slug, this is dynamic behavior - which AFAIK it is not.

That's the nuanced part here... defining generateStaticParams is the key - that's what I am missing on this PR, or rather, I thought If the page can be pre-rendered was clear enough.

On second thought, I think this can stay that way.

Well, it is up to you, I assume the dynamic behavior you mean actually implies the so called dynamic APIs (cookies, headers, etc).
For me it would be more clear to see it mentioned that way. Because like I said reading slug can also be considered dynamic by someone. But maybe some readers will understand.

[icyJoseph]

Because like I said reading slug can also be considered dynamic by someone. But maybe some readers will understand.

I hear ya, it is dynamic though, but you can provide ahead-of-time info for pre-rendering, by defining generateStaticParams - and then you can control with dynamicParams whether, more variants are allowed at runtime - very layered issue - if you go the dynamicParams false way, then things are settled, no more pages will be built. If you let it be true, then at runtime more pages can be made, on demand. And defining no generateStaticParams keeps these pages dynamic by definition.

[gmoniava]

Because like I said reading slug can also be considered dynamic by someone. But maybe some readers will understand.

I hear ya, it is dynamic though, but you can provide ahead-of-time info for pre-rendering, by defining generateStaticParams - and then you can control with dynamicParams whether, more variants are allowed at runtime - very layered issue - if you go the dynamicParams false way, then things are settled, no more pages will be built. If you let it be true, then at runtime more pages can be made, on demand. And defining no generateStaticParams keeps these pages dynamic by definition.

I may know that, but my point is in the documentation, someone else could have understood it differently. That's why one must strive to write docs in a way to not leave room for misinterpreting things.

[icyJoseph]

I may know that, but my point is in the documentation, someone else could have understood it differently. That's why one must strive to write docs in a way to not leave room for misinterpreting things.

Totally agree. I monitor several channels to try and catch these. Also as features evolved, and defaults changed, some pieces of documentation that pinned, or relied, on other bits, have lost their implicit context, and I am always trying to find those. I appreciate the feedback and effort to discuss this.

[gmoniava]

I may know that, but my point is in the documentation, someone else could have understood it differently. That's why one must strive to write docs in a way to not leave room for misinterpreting things.

Totally agree. I monitor several channels to try and catch these. Also as features evolved, and defaults changed, some pieces of documentation that pinned, or relied, on other bits, have lost their implicit context, and I am always trying to find those. I appreciate the feedback and effort to discuss this.

Well that's good because like I mentioned here (just resharing the link here), bad docs can alienate developers. Sadly I have found something unclear or confusing more than a few times in Nextjs docs.