Use webcomponents for dropbutton

At this point I'm looking for feeback on the overall approach. Chose dropbutton because it's self contained, and it's not related to forms. Other webcomponents that could be interesting: autocomplete, marchine name, vertical tabs, time diff, etc. anything self-contained that uses behaviors for init.

This makes dropbutton jquery-free as a side effect.

This makes core use the defer attribute, which will prevent a few things from working regarding aggregation at the moment, see 🐛 JavaScript aggregation should account for "async" and "defer" attributes Needs work .

Curious how accessible this to screen readers for example?

Accessibility is not an issue with this one. We don't use the shadow dom, the markup is stricly the same as before inside, and the drupal-dropbutton replaces a div which has no special meaning either.

I think this is a great idea. And I love the potential for our custom components to be used in other setups, such as if we had a custom menu component, I can imagine other developers using it in their personal projects or other CMSs learning from it, using it, or adapting it to make it suit their. use case.

Excited about this! So called 'html web components' (components that add behaviors to mostly existing markup and don't use the shadow dom) really seem to be catching on. Issues like this will also be super useful to demonstrate how to take advantage of existing Drupal js functionality inside a custom element. Or even better, to demonstrate the js features we don't actually need anymore.

Thanks @brianperry for pointing me to this issue.

In case it comes up. Yes, web components can be accessible.
https://www.erikkroes.nl/blog/accessibility/the-guide-to-accessible-web-...

That's what we can do today. If the Accessibility Object Model ever lands then we'll have low-level capability to do even more.

I can't believe how simple this MR looks 😳 🤩

This makes dropbutton jquery-free as a side effect.

👏

I actually like the idea of core staking a claim to own the drupal- namespace for custom elements.

+1

Need help with the test failures here.

First is the test testAdvancedCaching I do not have a clue why this happens, fails with

 Caused by
 ErrorException: Method "IteratorAggregate::getIterator()" might add "\Traversable" as a native return type declaration in the future. Do the same in implementation "Drupal\Core\Entity\ContentEntityBase" now to avoid errors or add an explicit @return annotation to suppress this message.

And the rest of the failures happens because selenium doesn't seem to think that our custom element can be interacted with. Haven't found out why yet.

How could a Kernel test fail due to front-end changes?! 🤯

Ah, quoting \Drupal\Tests\views\Kernel\Plugin\RowRenderCacheTest::doTestRenderedOutput():

      $expected = $access ? '  <div class="dropbutton-wrapper" data-drupal-ajax-container><div class="dropbutton-widget"><ul class="dropbutton">' .
        '<li><a href="' . $node_url . '/edit?destination=/" hreflang="en">Edit</a></li>' .
        '<li><a href="' . $node_url . '/delete?destination=/" class="use-ajax" data-dialog-type="modal" data-dialog-options="' . Html::escape(Json::encode(['width' => 880])) . '" hreflang="en">Delete</a></li>' .
        '</ul></div></div>' : '';

You'll need to adjust those expectations 😅

thanks! fixed that one.

Hopefully the selenium one won't be too bad…

I bet it's something about the selectors used in the test 🤓

Have not reviewed.

Seems to have some test failures though.

selenium not happy with webcomponents :/

Such an interesting issue! Replacing all Drupal behaviours by WebComponents looks exciting: one less Drupalism & better performance.

Is it possible to do the same with "normal" markup instead of a custom element? Leveraging the is attribute and using the web component only as an (efficient) behaviour bag:

<div is="drupal-dropbutton" class="dropbutton-wrapper dropbutton-multiple">
<div class="dropbutton-widget">
<!-- ul, li, li, li, li -->
</div>
</div>

Advantages:

• faster to convert the renderable once the JS is updated, just replace data- attributes by the is attribute
• even faster rendering because server-side goodness
• no accessibility issues because we are back to good old markup
• Selenium may prefer this one :)

Unfortunately, Safari would need a polyfill for now.

ok so with selenium, using webcomponents needs to happen through some JS, not with the driver methods, then it works.

Not ideal but at least it's green.

Had to mess with file weight for the JS so that the theme function is used for claro, that might cause some issues in contrib. Would have been ideal to have the before/after thing for scripts to replace weights.

How does this relate to ✨ Add new Splitbutton render element to eventually replace Dropbutton Needs work ?

Would make sense to make splitbutton a webcomponent too and not do it for this one. If we can't make all the dropbutton into splitbuttons at once it still makes sense to keep this one around.

This one was a test to check testability in our stack and the gotchas of using Drupal.theme()

The Needs Review Queue Bot → tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

Rebased as it was 200+ commits behind.

But what's a good way for testing? I'm on the branch and went to admin/content view and everything seems to be working as before.

Seems rebase caused some failures. But would still appreciate some testing steps.

What about using the is attribute instead of a custom element for this WebComponent, as proposed in #19 📌 Use webcomponents for dropbutton Needs review ?

So:

• no DOM bloat whatsoever
• markup is graceful enhanced
• stay SSR friendly out of the box
• we have all life cycles we like from Custom Elements, so we can replace Drupal JS Behaviours

https://css-tricks.com/supercharging-built-in-elements-with-web-componen...

The Needs Review Queue Bot → tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

False positive

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.