I've reflected more on this. Here's my case.
There are three core user types of any prismic project, beyond you folk.
Developer - Full access to code, aims to build robust, flexible, custom CMS their client will love.
Writers - Aim to keep site content fresh and relevant to their audience and up-to-date and continuing to attract and keep visitors engaged.
Visitors - Interest in the company, maybe interested in the services on offer depending on what experience they have and their sense of if they can trust this company with their needs.
Lets take the case of a single unhanded null.
Visitor Experience
Every time a visitor experiences visiting a page that just shows a a full page error message not designed for them, is a problem. There's no way back and their poor experience is bad for business as they are most likely to just close the tab and go elsewhere.
Writer Experience
Once a site is live, and error like the above will first be bought to the attention of the Writer or Head Writer (if at all, it could sit there for weeks). This message adds stress and pressure. "Oh no" there's something clearly wrong. What is it?? How did this happen? How do we even fix this? This thing is broken again. Looks serious. Even, I wish we just staid with Wordpress like Im used to.
The writer, once notified of the error, must go through their own process of stress and then if they cant work it out (most likley), will need to ask for help and time from a developer (Costing budget).
Turns out that when creating the site they had previously confirmed with the developer that an "Eyebrow Headline" was always used on a page, but on this occasion it had been left blank as one didn't seem needed for this particular page.
Each time an uncaught null makes it through and a writer has to address it, leaves them each time less confident in themselves and in prismic, the app seems brittle and they begin to worry as maybe if they arent super diligent the pages seem to keep breaking.
Where no defensive null handling is going on, the onus is on the Writer to be super diligent to ensure that no field they see is ever left empty. This is a stressful app to use for the Writer.
Developer Experience
The developer excited by the opportunities of prismic started full of hope. But its a big job to learn all the nuance of prismic.
Just getting the dynamic code working was a win and once understood, it's fairly elegant. Easy to read, makes logical sense.
But suddenly TypeErrors keep cropping up and the error messages are not that clear. They don't even isolate the line number.
Don't believe me, other devs are also confused..
And not sure they ever came back afterwards..
As a dev Im now faced with having to defensivley code ever one of my data entry fields to manually catch Nulls.
What intuitively was:
<div>{{ $prismic.asText(doc.pricetag) }}</div>
Now becomes the harder to read across the whole code base. So much defensive cruft.
<div>{{ $prismic.asText(doc.pricetag || [ ] ) }}</div>
And worse Im not even that confident of how to achieve this easily across all the prismic dynamic data fields.
Conclusions
The question of if a field is 'required' should not be decided at run time when an error just appears to a vistor, it should be resolve upfront. Meaning either lots of defensive work from the Dev or pressure on the Writer to get things right.
A key principal should be that Writers should always be safe to never really be able to mess things up. They need to be given a very safe space to play. What they see should be expected to them. Publish crappy text, that's what they see. Leave a field blank, unless the system gives immediate feedback it's a required field, well then once published that field is just empty.
As devs we should be able to mark fields as required in the Content Editor and have those field then covered by standard *required validation in the Writers room just like millions of other web forms.
If the field is not marked required, then it should be treated as optional by default and an empty value should be considered a valid state, meaning that its just an empty string. It's what Writers and Devs would expect.
This can also be achieved with empty strings, but now the code only needs to be included when needed.
Create 1000 prismic variables and need to test for empty strings on 5, then this code is only needed 5 times, removing hundreds of lines of cruft.
if (strValue === "") {
//...
}
It's easy to test for an empty string.
Appreciate if you folks gave it a good long thought. I know its a major change to a key design decision you've already committed to but by handling it your end it would greatly improve the experience for devs, writers and in the end visitors to prismic sites.