Proposal to use Lit / web components for building Drupal’s administrative UIs

Created on 8 October 2017, over 6 years ago
Updated 8 May 2023, about 1 year ago

Follow-up to 🌱 Proposal to use Vue.js for building Drupal’s administrative UIs Postponed , #2913321: Proposal to experiment with React for building Drupal’s administrative UIs

Problem/Motivation

At DrupalCon Vienna, Dries proposed a new strategic initiative to test and research how our admin UX could be improved by using a JavaScript framework. As a first step, we have to choose which JavaScript framework will be used as part of the research.

This issue has been created to explore the possibility that Web Components can assist the selected framework by providing a common standard for making, reusing, and sharing our work on frontend components.

If you have knowledge of React, here's a great walk through of differences, advantages and disadvantages: https://jeremenichelli.github.io/2017/10/the-web-components-experience/

Proposed resolution

Use webcomponents wrapped with Lit. While there are many ways we can work with the set of web standards that are collectively known as Web Components, Lit provides excellent documentation, practice projects and community support for writing Web Components. As we speed towards making a proof of concept we'll need to iterate fast and try a bunch of stuff. So we're going to start with Lit and see how it goes.

Proofs of concept

  1. https://github.com/attiks/dblog-ui based on https://github.com/Chi-teck/dblog-ui written in Vue v1 by @Chi

Requests for comment

We kicked of some polling / requests for comment from the community here and on other social media platforms. See:

  1. https://plus.google.com/+ChrisWeber/posts/YxQw9jwiVzU
  2. https://www.reddit.com/r/drupal/comments/75hv6j/user_research_what_do_yo...

Benefits of Lit/webcomponents

Can be used by any framework (JS, PHP, other)
Emerging standard that could one day be the foundation of all web component creation.
Approachable by novices, React developers, and Angular developers alike.
Growing vibrant ecosystem and great documentation.
Designed for incremental adoption which will allow Drupal to ease in to decoupling its frontend.
Never had a license concern

Challenges

  • Like jQuery and picturefill, the polyfill and library adds a bit to the page load to provide support for browsers that don't full support the standards. We need to measure and report on what the practical impact to page load is.
  • Need a way to allow developers to discover and reuse the components we are making. Consider publication on Webcomponents.org

Getting started

Next steps

Probably similar to the React issue:

Gauge community interest, and flesh out any hard blockers (this issue)
Replicate a “proof of concept” project—Database Logging UI.
Identify changes to our supporting infrastructure, e.g. do we need new/changed build tools for packaging, testing infrastructure, etc.)
Research release cycle and develop a plan.
Rewrite code to plain webcomponents

Your feedback

The focus is on how we can solve this using webcomponents, for the moment using Lit as a wrapper to speed development, but in the end we should discuss how we can publish this work as vanilla webcomponents, either in this issue or a separate one. The reason Lit was selected is that it allows us to re-use an existing component for the data grid.

🌱 Plan
Status

Postponed

Component

Idea

Created by

🇧🇪Belgium attiks

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • 🇬🇷Greece pinkonomy

    Any progress on this?

  • 🇺🇸United States cosmicdreams Minneapolis/St. Paul

    Kind of actually. With Drupal 10.1's single directory components we're able to start building components that work within Drupal Core. Now we just need to demonstrate a component or set of components that provide value to the system. We're also able to compare and contrast different approaches to making components.

    Here's a component I made with lit for reference: https://www.drupal.org/project/pokemon_card

  • 🇬🇷Greece pinkonomy

    @cosmicdreams
    Thanks for the reply.
    I have a question:Do we need to build web components specific to Drupal?
    Wouldn't it be better to use existing components e.g. from Lit?

  • @pinkonomy - yes and no. It would probably be best to take some dumb components (design specific) and use them as the basis to wire into smart components (drupal specific). There are many out there but the two I think are the most well developed as far as providing reusable pieces that are within a specific design system they'd be:
    - https://shoelace.style/
    - https://github.com/material-components/material-web

    Both are built on top of Lit and are very small as a result.

    @cosmicdreams is correct that Drupal has a methodology for organizing and loading these assets.

  • 🇺🇸United States cosmicdreams Minneapolis/St. Paul

    @pinkonomy: I think this question goes back to the classification of components. I like to think of it as:

    • display component: just frontend stuff, intakes variables prepared by the server
    • layout components: components with slots, built to wrap other components
    • data-driven components: components that are built to got fetch data from outside sources

    Now, I suspect that either with web components / lit or not. The fact that we can componetize bits of markup and share them (like within a module or a theme) will help Drupal go a long way down the road to making it easier to interact with Drupal's from a template / component level. And whether the final component was written with vanilla / lit / whatever component library, the way we'd interact with it via twig will be the same. As a result, it would likely be a good idea to make each component be self contained.

    We'll have to see.

    One of the adventures I'd like to do before Drupalcon is to take a component library and see what it would take to convert it to SDC. A few I've looked at for that effort include:

    Now I'll add shoelace

Production build 0.69.0 2024