Treat each view mode in "Rendered entity" formatter as a standalone formatter

1. +++ b/src/EntityEmbedDisplay/FieldFormatterEntityEmbedDisplayBase.php
   @@ -116,11 +111,18 @@ abstract class FieldFormatterEntityEmbedDisplayBase extends EntityEmbedDisplayBa
      /**
   +   * Returns the field formatter id.
   +   */
   +  public function getFieldFormatterId() {
   +    return $this->getDerivativeId();
   +  }
   

   Should add @return statement. Let's use this function on other places where getDerivativeId() is used at the moment. For consistency and to make sure overrides are always respected.

   I think that this last part actually introduces bugs at the moment. Button configuration form will throw a fatal if you limit the list of display plugins that can be used.

2. +++ b/src/Plugin/Derivative/ViewModeDeriver.php
   @@ -0,0 +1,59 @@
   +   * The entity type manager.
   ...
   +   * Constructs new FieldFormatterEntityEmbedDisplayBase.
   
   +++ b/src/Plugin/entity_embed/EntityEmbedDisplay/ViewModeFieldFormatter.php
   @@ -0,0 +1,82 @@
   + * Entity Embed Display reusing entity reference field formatters.
   
   +++ b/src/Tests/ViewModeFieldFormatterTest.php
   @@ -0,0 +1,55 @@
   + * Tests the view mode field formatters provided by entity_embed.
   ...
   +   * Tests view mode field formatters.
   ...
   +   * Tests filter using view mode Entity Embed Display plugins.
   

   This comments are not correct in one way or another. Review and fix them.

   Usually when we refer to "field formatter" we think "Entity Embed Display". Let's use that.

3. +++ b/src/Plugin/Derivative/ViewModeDeriver.php
   @@ -0,0 +1,59 @@
   +    foreach ($this->entityDisplayRepository->getAllViewModes() as $entity_type => $view_modes) {
   

   $entity_type is not used.

4. +++ b/src/Plugin/entity_embed/EntityEmbedDisplay/ViewModeFieldFormatter.php
   @@ -0,0 +1,82 @@
   + *   label = @Translation("View Mode Field Formatter"),
   

   "Field formatter" part is strange here. It can simply be "View mode".

5. +++ b/src/Plugin/entity_embed/EntityEmbedDisplay/ViewModeFieldFormatter.php
   @@ -0,0 +1,82 @@
   +class ViewModeFieldFormatter extends FieldFormatterEntityEmbedDisplayBase {
   ...
   +  public function getFieldDefinition() {
   +    if (!isset($this->fieldDefinition)) {
   +      $this->fieldDefinition = parent::getFieldDefinition();
   +      $this->fieldDefinition->setSetting('target_type', $this->getEntityTypeFromContext());
   +    }
   +    return $this->fieldDefinition;
   +  }
   ...
   +  /**
   +   * {@inheritdoc}
   +   */
   +  public function getFieldValue() {
   +    return ['target_id' => $this->getContextValue('entity')->id()];
   +  }
   

   If we extend EntityReferenceFieldFormatter instead of FieldFormatterEntityEmbedDisplayBase we're able to get rid of this two functions entirely.

6. +++ b/src/Plugin/entity_embed/EntityEmbedDisplay/ViewModeFieldFormatter.php
   @@ -0,0 +1,82 @@
   +    // Remove the configuration from entity_reference_entity_view. The view mode
   +    // is already set in getFieldFormatter.
   +    return [];
   

   This comment reads a bit strange. Maybe something like "Configuration form is not needed as the view mode is defined implicitly."

7. Readme file could use an update with this change.
8. Would be nice to have before and after screenshots.

Patch looks good to me. However, we need to handle BC. As @Berdir suggested we should probably create two "modes". In new mode we will make only view mode plugins available while in old mode that will be the case for Rendered entity display.

We can do this through configuration: add default config that will enable new mode and add an update hook that will enable old mode for existing sites.

Hiding should be done on UI level. All plugins should be created, but only the ones that are "active" in a given mode should be displayed in UI (button config and embed dialog). We could probably add a parameter to the plugin annotation that could be used to control display.

Please add screenshots to the issue summary.

1. +++ b/README.md
   @@ -49,18 +49,18 @@ Entity Embed can be installed via the
   +* If the entity you select is a node entity, for **Display as** you can choose one of the following options:
   

   Break the line to not exceed 80 chars.

2. +++ b/src/EntityEmbedDisplay/EntityEmbedDisplayManager.php
   @@ -95,13 +93,32 @@ class EntityEmbedDisplayManager extends DefaultPluginManager {
   +  public function filterExposedDefinitions(array $definitions) {
   +    return array_filter($definitions, function($definition) {
   +      return isset($definition['no_ui']) && $definition['no_ui'] == FALSE;
   

   Should this be protected?

   We could simplify the condition with empty($definition['no_ui'])

3. +++ b/src/Tests/EntityEmbedUpdateHookTest.php
   @@ -0,0 +1,43 @@
   +   * Tests hook_post_update_NAME().
   

   This comment is not accurate.

Two nit-piks before committing:

diff --git a/README.md b/README.md
index 9a260f0..7c008ae 100644
--- a/README.md
+++ b/README.md
@@ -49,7 +49,7 @@ Entity Embed can be installed via the
 * Click on the 'E' button in the text editor.
 * Enter part of the title of the entity you're looking for and select
   one of the search results.
-* If the entity you select is a node entity, for **Display as** you can choose 
+* If the entity you select is a node entity, for **Display as** you can choose
   one of the following options:
   * Entity ID
   * Label
diff --git a/src/Plugin/Derivative/ViewModeDeriver.php b/src/Plugin/Derivative/ViewModeDeriver.php
index 76cfd82..d3870d3 100644
--- a/src/Plugin/Derivative/ViewModeDeriver.php
+++ b/src/Plugin/Derivative/ViewModeDeriver.php
@@ -64,7 +64,7 @@ class ViewModeDeriver extends DeriverBase implements ContainerDeriverInterface {
         $this->derivatives[$definition['id']]['label'] = new TranslatableMarkup($definition['label']);
         $this->derivatives[$definition['id']]['view_mode'] = $view_mode;
         $this->derivatives[$definition['id']]['entity_types'] = $definition['targetEntityType'];
-        $this->derivatives[$definition['id']]['no_ui'] = $mode ? TRUE : FALSE;
+        $this->derivatives[$definition['id']]['no_ui'] = $mode;
       }
     }
     return $this->derivatives;

Committed. Thanks!

Can you tell more? What are your concerns? Is there any UX expert that wasn't involved into this or parent issue looking at this? Can we rather do it as a follow-up (setting this to "Needs review" without explaining what the plan is doesn't really mean anything)?

Diverging from re-using field formatters as they exist, same as I said in #4.

We didn't diverge from that. We are still using field formatter to do that. It is just presented differently. Nothing changed behind the scenes.

* No actual UX feedback on this change (can we hop in the UX community meeting for this, before proceeding further?)

Definitely. Let's open a follow-up issue and continue there. EE could use a general UX review and suggestions for improvements in that area.