Discovered while discussing #3461499-17: Support complex SDC prop shapes: introduce (Storable)PropShape to compute field type storage settings → in-depth with @lauriii.
Hypothetical scenario:
{type: string, format: date}.StaticPropSource that uses core's datetime field type, with the datetime_type setting set to date.timestamp field type, plus the unix_to_date adapter (which already exists: \Drupal\experience_builder\Plugin\Adapter\UnixTimestampToDateAdapter).Existing content will continue to work, because the StaticPropSource is self-contained. It will continue to use the datetime field type.
But this also means the UX will be different: a different widget is presented.
So the Content Creator should have the ability to update the component's existing stored props to whichever the updated default field types are for each prop shape.
⚠️ For now this is pretty hypothetical: moving from one field type to another is not very likely because ✨ [later phase] PropShapes' JSON schema must match exactly with FieldType's storage format — what if you want to use another FieldType? Active . Changing the widget is far more likely.
Something like:
(hacked together by @lauriii — different wording obviously, because this is not a different "component version")
Implementation: TBD. In the example above, the data that is stored is very different: something like 2024-07-26 vs 1721992490. How do we transform from one to the other? The answer is not too far-fetched: just another adapter, i.e. the inverse of the already existing unix_to_date would suffice … except that we have no way to record this information. One way could be to update the Component config entity to store not only the current default field type, but also past default field types, as well as an adapter to go to adapt to a subsequent field type, something like:
defaults:
props:
event_date:
field_type: datetime
field_widget: datetime_default
default_value: 1721992490
expression: ℹ︎datetime␟value
previous_field_types:
-
field_type: datetime
adapter: datetime_to_unix
Related: 📌 [PP-1] Prevent modules from being uninstalled if they provide field types used in an Experience Builder field Postponed and follow-ups: because an alternative to the above could be that any such change should have an accompanying update hook.
TODO: screenshots
Postponed
Page builder
Just realized that this is actually far out because of ✨ [later phase] PropShapes' JSON schema must match exactly with FieldType's storage format — what if you want to use another FieldType? Active .