Use JSON-LD schemas for partial block values

[tiberiuichim]

We sometimes have block values that we might want to transform in the backend (for example internal links, to transform them to use relativeuid, etc). The problem is that we don't have uniformity in our block values, so I could express a link as several "field names". It could be "url", it could be "href", or "internal_link" or whatever.

So that's the problem, we don't have types for our data. Now, we have the concept of "smart fields" sketched out: fields inside a block value that have special magical properties based on their name. The href and url are example of such "smart fields", as they're treated differently on the block transformer in the backend.

So maybe we should adopt JSON-LD to describe some values. Instead of saying "You should name your field like this to have magic behavior", we can say "schema.org URLs values are automatically resolve-uid'd", etc.

[davisagli]

@tiberiuichim I think this would solve some problems, but the thing that isn't clear to me yet is: how would we sync the schema between frontend and backend?

[tiberiuichim]

@davisagli no schema sync needed. What I'm proposing is something that the block data looks like this:

{"@type": "teaser", "someURLField": {"@type": "https://schema.org/URL", "url": "https://example.com"}}

Or, simpler:

{"@type": "teaser", "someURLField": {"@type": "URL", "url": "https://example.com"}}

Or something along these lines. I'm not suggesting that we fully adopt the jsonschema or the json-ld libraries, just that we get inspiration from them and do "typed values in json".

Then in the backend we can create a block value transformer that would recursively "look" inside all the block data fields and "fix them" according to their declared @type. Just as we do for the block data, we can do it for any other field inside the block data. We can use the "smart fields" to register such generic block transformers.

[davisagli]

@tiberiuichim Thanks for clarifying. I'm not sure I would call that a schema, but it's certainly one possibility to consider.