We use the gatsby source prismic plugin (GitHub - prismicio/prismic-gatsby: Gatsby plugins for building websites using Prismic) and recently moved to v5. We notice that our previews break when we add a custom type because it throws a "no type for path" error. See also this issue: No type for path · Issue #512 · prismicio/prismic-gatsby · GitHub
I understand that the preview feature wants all types to be somewhere, but this is really annoying for us. Here is a minimum example that highlights this:
1: You have prismic running on a production site. Content editors are updating content and previewing all the time.
2: Someone updates the type in Prismic because of a future new text thing
3: Production previews are broken until developers release a new version
When in this example the content editors want to preview something, it doesn't have to crash, because the new type cannot be visible on the website by definition (it's usage is not in the code yet). So why crash? Why not just ignore the type.
Could the throw be removed? Or at least an option added to either throw (default behaviour if it makes sense for other use cases) or ignore, so we can set that option. We now have to fork the repo to remove the throw...
Thanks a lot!
Hello @luc.hendriks, thanks for reaching out.
This is probably because the new Custom Type doesn't exist on the front-end yet. For example, if you have a Custom Type Page, and you modify the content of a text field and then preview it, you will be able to see the new content of the field. But if you add a new text field instead, or change the API ID of the original field, your repository won't know where to render it.
Yes that is exactly the point. When you create the new custom type, immediately all previews break until we push a new version to production.
However, until that version is pushed to production, that new type cannot by definition be visible on the production site, so the preview does not have to break.
We do not create a new custom type and the code for that type in one go. We might need a few days to code the stuff to make the new custom type visible and then push it to production. This leads to previews being broken nearly always...
We want to be able to ignore the error instead of a hard throw, because the error is actually not a problem.
Could you please detail the steps you followed until you found this problem? We'd like to understand the entire process so we can reproduce it on our end.
It still makes sense that document previews break if their Custom Type doesn't exist on the front-end.
Sure, our setup is as follows: we have 1 Prismic environment for development and production, a development environment, staging environment, review apps (so every pull request has its own environment) and a production environment.
Now suppose there is a website. It is the same on staging and production, no open pull requests, everything is fine. It uses prismic custom types etc and previews work just fine. There are several people (not developers) creating content on prismic all the time, so assume the preview function is used by multiple people the whole time during the day. The content people type the documents and preview on the production website always.
Now we need a new feature that requires an additional custom type. The developer needs to do 2 things: 1) create the custom type in prismic, 2) update the code to use the custom type to show things.
The developer needs the custom type in his development environment before he can do the graphql query required to load the data for his React component. So he creates the new custom type and starts building.
The moment the developer creates the custom type, previews on the production site are broken. Sure, the content people can now fill in data for the new custom type, but the current production site does not have any code related to that new custom type yet (the developer is still building that). So instead of crashing, the preview function can just choose to ignore it. It cannot be previewed anyway because there is no code.
Until the developer built out the functionality using the custom type, tested it, made a PR, checked the review app, merged into main and finally did a production deploy the previews remain broken.
Finally it is merged, previews work again yay. However now we need a new custom type, so previews are broken again.
There are multiple solutions for this:
- Use a different environment for development and production. However then we need to sync the custom types. Note that it was working fine before v5 and just for this simple functionality creating this whole syncing stuff is overkill
- Use your development environment functionality. But that is basically saying "previews don't work properly until you pay at least $500/month plus $3000/year per environment" which I cannot imagine is part of your master plan
- Just do not let the preview script crash when a particular type is not in the code
Thank you for detailing your use case. The team agrees a fix is needed as soon as possible.
For now, we recommend using the Trigger it button in your repository’s Webhook settings. agreed that