Feature request: Centralized Variables

Hi there!

Sometimes I have pieces of information that need to live in different pages, custom types, or slices.

Let’s make a quick example.
In many e-commerce projects (mine included), we work with seasonal events like Christmas, Valentine’s Day, Easter, etc. In these cases, there’s often a last day to order that needs to be displayed in multiple places: on a page, inside a custom type, and of course inside one or more slices.

While working with Shopify, I noticed they provide “centralized variables” (metaobjects and metafields) that can be used almost everywhere in the theme.

Right now, my workaround is to create a configuration custom type, where I define these kinds of “key–value” parameters and then hard-code the fetch at the top of the app so they’re available inside slices.

It would be great to set up something directly at the Prismic level that can be referenced from different places. That way, thanks to centralization, if something changes (for example: “Hey, the last date is not the 8th anymore, it’s the 22nd”), you don’t have to go crazy hunting down every place where that value was used.

What do you think?

Hey @g.vallarelli!!

This is already achievable with Content Relationship fields.

You can create a dedicated custom type for things like seasonal banners or key dates, then add a Content Relationship field on the page types or slices where you need it. That way, you maintain the content in one place and reuse it everywhere it’s linked.

When the value changes, you update it once and it’s reflected across all linked pages. This is the intended way to handle centralized, reusable content in Prismic.

One pattern that works well on top of the Content Relationship approach, for the case where the value has to appear inside rich text (e.g. "Order by {{last_order_date}} for Christmas delivery"):

  1. Keep a single "settings" custom type (singleton) with a group of key / value fields.
  2. Fetch it once at the layout level (e.g. client.getSingle("settings")) and expose the key/value pairs through context or props.
  3. In your rich text rendering, use a custom serializer for text nodes that replaces {{key}} tokens with the matching value.

Editors can then write the token anywhere in a page or slice, and changing the date in the settings document updates every place at once. Content Relationship fields are still the better fit when you want a whole block (banner, CTA) reused; tokens are handy for short values that sit in the middle of a sentence.