Directly render preview, don't simulate click

This issue has led to a study of how $node->in_preview works. One key place where in_preview is used in the node module's NodeForm::form method. This logic attempts to reload the entity by using the uuid that was previously stored in the temp store.

// Try to restore from temp store, this must be done before calling
    // parent::form().
    $store = $this->tempStoreFactory->get('node_preview');

    // Attempt to load from preview when the uuid is present unless we are
    // rebuilding the form.
    $request_uuid = \Drupal::request()->query->get('uuid');
    if (!$form_state->isRebuilding() && $request_uuid && $preview = $store->get($request_uuid)) {
      /** @var \Drupal\Core\Form\FormStateInterface $preview */

      $form_state->setStorage($preview->getStorage());
      $form_state->setUserInput($preview->getUserInput());

      // Rebuild the form.
      $form_state->setRebuild();

      // The combination of having user input and rebuilding the form means
      // that it will attempt to cache the form state which will fail if it is
      // a GET request.
      $form_state->setRequestMethod('POST');

      $this->entity = $preview->getFormObject()->getEntity();
      $this->entity->in_preview = NULL;

      $form_state->set('has_been_previewed', TRUE);
    }

While work has progressed in 📌 On by default, make off-by-default an opt-in setting Closed: duplicate , we were able to get there by delegating all the work to the existing button-driven method of creating the openOffCanvasDialog method we've used throughout Phase 1. It would be really great to understand what the gap is between our effort to handle all of this without that button (the "easy" way). That would allow us to not need to simulate clicks.

In regard to the "preview" button. We have learned more about why we rely on clicking that button. I create a flowchart explaining that whole thing. In short, the preview button does a lot of heavy lifting for us that we might just want to delegate to CORE to handle for us at the end of the day. I think we can stop pursuing an alternative there.

But the "toggle Preview" button we have added is still a good option to takeover. I'll continue pursuing a solution by pulling bits from 📌 On by default, make off-by-default an opt-in setting Closed: duplicate . That issue can be reduced in scope so it can be merged.

I recently came across some code in core that is relevant to this issue, within EntityDisplayFormBase.php:

    // In overviews involving nested rows from contributed modules (i.e
    // field_group), the 'plugin type' selects can trigger a series of changes
    // in child rows. The #ajax behavior is therefore not attached directly to
    // the selects, but triggered by the client-side script through a hidden
    // #ajax 'Refresh' button. A hidden 'refresh_rows' input tracks the name of
    // affected rows.
    $form['refresh_rows'] = ['#type' => 'hidden'];
    $form['refresh'] = [
      '#type' => 'submit',
      '#value' => $this->t('Refresh'),
      '#op' => 'refresh_table',
      '#submit' => ['::multistepSubmit'],
      '#ajax' => [
        'callback' => '::multistepAjax',
        'wrapper' => 'field-display-overview-wrapper',
        'effect' => 'fade',
        // The button stays hidden, so we hide the Ajax spinner too. Ad-hoc
        // spinners will be added manually by the client-side script.
        'progress' => 'none',
      ],
      '#attributes' => ['class' => ['visually-hidden']],
    ];

I thought it was interesting that using hidden elements to trigger AJAX behaviors is already in core.

Marking as postponed as I don't think we have current plans to refactor this. But wondering if this one should be wontfix. We're pretty deep into making use of hidden elements...