Updated docs to reflect that getEntry returns undefined

[hkbertoson]

Description (required)

Updated Content Collections to reflect that getEntry returns undefined.
Feedback is greatly appreciated since I am still fairly new on writing documention.

Related issues & labels (optional)

• Closes #
• Suggested label:

[astrobot-houston]

Lunaria Status Overview

🌕 This pull request will trigger status changes.

Learn more

By default, every PR changing files present in the Lunaria configuration's files property will be considered and trigger status changes accordingly.

You can change this by adding one of the keywords present in the ignoreKeywords property in your Lunaria configuration file in the PR's title (ignoring all files) or by including a tracker directive in the merged commit's description.

Tracked Files

File	Note
en/guides/content-collections.mdx	Source changed, localizations will be marked as outdated.
en/reference/modules/astro-content.mdx	Source changed, localizations will be marked as outdated.

Warnings reference

Icon	Description
🔄️	The source for this localization has been updated since the creation of this pull request, make sure all changes in the source have been applied.

[netlify]

✅ Deploy Preview for astro-docs-2 ready!

Built without sensitive environment variables

Name	Link
🔨 Latest commit	eaed64a
🔍 Latest deploy log	https://app.netlify.com/sites/astro-docs-2/deploys/678e554349f1b60008d9f6f0
😎 Deploy Preview	https://deploy-preview-10688--astro-docs-2.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[sarah11918]

Thanks for identifying an issue and bringing it up @hkbertoson

I'll ask @ascorbic to weigh in here, because I really don't love that our "basic, here's what it looks like" example has error checks and even different ways to do things in it! I don't think the guide page is the place for this unless we absolutely expect all of that to be written every time someone renders content. @ascorbic , is that really the idea?

We could have a line or section that mentions you may want to consider error handling/checking for entries, with its own separate example. Or, this just links to the reference page where we add a section on how to do this.

But, this seems wrong as "Here's how you do this!" unless this really is "how we expect you to do it, every time, checking for whether things exist first." So I'll need Matt to let me know how he wants to guide people to use the feature! Hang tight Hunter until he gives his guidance! 🙌

[hkbertoson]

Sure thing. Thanks! @sarah11918

[sarah11918]

On Talking and Doc'ing we discussed how to include this in a minimal, helpful way. We think this, plus adding to the type reference that getEntry() can returned undefined should be sufficient!

[sarah11918]

Thanks so much for this great improvement @hkbertoson ! It's so appreciated that experiences from support threads make it into docs! 🙌

[Fryuni]

This might be too big to be legible in a single line. Do we have a multi-line syntax for types anywhere that we could replicate here?

[delucis]

Not really unfortunately. The usual pattern we’d follow instead would be to have something like **Type:** [`TypeName`](#typename) and show it as a type in a code block with a subheading. But usually that’s for things like options interfaces etc., not just a function type.

[sarah11918]

@ArmandPhilippot Can you think of an example off the top of your head? On desktop for me, it looks like this:

I think one problem is I'm not convinced that each of those two pieces will themselves fit on their own single line, so it's going to look icky either way. But, happy for someone to suggest something that they can figure out that looks good!

[sarah11918]

Also happy for any maintainer to merge once they either have improved, or resigned themselves to, the above! 😅

[ArmandPhilippot]

Yeah I see the same thing but... not really, no. Can we drop support for Legacy collections? 😆 Another "solution" would be to use a list under Type: so that each is on its own line... (instead of the union) but that's not ideal either.

[ArmandPhilippot]

I have a little more time than before, so I took the opportunity to take a screenshot to illustrate what I was saying:

I don't have a strong opinion on this... I'm not sure what is more readable/understandable.

Edit: Well, it seems you also have thought about that ("on their own single line, so it's going to look icky either way.")... Not my day. 😄

[sarah11918]

I mean, I guess that's better? What does everyone think? I'm fine with 2 lines (which unfortunately looks like it's gonna be 3 in practice?) Not opposed to the bullet points here!

[louisescher]

LGTM, way more readable

[delucis]

NWTWWHB!

[sarah11918]

@ArmandPhilippot Happy for you to make the two line change and merge!