Special fields on entity reference

I'm not sure I understand the question. Please be more specific. You should be able to see all the fields in the image entity via the image resource or using the includes.

Thanks for the details!

I also ran into the problem. As of now there seems to be now way to fetch it.

Besides the alt text, the image width and height values are also useful.

That seems reasonable. There can be dedicated normalizers for this.

1. +++ b/src/Normalizer/EntityReferenceFieldNormalizer.php
   @@ -85,17 +85,34 @@ class EntityReferenceFieldNormalizer extends FieldNormalizer implements Denormal
   +      // TODO: Add computed values?
   

   I think its fine to skip computed fields for now. Computed fields adds its own complexity.

2. +++ b/src/Normalizer/EntityReferenceFieldNormalizer.php
   @@ -85,17 +85,34 @@ class EntityReferenceFieldNormalizer extends FieldNormalizer implements Denormal
   +      // TODO: What about entity reference revisions?
   

   Conceptually I think that is its own complexity, maybe a submodule of ERR would be good on tp.

3. +++ b/src/Normalizer/EntityReferenceFieldNormalizer.php
   @@ -85,17 +85,34 @@ class EntityReferenceFieldNormalizer extends FieldNormalizer implements Denormal
   +      // TODO: Add access control on those properties?
   

   I guess you should check for \Drupal\Core\Access\AccessibleInterface for each property here, but core doesn't do it, nor there are properties which have that.

I started with some additional test coverage.

@Grimreaper
Oh yeah good point. I just wanted to put out some test ...

I like what I am seeing from a code perspective. A couple of comments:

1. +++ b/src/Normalizer/EntityReferenceFieldNormalizer.php
   @@ -85,17 +85,31 @@ class EntityReferenceFieldNormalizer extends FieldNormalizer implements Denormal
   +    $entity_reference_item_list = array_filter($field->getIterator()->getArrayCopy(), function ($item) {
   

   Can we use getReferencedEntities() instead?

2. +++ b/src/Normalizer/EntityReferenceFieldNormalizer.php
   @@ -85,17 +85,31 @@ class EntityReferenceFieldNormalizer extends FieldNormalizer implements Denormal
   +    $entity_list_metadata = array();
   

   Nit. Use [] instead of array(). (applies to other places as well)

3. +++ b/src/Normalizer/RelationshipItem.php
   @@ -86,7 +96,11 @@ class RelationshipItem {
   -    return [$this->targetKey => $this->getTargetEntity()->uuid()];
   +    return [
   +      $this->targetKey => $this->getTargetEntity()->uuid(),
   +      'meta' => $this->metadata,
   +      'target_key' => $this->targetKey,
   +    ];
   
   +++ b/src/Normalizer/Value/RelationshipItemNormalizerValue.php
   @@ -39,10 +39,16 @@ class RelationshipItemNormalizerValue extends FieldItemNormalizerValue implement
   -    return [
   +    $rasterizedValue = [
          'type' => $this->resource->getTypeName(),
   -      'id' => $value,
   +      'id' => is_array($value) ? $value[$value['target_key']] : $value,
        ];
   

   What is the reasoning behind adding this? Would it make more sense to pass the UUID around under a static 'target_uuid' key that we can expect during "rasterization"?

However I am not convinced that companion properties to a relationship are metadata at all. They are first class content, and they should be treated as such.

I did a bunch of research as part of this issue and found some relevant threads.

• http://discuss.jsonapi.org/t/working-with-data-on-relationships/859/1
• http://discuss.jsonapi.org/t/can-relationships-hold-attributes-as-an-alt...
• http://discuss.jsonapi.org/t/another-use-case-for-attributes-in-relation...

I believe that ultimately it all boils down to an architectural problem derived from the 1-to-1 mapping of resource and bundles. If that was not a limitation we could consider doing:

{
  "data": {
    "type": "node--article",
    "id": "article-uuid",
    "attributes": {
      "title": "Foo!"
    },
    "relationships": {
      "field_image": {
        "data": {
          "type": "file--image-instance",
          "id": "some-generated-id"
        }
      }
    }
  },
  "included": [
    {
      "type": "file--image-instance",
      "id": "the-same-generated-id",
      "attributes": {
        "title": "Image title",
        "alt": "Image alt"
      },
      "relationships": {
        "file": {
          "data": {
            "type": "file",
            "id": "image-entity-uuid"
          }
        }
      }
    },
    {
      "type": "file",
      "id": "image-entity-uuid",
      "attributes": { … },
      "relationships": { … }
    }
  ]
}

As of now, that is not possible so I believe that meta on the relationship is the best we can do for now.

Also I wonder if the "cid" and the "last_comment_uid" should be converted into the UUID of the entities.

I don't think that is the case. If a module (even if it is core) wants to store some normalized data for performance reasons, we should not transform it in any way. We should only turn references into their UUID when they are declared as entity relationships explicitly.

Can we use getReferencedEntities() instead?

Well, not really, because the entities don't contain the metadata we want here.

What is the reasoning behind adding this? Would it make more sense to pass the UUID around under a static 'target_uuid' key that we can expect during "rasterization"?

This is indeed a much nicer solution ...

One underscore too much.

Added some minor modifications. Merging if green.