Make preview responses cacheable to accelerate previews

A few hours later, this happened: #2844822-25: The preview in CKEditor does not use the same Twig template as the one on the front end (default theme). In part spawned by this issue causing me to take another look at it 🤓 🥳

If that lands, then this can simply delete the @todo.

#2844822: The preview in CKEditor does not use the same Twig template as the one on the front end (default theme) landed.

I've got an exciting new patch for y'all … thanks to #2844822-25: The preview in CKEditor does not use the same Twig template as the one on the front end (default theme) we know we don't need to use the AJAX system anymore (and we don't anymore as of #2844822 landing), we also have solid test coverage even before #2844822 but with #2844822-40: The preview in CKEditor does not use the same Twig template as the one on the front end (default theme) even more so, and in #2844822-41: The preview in CKEditor does not use the same Twig template as the one on the front end (default theme) I pointed out that we're now using nothing of the Drupal AJAX system anymore which opens the door to making the response cacheable…

So without further ado, here we go: a test asserting using the Resource Timing API (https://developer.mozilla.org/en-US/docs/Web/API/Resource_Timing_API) to verify that the browser is indeed caching the response and is hence resulting in a much improved UX. Of course, this will fail right now.

-            success: function (data) {
-              for (var i = 0; i < data.length; i++) {
-                if (data[i].command === 'embed_insert') {
-                  widget.element.setHtml(data[i].data);
-                  callback(widget);
-                }
-              }
-            }

Since #2844822: The preview in CKEditor does not use the same Twig template as the one on the front end (default theme), the Drupal AJAX response was merely a means of transportation; we were picking out the data for a single AJAX command, and were ignoring the add_css AJAX command for example if that existed. (Of course, prior to #2844822, that command was executed, but didn't have any effect on <iframe> CKEditor instances: the add_css command operated in the main frame!

So, since there's no point in sending that data, there's also no point in using a controller that returns AJAX responses that we then have to parse manually anyway. If we simplify that, we simultaneously gain the opportunity to cache the response on the client side, which we know is fine for Entity Embed responses, but we can't say that for sure about \Drupal\embed\Controller\EmbedController::preview(), which anything in contrib/custom code could be using for non publicly known things.

Did all that, and in doing so, this yielded the UX improvement we all were hoping for:

Before

After

(Those screencasts are with usleep(500000); in the controller, to simulate real-world less-than-ideal circumstances: response times of a little over half a second.)

Cleanup.

+++ b/entity_embed.routing.yml
@@ -5,3 +5,10 @@ entity_embed.dialog:
+entity_embed.preview:
+  path: '/entity-embed/preview/{filter_format}'
+  defaults:
+    _controller: '\Drupal\entity_embed\Controller\PreviewController::preview'
+  requirements:
+    _entity_access: 'filter_format.use'

+++ b/src/Controller/PreviewController.php
@@ -0,0 +1,89 @@
+  public function preview(Request $request, FilterFormatInterface $filter_format) {

Given this is 99% identical to embed.preview/\Drupal\embed\Controller\EmbedController::preview(), I feel confident moving ahead with this. Even more so thanks to our test coverage :)

To thinking about users on high-latency connections! To better user experiences!

🚢

🤷‍♂️

😊