Enhancement Request: Make fields that are left blank by the user generate an empty string by default

Please improve Prismic so that fields that are left blank by the user generate an empty string by default.
Eg A double quotes empty string ("") rather than Null

Currently I'm getting errors along the lines of:

Cannot read property 'text' of undefined

And it seems to be caused when a user creates a Document and then leaves any one field blank.

This seems highly brittle and it also seems overly defensive to then have to add a v-if check for null strings into every text field I code up.

Thanks

Hey, thanks for reaching out!

The default null response was a decision we took, not because of a technical limitation but because we want to allow people to check if it's null or not and to be able to display it or not.

This is true for simple string fields, like a Key text field, Color, etc. If you have more depth like in an Image or Rich Text field, you'll have an object or array, for instance.

So yes, you'll need to add the check that validates the field before trying to render it. e.g., say you have a Key Text field with the API of 'pricetag', and if you're working on Nuxt, you can add an empty array that will be added if the response is null

<div>
  {{ $prismic.asText(doc.pricetag || [ ] ) }}
</bdiv>

I suppose then Im asking your dev team to review this position.

Handling null cases leads to some of the greatest waste of time in programming.
(One minutes google search provided this for example: http://rundis.github.io/blog/2016/elm_maybe.html)

I think its a serious oversight of Prismic to have it so that defensive programming is required on so many fields or risk the user generating page errors on production.

In fact when reviewing a few example Prismic apps and clicking around I already came across a broken page, which is a case-in-point.

All this is to say that I really appreciate the great work your team is doing, just want to make an impassioned plea on this point.

Can I recommend that you make all fields safe to output by default and that would be having fields output an empty string if the field is left empty.

As devs we can still check to see if the value is an empty string and do conditionals on that.

Having null in addition to empty adds nothing.

If this is still an open debate, lets get a few more voices on this too if we're still in disagreeance.

I'm also not talking here how quickly you'd make this change, I appreciate it could be a big change also.

Thanks

1 Like

Thank you for your feedback, it is always, very much appreciated. I've made them aware of our conversation. If/when they come back to us with a response or opinion about this I'll let you know as soon as possible.

In the meantime, what I'll do is to add a feature request tick to your thread to show your interest in this topic.

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.

1 Like

Thank you for the feedback, we'll be sure to add a ping about this in the feature request tracker.

This is being tracked as an open feature request.

If you have another use-case for this feature, you can 'Flag' this topic to reopen. Please use the :heart: button to show your support for the feature and check out our Feature Request Guidelines.

Old topic, but worth stating this is satisfied by prismic.isFilled helpers now.

1 Like