Investigate possible token syntax and support for XB data

Created on 24 October 2024, 5 months ago

Overview

🌱 [META] Support alternative renderings of prop data added for the 'full' view mode such as for search indexing or newsletters Active demonstrates a requirement to be able to use XB data in scenarios other than rendering content.
One such use case is for metatags

Proposed resolution

Create a syntax and proof of concept for token support for extracting data from component properties.

Possible syntax

[node:xb:0:title] // title prop of first component
[node:xb:filter--cards:0:title] // title prop of the first cards component

User interface changes

πŸ“Œ Task
Status

Active

Version

0.0

Component

Data model

Created by

πŸ‡¦πŸ‡ΊAustralia larowlan πŸ‡¦πŸ‡ΊπŸ.au GMT+10

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @larowlan
  • πŸ‡§πŸ‡ͺBelgium wim leers Ghent πŸ‡§πŸ‡ͺπŸ‡ͺπŸ‡Ί

    title prop of the first cards component

    What if the cards components are reordered? 🫣

    I can see this working well if and only if these target component instances that are locked as described in 🌱 [META] 7. Content type templates β€” aka "default layouts" β€” clarify the tree+props data model Active β€” but that means you'd only be allowed to target content type template-defined component instances using tokens, not per-content entity ones.

    I think that limitation would work well, because for the metatag use case, you'd want to define these tokens at the content entity type bundle level, so that consistent meta tags are generated for all entities of that content entity type + bundle. The same is true for search indexing and newsletters.

  • πŸ‡³πŸ‡ΏNew Zealand john pitcairn

    What if the cards components are reordered?

    In that case I'd expect to get the new first card.

  • πŸ‡§πŸ‡ͺBelgium wim leers Ghent πŸ‡§πŸ‡ͺπŸ‡ͺπŸ‡Ί

    That's a simple technical solution, but is it also a valid semantical solution? Is it usable, understandable?

    It's easy to think of scenarios where a simple rearranging of components resuls in very different values for tokens, and that resulting value not being the Content Creator's intent.

  • πŸ‡³πŸ‡ΏNew Zealand john pitcairn

    Semantically it's the same as the first image on the page becoming the social media preview image, no? Make another image the first image and you'd certainly expect that to change. Content creators understand this.

    I think anything else is trying to be too clever and making a sizeable assumption. Provide an extension point and leave more case-specific solutions to contrib?

Production build 0.71.5 2024