Allow easily creating dialog links

Here is the first try.

Added \Drupal\Core\Link::$attributes with getter/setter because we need attributes for dialog links.

One thing I noticed with this patch is that if you call \Drupal\Core\Link::openInDailog() and then call \Drupal\Core\Link::setAttributes you will overwrite your the attributes for the dialog.

So maybe it would make more sense in ::openInDailog() to simply save parameters and then in toRenderable()
add what is needed to make the dialog link.

This will need test but for now this is how you would create a dialog link:
Link::createFromRoute('Click me!', 'tester.route')->openInDailog('dialog', 'off_canvas')->toRenderable(),

I switched getAttributes() to merge dialogAttributes and regular attributes. So this will return the actual attributes that will be used on the link.

This is important because setAttributes() might be called to set the 'class' but you 'use-ajax' would need to used regardless.

Also added a @todo noting that toString() because this is used for converting in twig templates I think. So it would need to take into consideration attributes now and #attached.

Adding #2529560: Expand support for link objects for history

I think adding redirect via 'destination' is important for dialog forms. So I also created #2944791: Create a "setDestination" method on \Drupal\Core\Url to make it easier to set the destination

I previously created #2933379: Automatically add 'use-ajax' class when 'data-dialog-type' is used which also was trying to address some of the complexity of creating dialog links.

Not sure if we would still need that

@borisson_ yes that makes sense. Fixed

Simplified the patch a bit.

I originally add the '#attributes' => .. to \Drupal\Core\Link::toRenderable() because I thought link objects didn't allow you set attributes on the <a> tag.

Of course this isn't true. The URL object itself takes care of this. Looking at the doc for \Drupal\Core\Url::fromUri() the $options parameter supports

* - 'attributes': An associative array of HTML attributes that will be
* added to the anchor tag if you use the \Drupal\Core\Link class to make
* the link.

So we can just use this. This allows the same logic to be used from ::toRenderable() and ::toString().

Right now ::toString() doesn't handle attaching the core/drupal.dialog.ajax. Not sure how to handle that yet.

After looking at this again I wonder why not move all this logic to \Drupal\Core\Url itself?

This would make dialog links much easier even when using it like this

'dialog_link' => [
   '#title' => 'Click Me Dialog!',
   '#type' => 'link',
   '#url' => Url::fromRoute('tester.dialog_callback')->openInDialog('dialog'),
],

In this case then you won't have to worry about the attributes or adding the 'use-ajax' class.

Then if we just add a helper function to Link then can still do:
'modal_link' => Link::createFromRoute('From object', 'tester.simple_form')->openInDialog();

Regarding the problem making sure 'core/drupal.dialog.ajax' library is always attached I have moved this to \Drupal\Core\Render\Element\Link::preRenderLink() and it simply checks for data-dialog-type as was suggested by @bedir in #2933379: Automatically add 'use-ajax' class when 'data-dialog-type' is used.(which would no longer be needed.

+++ b/core/lib/Drupal/Core/Url.php
@@ -655,6 +662,7 @@ public function getOption($name) {
   public function setOptions($options) {
     $this->options = $options;
+    $this->setDialogAttributes();
     return $this;
   }

@@ -672,6 +680,9 @@ public function setOptions($options) {
   public function setOption($name, $value) {
     $this->options[$name] = $value;
+    if ($name == 'attributes') {
+      $this->setDialogAttributes();
+    }

Here I decided call setDialogAttributes() to make sure that getOption('attributes') would always return the correct attributes that would be what is actually is used to generate a link.

Otherwise existing code that might be checking to see if 'data-dialog-type' see if the link will be in dialog can still rely on this.

I am not sure how else right now you would test if a Url object would produce a dialog link.

+++ b/core/lib/Drupal/Core/Link.php
@@ -147,4 +147,16 @@ public function toRenderable() {
+  public function openInRenderer($renderer, array $options = []) {
+    $this->getUrl()->openInRenderer($renderer, $options);
+    return $this;
+  }

@Sam152 the idea of moving the logic to the renderers themselves is interesting and would more flexible for future renderers.

My concern about this approach is it moves the DX problem from having to know what specific attributes to add to render array to having to know what "renderers" are in Drupal. Then also knowing the difference "main content renderers"(though not mentioned here) and other uses of the "renderer" in core.

It maybe that to everyone involved in this issue that the meaning is clear but I would doubt that would the case for Drupal developers who are trying to make a contrib module or especially some simple custom code where they would like to create link that will open in dialog.

If feel like before I got involved in core development(though with a lot of d8 contrib experience) a "main content renderer" would mean nothing to me and if I was creating a link and was searching available methods on the Link object ro figure out how to make it open in dialog, then openInRenderer would not be a method I would explore further.

For that reason I am not sure this solves the initial idea of this issue to "Allow easily creating dialog links". It makes it easier if you already have considerable core knowledge otherwise I don't think it does.