[PP-1] Normalization of LinkItem's 'options' property

Btw maybe kind of fix for normalization of MapDataDefinition required?

It needs unit test to make sure ComplexDataNormalizer works fine

Unrelated failure, sorry, gave testbot a bit of a headache, might take a while to recover.

Now it needs aggregated patch #2+#9

+++ b/core/modules/link/src/Normalizer/LinkItemNormalizer.php
@@ -0,0 +1,39 @@
+class LinkItemNormalizer extends NormalizerBase {
...
+  protected $supportedInterfaceOrClass = 'Drupal\link\Plugin\Field\FieldType\LinkItem';

Hm… but:

    $properties['options'] = MapDataDefinition::create()
      ->setLabel(t('Options'));

So isn't the problem that maps aren't normalized correctly?

Looks good, but will conflict with #2577923: MenuLinkContent entities pointing to nodes are not deployable: LinkItem should have a "target_uuid" computed property where we also add a link item normalizer

Once #2871591: Allow ComplexData in TypedData to specify computed properties that should be exposed in normalization and other contexts is in, this will become much much simpler.

@WimLeers: That issue is not the solution for every problem :)

options is *not* a computed property, so I'm not sure that issue will help. It is possible a more generic solution is possible, but not through computed properties but generic support for exporting map properties.

If we do need a new normalizer here, it should be one on the data property level instead, i.e. a MapNormalizer? Another up side of that is that it would only need one normalizer in serialization module, not a field level implementation in both hal and serialization.

+++ b/core/modules/link/src/Normalizer/LinkItemNormalizer.php
@@ -0,0 +1,39 @@
+      if ($name == 'options') {
+        $options_attributes = [];
+        foreach ($field->getValue() as $key => $val) {
+          $options_attributes[$key] = $this->normalize($val, $format, $context);
+        }
+        $attributes['options'] = $options_attributes;
+      }

What you're doing here is basically what a MapNormalizer could/should/would do.

Tentatively moving back to open.

Wim, let me know if you still don't agree :)

This issue has been fixed on other issueMapData cannot be serialized by using a generic solution
which solved all data's normalization's problem that was defined as MapDataDefinition
1. core/LinkItem
2. commerce
3. BlockField
4. ...

@liuxin the issue is not solved and related #2895532: @DataType=map cannot be normalized, affects @FieldType=link, @FieldType=map is not a half way in, I'd better marked related as duplicate

Hi @andypost,
I don't understand

is not a half way in

It means "it's haven't been completely solved?" Or "it's not a shortcut“
Could you explain further?thanks

@andypost,Sorry for closing the issue hastily before,
The related #2895532: MapData cannot be serialized issue's resolution has divergence now
So, we should rethinking in the issue

I agree with the duplicate. The other issue is close and among other things, has specific test coverage for the link field.