- Issue created by @wim leers
📌
[later phase] Support matching `{type: array, …}` prop shapes
Postponed
added support for type: array
, including for DynamicPropSources
(aka finding an existing field instance whose cardinality fulfills the requirements of the SDC prop's shape).
However, that means lower-cardinality (e.g. max 3 values) field instances cannot populate higher-cardinality SDC props (e.g. max 20 items), and vice versa: higher-cardinality (e.g. max 50 values) field instances cannot populate lower-cardinality SDC props (e.g. max 20 items).
Hence we have this in place right now:
if ($cardinality_in_json_schema !== $field_cardinality) {
// For finite cardinalities, we can still allow a lower cardinality (>1)
// field instance to be matched with a higher cardinality JSON schema.
// For example: a `maxItems: 20` SDC prop could be populated by a field
// instance with cardinality 5. But a single-cardinality field would not
// make sense, because it's no longer an array.
// All other cases would result in problematic UX.
// @todo consider allowing/supporting (but needs UX to be designed first to disambiguate the cardinality mismatch):
// 1. JSON schema cardinality `unlimited`, field cardinality 1–N => would mean only partially populating an array
// 2. JSON schema cardinality `1-N`, field cardinality `unlimited` => would mean some structured data values would not be visible; the content author would need to either be informed only the first N would be visible, or they'd need to be able to pick specific values
if (!($field_cardinality > 1 && $cardinality_in_json_schema > $field_cardinality)) {
continue;
}
}
This issue exists for that @todo
.
TBD, needs design. Significant mental model mismatch risks here! ⚠️
Postponed
0.0
Page builder