Evaluate 'property paths' as an alternative syntax to prop expressions

Thanks, I definitely did not know about either of these!

1. field_tags:entity:revision_user:entity:name → this expression can only be evaluated on a given entity type+bundle context. Because not every entity type + bundle has a field_tags. That's why this is insufficient.
2. In that PropertyPath producer, the root_type is optional, which causes the same problem as the above. That seems possible to overcome though! Plus, I quite like the @DataProducer concept — that means the data could be produced using external data sources too.

   TIL the module exists. The fetchDataByPropertyPath() method indeed seems very similar. Test coverage seems thin, but that can be overcome.

There are three requirements neither of those meet:

1. the stored expression/property path must define what the expected root type is. XB's \Drupal\experience_builder\PropExpressions\StructuredData\Evaluator specifically checks StructuredDataPropExpressionInterface::isSupported() for this. Otherwise an expression cannot be evaluated in isolation. (Plus, this is used by ValidComponentTreeConstraintValidator(), too.)

   the code you linked from the GraphQL ecosystem could quite easily be updated to meet this one)

2. the ability to compactly represent fetching multiple field prop values from a field.

   XB's PropExpression:

   ℹ︎␜entity:node:article␝field_image␞␟{src↝entity␜␜entity:file␝uri␞␟value,width↠width,height↠height,alt↠alt}
   

   That single expression would require the following multiple property paths:

   entity:node:article.field_image.src.entity:file.uri.value
   entity:node:article.field_image.width
   entity:node:article.field_image.height
   entity:node:article.field_image.alt
   

   (although AFAICT that does not yet support entity:node:article in the expressions, or if it does, then there's no test coverage for it)

3. the ability to also describe the shape of the resulting data — in the above example entity:node:article.field_image.src.entity:file.uri.value would be the correct property path to retrieve a value from, but it doesn't yet capture the expected name/key is src

Preliminary conclusion

There is some prior art, but it does not do everything PropExpressions do. I'm working to capture that at 📌 Document the current JSON-based data model, and describe in an ADR Active .

FWIW search api overcomes these issues using data source plugins, you can index multiple bundles (and even multiple entity types) to the same index. Each field is a combination of property path and data source id. That gives you the root data type. Fields helper even has a filter by data source method which is similar to the isSupported

I concede that the multiple properties syntax is more verbose