Product Updates

Despite being somewhat scary, regular expressions are a very powerful tool. DatoCMS supports regex for filtering patterns in GraphQL queries. We just improved how we report syntax errors in regex to ease their usage and provide more precise feedback.

Now, providing a query like this:

{
  allBlogPosts(filter: {name: {matches: {pattern: "^+123"}}}) {
    id
  }
}

will get you the following error:

{
  "data": null,
  "errors": [
    {
      "message": "Invalid regular expression: quantifier operand invalid (provided regular expression: \"^+123\")",
      "locations": [
        {
          "line": 2,
          "column": 3
        }
      ],
      "path": [
        "allBlogPosts"
      ]
    }
  ]
}

Basically, with react-datocms v4.0.0 your responsiveImage() GraphQL queries can be reduced down to:

responsiveImage(imgixParams: { auto: format }) {
  src width height alt base64
}

• You can avoid requesting srcSet in the responsiveImage GraphQL query, as if it's missing, the React <Image /> component knows how to build it from src.

• You can avoid requesting webpSrcSet as well, because the { auto: format } Imgix transformation parameter offers even more performant optimizations (AVIF), without increasing the GraphQL response size.

• You can avoid requesting sizes, and just use the sizes prop on the Image component itself.

Overall, these changes can reduce the overall GraphQL response size significantly, especially when dealing with many images at once.

New props for Image component:

• priority: When true, the image will be considered high priority. Lazy loading is automatically disabled, and fetchpriority="high" is added to the image.

  You should use the priority property on any image detected as the Largest Contentful Paint (LCP) element. It may be appropriate to have multiple priority images, as different images may be the LCP element for different viewport sizes. Should only be used when the image is visible above the fold.

• sizes: If you're using this prop, you can avoid requesting sizes in the responsiveImage query.

• srcSetCandidates: If you're not requesting srcSet in the responsiveImage query, srcSetCandidates will be used to generate the different srcset candidate strings at various widths. Default candidates are: [0.25, 0.5, 0.75, 1, 1.5, 2, 3, 4].

A new major version (v5) of our popular Gatsby source plugin is out!

The biggest change introduced by version 5 concerns the management of locales. If until now, for each record, each locale generated a different Gatsby node, now the node is always one, regardless of the number of locales.

On projects with many languages and/or many records, this change produces tremendous savings in memory and build times (up to one order of magnitude).

As a consequence of this change, the way you must write GraphQL queries for localized content is changed.

We know this can be a big annoyance for those who want to upgrade, but on the other hand, everything is now much more similar to the way our GraphQL Content Delivery API works, and the new syntax allows for complex use cases that were simply impossibile to solve before.

For this release, we would like to publicly thank the Gatsby team for their support. We've worked closely together to take full advantage of Gatsby v4's latest customization capabilities, and where issues have arisen, they have been incredibly responsive in fixing them! 🙏

We just completed a comprehensive update of our library for Vue — vue-datocms, now at version 3:

• it now supports both Vue 2 and Vue 3 via VueDemi, thus opening the possibility of easily using Vue composition API with DatoCMS;

• it comes with first-class support for Typescript;

• it has new features, including multiple layout modes for the <Image> component.

We also took the chance for a due upgrade of our demo projects related to Vue. New-comers now have 2 solid starting points:

• vuejs-demo is now based on Vue 3 and the fast Vite.js;

• Nuxt users will enjoy the nuxtjs-demo, now based on Nuxt 3.

Finally, the DatoCMS website now contains two separate learning sections, providing a solid walkthrough for integrating Dato in projects based on Vue.

Our Next.js Blog starter has been updated and now offers the following enhacements:

• Preview Mode also works if you deploy it on Netlify;

• The SEO/Readability Analysis and Web Preview plugins are already installed and configured!

A small addition to our Plugins SDK: inside the renderFieldExtension hook, you can now access ctx.block.

If the field extension is installed in a field of a block, ctx.block returns the ID of the block — or undefined if the block is still not persisted — and the block model.

Our CLI just became a lot smarter, and can now automatically generate a migration script from the differences between two environments!

Read the complete announcement in our Blog.

Within a record, you can now add — and remove — multiple locales at once! Simply select all the locales you are interested in and press the relevant button:

This small change, along with the ability to automatically copy content from the currently selected language, greatly reduces editing time in projects with dozens of locales.

When you enter inside a sandbox environment, the URL of the administrative interface now changes to become the following:

https://<PROJECT-NAME>.admin.datocms.com/environments/<ENVIRONMENT>/editor

This allows you to share a link to a particular record/entity contained in a sandbox environment without confusion to your team members!

Starting October 10th, a couple of changes will be made to the CMA endpoints related to Workflows.

Workflows are a feature enabled in our Enterprise plans, so most of our users won't be affected by this change. All accounts actively using Workflows have already been notified via email about this change. If you did not receive an email, then you have nothing to worry about. 😉

Let's see how the workflow entity will change:

// Until October 10th:
{
  "type": "workflow",
  "id": "approval_by_editors",
  "attributes": {
    "name": "Approval by editors",
    "stages": [...]
  }
}
// From October 10th:
{
  "type": "workflow",
  "id": "123902133",
  "attributes": {
    "name": "Approval by editors",
    "api_key": "approval_by_editors",
    "stages": [...]
  }
}

As you can see:

• The old ID is now present in the new payload as attributes.api_key;

• The ID becomes a regular DatoCMS ID, immutable during environment forks.

Please note that it will still be possible to fetch, update and delete workflows by passing the API key in the URL, although it is suggested to use the ID.

It will be required to pass the new ID instead of the API key every time a workflow is referenced in another entity relationship (ie. when creating/updating a Model) and inside roles permission rules.