Dato should know the final relative path associated with each record. To tell it, for each model, I would like to be able to define rules for how the record’s final relative frontend path is formed from its slug, related slugs, or related fields.
The benefits of this would be:
- When pulling record data from the API, we can also pull it with a correct related front-end path (because we have told Dato how to generate that path)
- DatoCMS could include a link picker (far more user friendly) when inserting inline links: the editor selects a record, Dato generates the correct path and inserts it
- DatoCMS slug field can show the actual final path in its prefix element automatically (more user-friendly for editors)
- Easily offer a link to click from viewing a record in DatoCMS to viewing the live page (in different deployment environments) – much more user-friendly “preview” experience
The Path Builder rules would be specified in Settings, under a new “Path Builder” tab. There is always a “Default” rule which is just “slug” (i.e. the path is the slug of the record); but more rules can be added. Each model then references the rule that it should use, in its settings. Again, the default for all models is to use the Default rule.
When creating a new Path Builder rule, we are offered a number of possible path-fragments, which we can add together in a list. These include an explicit
- “about” +
- “info” +
The final example there addresses the key use case, which is tree collections. The most common use case is that the path is formed by the slugs of all ancestors, concatenated with “/”.
In example 3, we specify that the path is formed from the value of the
category field within the record, plus the record’s slug. So, how do we handle fields that aren’t slug fields? It depends on the field’s type:
- Link: use the slug of the (first) linked record
- Date: format it (use can specify e.g. <Option: format:
- Anything else: stringify, and then slugify, the field value
At present, all path building logic is done after data is pulled down from Dato. That works, but it makes sense to me to be able to configure this at the CMS side, which may be a faster and simpler workflow for many types of app/site. Furthermore, if Dato knows the path, we can gain a number of UX improvements inside Dato as well.