- Issue created by @wim leers
- Assigned to tedbow
- Status changed to Postponed
6 months ago 6:16pm 2 July 2024 - ๐บ๐ธUnited States tedbow Ithaca, NY, USA
We should fix ๐ All field item constraints are not found when evaluating prop matchs Active first
- ๐ง๐ชBelgium wim leers Ghent ๐ง๐ช๐ช๐บ
See #3458580-5: Document in great detail where constraints for data leafs is authoritatively defined โ โ that's in, but it might still be insufficient. I was unable to tell based on that issue summary + this issue.
- Issue was unassigned.
- ๐ง๐ชBelgium wim leers Ghent ๐ง๐ช๐ช๐บ
@tedbow is not actually working on this, but on ๐ Lift most logic out of ComponentTreeItem::preSave() and into a new validation constraint Needs work .
- ๐ง๐ชBelgium wim leers Ghent ๐ง๐ช๐ช๐บ
Actually, I think this would no longer be in the critical path once we do ๐ Support complex SDC prop shapes: introduce (Storable)PropShape to compute field type storage settings Fixed along with predefining the needed
PropShapeInput
s for someenum
-using SDCs.Demoting priority.
- ๐ง๐ชBelgium wim leers Ghent ๐ง๐ช๐ช๐บ
I don't think it is likely that a
{type: string, enum: โฆ}
SDC prop schema would be able to be supported by existing structured data (i.e. existing entity fields). IOW: aDynamicPropSource
for them seems to be a rather edge case need.But I do think it's a hard requirement that SDCs with such props are supported, so supporting
StaticPropSource
s for them is crucial.In working on ๐ Support complex SDC prop shapes: introduce (Storable)PropShape to compute field type storage settings Fixed , I realized that the "matching" infrastructure makes more sense for
DynamicPropSource
, but far less so forStaticPropSource
. And in fact โฆ I've got exactly this use case working there: https://git.drupalcode.org/project/experience_builder/-/merge_requests/1... - ๐ซ๐ฎFinland lauriii Finland
I don't think it is likely that a {type: string, enum: โฆ} SDC prop schema would be able to be supported by existing structured data (i.e. existing entity fields). IOW: a DynamicPropSource for them seems to be a rather edge case need.
This is indeed a scenario which doesn't work very well with the current
DynamicPropSource
concept because mapping enum values 1:1 introduces tight coupling between the data model and the components. I'm glad we're getting to the weeds because it helps us discover these scenarios.For this scenario, we'd need some concept of mapping values. I'm wondering if it would make sense to implement this as an adapter:
- ๐ง๐ชBelgium wim leers Ghent ๐ง๐ช๐ช๐บ
That's what adapters are indeed for.
- At a technical level, #9 is trivial. It already works, and has basic test coverage since ๐ Centralize & standardize logic for constructing *PropSource objects + kernel test coverage Fixed .
- But providing a UI for adapters is very hard, let alone one that achieves the superb UX that XB aims for.
- ๐ซ๐ฎFinland lauriii Finland
Thank you for confirming that @Wim Leers! I was worried that this would be challenging from technical perspective, and felt more confident about designing a UX for this. I would not say that it's a trivial UX task but it should not be insurmountable. I think that's a good sign given that we both feel good about this *high-five* ๐
- ๐ง๐ชBelgium wim leers Ghent ๐ง๐ช๐ช๐บ
This is not for ๐ฑ Milestone 0.1.0: Experience Builder Demo Active , so marking for a later phase.
More context: #3461499-17: Support complex SDC prop shapes: introduce (Storable)PropShape to compute field type storage settings โ .
- ๐ง๐ชBelgium wim leers Ghent ๐ง๐ช๐ช๐บ
Now that ๐ Clarify the "shape matching" bits: namespaces, `CODEOWNERS` and as issue queue component Fixed landed, the remaining work here became clearer:
-
๐
Support complex SDC prop shapes: introduce (Storable)PropShape to compute field type storage settings
Fixed
added support for a number of complex prop shapes when generating
static prop sources
(see 3.1.2.b in docs) โ see\Drupal\Tests\experience_builder\Kernel\PropShapeRepositoryTest::getExpectedStorablePropShapes()
for the supported ones - this issue is about adding support for those same complex prop shapes when matching
dynamic prop sources
(see 3.1.2.a in docs)
-
๐
Support complex SDC prop shapes: introduce (Storable)PropShape to compute field type storage settings
Fixed
added support for a number of complex prop shapes when generating
- ๐ง๐ชBelgium wim leers Ghent ๐ง๐ช๐ช๐บ
Because >50% of the https://git.drupalcode.org/project/experience_builder/-/merge_requests/73 MR won't be relevant anymore when #13 gets worked on eventually, I closed it.
3 tiny bits will still be relevant:
- https://git.drupalcode.org/project/experience_builder/-/merge_requests/7...
- https://git.drupalcode.org/project/experience_builder/-/merge_requests/7...
- https://git.drupalcode.org/project/experience_builder/-/merge_requests/7...
Now that I've explicitly linked those bits, it's definitely justified to have that MR closed.