Support nullish inputs for `isFilled` helpers

[Angelo Ashmore]

Is your feature request related to a problem? Please describe.

The isFilled helpers currently require a non-nullish input to detect if its is filled or not. This requires extra code when the input may be nullish (such as documents that have not yet loaded).

Note the need to check if slice.primary.text?.richText is truthy in the following example.

export default function TextSlice({ slice }: SliceComponentProps<PrismicText>) {
	return (
		<section>
			{slice.primary.text?.richText &&
				isFilled.richText(slice.primary.text.richText) && (
					<div>
						<PrismicRichText field={slice.primary.text.richText} />
					</div>
				)}
		</section>
	);
}

Describe the solution you'd like

The isFilled helpers could accept null or undefined values. This removes the need to manually check if the field is present.

export default function TextSlice({ slice }: SliceComponentProps<PrismicText>) {
	return (
		<section>
			{isFilled.richText(slice.primary.text?.richText) && (
				<div>
					<PrismicRichText field={slice.primary.text?.richText} />
				</div>
			)}
		</section>
	);
}

Describe alternatives you've considered

The alternative is provided as an example in the first section.

Additional context

N/A

[Lucie]

Definitely!

Side thoughts

One thing that this highlights though is the lack of coverage of the underlying issue "why is the value nullish?" in the first place (as a nullish value is not a valid API response).

I think there are two cases when a value can be nullish:

• Document is still being fetched;
• Document fetching step failed (404, etc.).

And I'm not sure "not rendering the field" is the correct approach to solve those two cases, better approaches might be:

• Preventing the rendering of the whole section displaying the document (e.g. in the case of a blog post: post hero with title, lead thumbnail, post body with slices, post footer with author info, etc.);
• Using the loading state to display a skeleton instead of the Prismic component (which the above approach doesn't help with);
• Rendering the 404/error page in case of failure.

I'm bringing this (again I think ^^') to have us think about "how to promote/ease/define" what can be considered as best practices here ☺️

Not sure of the behavior of slice variations in that story though 🤔 (are all fields still available with those? may some disappear?)

[Angelo Ashmore]

That's a good point. In the above example, slice.primary.text is nullable because the Gatsby GraphQL type is incorrect (something that should be fixed in gatsby-source-prismic).

When working with multiple Slice variations, only the intersection of all variation fields would be known without performing some kind of type narrowing (checking for the variation value). Supporting nullish fields wouldn't help or be affected here since the type wouldn't include fields from other variations (i.e. the field is a level away from simply being nullish).

I think you're right - supporting nullish fields may not be the right solution here. I'll close this for now but we can always revisit it if a use case is found.

[Lucie]

Released as part of @prismicio/helpers@2.2.0 🎉