I've come to realize while dealing with caching and syncing in Field Kit that I haven't really addressed the issue of the type field in resource identifiers, with regard to how its defined in the JSON:API spec. This is somewhat complicated by [how Drupal implements the spec]() to accommodate its entity/bundle model:
The type member is always required. The value for the type member is derived from the entity type name and bundle, where applicable. The type for an entity resource always follows the pattern entity_type--bundle. As an example, the core article and basic page node types will be represented as: node--article and node--page.
I've already departed from the Drupal convention insofar as I've transformed the type member of resource objects themselves, removing the entity type and hyphens and just leaving the bundle name, via the transformRemoteEntity function used by the adapter. But I've refrained doing something similar to the type member in resource identifier objects, which are used primarily in relationships, because without the bundle and the entity name, it could be hard if not impossible to definitively identify which entity/bundle is being referenced, at least without querying every entity by its UUID.
A few possible solutions:
Add an entity or entity_type member to resource identifiers. As an extension of JSON:API, this is not prohibited, but not exactly encouraged either. It seems a little heavy-handed in general.
Add the entity to the meta member of the resource identifier. This seems like a "softer touch," but I'm not sure this information should be relegated to meta, since it's absolutely critical to identifying the resource.
Create something like a custom format or other means of distinguishing the resource type for each relationship in the JSON Schema, rather in the data itself. It couldn't actually be a format, b/c that's for strings alone, but some kind of definition or vocabulary. I'll have to read up on the best way to do this, but I think I slightly favor this approach as of now.
Leave it as is, and use the entity_name--bundle convention in resource identifiers while continuing to use only the bundle in resource objects.
That last option, to leave it as is, is what I will do for now, and it's probably sufficient for now, at least where farmOS.js is being used in Field Kit, but I could see this as being critical to the development of more robust functionality in the future.
jgaehring
commented
2 years ago
I've come to realize while dealing with caching and syncing in Field Kit that I haven't really addressed the issue of the
typefield in resource identifiers, with regard to how its defined in the JSON:API spec. This is somewhat complicated by [how Drupal implements the spec]() to accommodate its entity/bundle model:I've already departed from the Drupal convention insofar as I've transformed the
typemember of resource objects themselves, removing the entity type and hyphens and just leaving the bundle name, via thetransformRemoteEntityfunction used by the adapter. But I've refrained doing something similar to thetypemember in resource identifier objects, which are used primarily inrelationships, because without the bundle and the entity name, it could be hard if not impossible to definitively identify which entity/bundle is being referenced, at least without querying every entity by its UUID.A few possible solutions:
entityorentity_typemember to resource identifiers. As an extension of JSON:API, this is not prohibited, but not exactly encouraged either. It seems a little heavy-handed in general.metamember of the resource identifier. This seems like a "softer touch," but I'm not sure this information should be relegated tometa, since it's absolutely critical to identifying the resource.formator other means of distinguishing the resource type for each relationship in the JSON Schema, rather in the data itself. It couldn't actually be aformat, b/c that's for strings alone, but some kind of definition or vocabulary. I'll have to read up on the best way to do this, but I think I slightly favor this approach as of now.entity_name--bundleconvention in resource identifiers while continuing to use only the bundle in resource objects.That last option, to leave it as is, is what I will do for now, and it's probably sufficient for now, at least where farmOS.js is being used in Field Kit, but I could see this as being critical to the development of more robust functionality in the future.