[meta] Organize components-related ideas

An issue to list all the components related issues from the ideas queue. Here "component" is used as a generic term that refers to a reusable set of html/js/css. It doesn't make any assumptions about the implementation (web components, react components, etc.) which is going to be a different subject/issue/discussion. The concern here is to regroup the different needs expressed in the many different issues talking about this topic.

• #2702061: Unify & simplify render & theme system: component-based rendering (enables pattern library, style guides, interface previews, client-side re-rendering) There are many things, some highlights (mix of goals/solutions):
  

  • bring style guide-driven development to Drupal as a default rather than a labor-intensive, hacked-on after-thought (without the need to duplicate markup and thus keep them in sync).
    • automatically generated pattern library (== all #type/@RenderElements — but without having to know those details)
    • automatically generated style guides for every theme (== pattern library with the theme's overrides/extensions applied)
  • Retain compatibility with the existing Render & Theme systems. Allow for a gradual transition.
  • components are not deeply tied to Drupal, and in fact, can be developed independently of Drupal
  • modules and themes can specify components — modules can define patterns that any other module can use, themes can specify theme-specific components

  • Component have a file that define all the metadata (variables, types, names, default values, etc.)
  • The Twig template (*.html.twig) performs all the necessary processing of the variables received, this ensures we don't depend on preprocess functions. This removes the need for front-end developers to dive into PHP.
  • components can be extended: add attributes, modify markup, and so on
  • components can be composed: combine multiple components to create a new component

• #3230518: Figure out how we want to incorporate web components in Drupal 10
  

  Add issue needs

• #3092431: [meta] Accommodate component-based theming
  

  The principle here is that the theme could become a mere collection of components. For this to make each component independent. Independent components have little to no link to the theme they are in. This makes it possible for those components to be dragged and dropped between theme, project and developer. It also means that each component is just a folder of files that holds all the complexity of a component, which makes it in turn super readable.

• #2875935: Add Components Module to Drupal CMS
  

  The components module allows Drupal to reference twig files outside of the /templates folder, making component-based design much easier and more maintainable for developers.

• #2235485: [meta] Automated Theme Component Library - Overall concept/discussion
  

  Make Drupal automatically create a styleguide from the theme hooks/css/assets

• #1804488: [meta] Introduce a Theme Component Library
  

  From Jacine Luisi post: Let's do something about Drupal's theme system

  • Provide a set of common markup patterns as wrappers to be called (button patterns, unordered list patterns, ordered list patterns, headers, def lists, form elements, etc…) with the goal of having one set of predictable, easy to override, semantic markup. Jacine has done a lot of great work on the demo page she put together already.
  • Provide an easy way for themes to override a specific pattern and have it apply to all patterns without the use of override functions.
  • Provide predictable, precise, and useful CSS classes based on SMACSS guidelines that are easy to override or remove, ideally without the need of lots of override functions.
  • Allow for components to ingest other components and template files (where appropriate).
  • Disallow, to the best of our ability, markup to be directly injected into a component from a theme function or for a theme function to output markup directly without using a template/component. This is extremely frustrating currently and continuing to allow this would defeat the purpose of the component library.
  • Provide development and UI hooks to allow developers and site builders to make use of the components through code or through UI
  • Provide development hooks to allow developers to add additional components to the Component Library
  • Provide a Style Guide menu callback with all components on screen (or divided between major groupings) to allow for easy theming
  • VERY SPECIFICALLY do not include any default CSS or JS for these components unless absolutely necessary (such as in the case of widgets). When default CSS or JS is needed, make sure it is as minimal as possible and very easy to override/remove, ideally without a process/preprocess function. Think Stark as the default theme for these components, not Bartik.

• #2897055: Decouple Drupal’s Theming Layer into a REST Service
  

  I [cyb.tachyon] suggest we take a look at moving the theme layer into a microservice that takes REST requests and returns schemas and formatted HTML. The goal is effectively abstracting/decoupling layout and theme related elements from content and configuration.

  The proposal is to treat the reusable components as first class objects deliverable by an anonymous service (whether that be Drupal or some other platform is inconsequential). The components would be exposed with all information necessary to solicit the dynamic data necessary for rendering - The implementation would choose how to handle the collection and injection of dynamic data.

Those issues are overlapping in some capacity. Needs and technical implementation concerns should be separated. I propose that the needs be regrouped either here or in one of the existing issues.

Other issues talking about components

Issues below mostly talk about implementation details and not use-cases, or reasons to put components in place.

• #2914759: Proposal to use Lit / web components for building Drupal’s administrative UIs
  Discussion on implementation details for dblog UI with Polymer
• #2916453: Decide on committing to and adopting W3C Web Components standards
  Proposal for a policy decision about the implementation detail of components in Drupal
• #2809255: Create a polymer SDK for Drupal
  Exploration of implementation detail of components
• #2821399: [meta] Theme System Modernization Initiative
  todo list for making the theme system more modern/in line with more current practices