Idea summary

What is the problem to solve?

Component-based design/implementation is an evolving-best practice for front-end development, whereby individual components are created one-by-one (header, footer, card display mode, accordion, etc) and packaged with all their frontend assets in one place (twig template, (s)css, js). See Driesnote from DrupalCon Dublin (I think, it was Dublin).

At the moment, if a developer creates these components as standalone items (using PatternLab, Fractal, or some other system), there is no way for Drupal to have knowledge of them. This means (at a minimum) the twig files need to be duplicated into the Drupal /templates folder of the current theme, leading to duplication of code, and some sort of gulp task or otherwise getting the CSS and JS assets to the Drupal theme and other extra maintenance. It means that it is much more difficult to maintain living styleguides created by PatternLab or KSS or a custom system.

With the advent of the 'Out of the Box' initiative, there is going to be a new theme in Drupal core. The developers of this theme (I am one of these) will be builing this with best-practice in mind and are aiming to build a styleguide into the theme, using component-based design principles. Having a way to reference components would make this much easier for us (and any developer in the future who wishes to use component-based design in their custom or contrib themes, opening up many new avenues to Drupal front-end development). It would also mean that contrib themes would not need to depend on a contrib module.

It might also help Unify & simplify render & theme system: component-based rendering (enables pattern library, style guides, interface previews, client-side re-rendering).

Though quite a small module (it does one thing, and does it well!), it would open up/encourage a lot of new frontend possibilities.

Who is this for?

This is a utility tool for front-end developers.

Result: what will be the outcome?

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.

How can we know the desired result is achieved?

As long as we can reference templates outside of the theme's /templates folder we know the result has been achieved.

CommentFileSizeAuthor
#18 add-components-module-to-core-2875935-17.patch5.47 KBmarkconroy
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

markconroy created an issue. See original summary.

markconroy’s picture

markconroy CreditAttribution: markconroy at Annertech commented
Title: Proposal: Add this module to Drupal Core » Proposal: Add this Components Module to Drupal Core
lauriii’s picture

lauriii
he/him
Primary language Finnish
Location Finland
CreditAttribution: lauriii as a volunteer and at Druid commented
Title: Proposal: Add this Components Module to Drupal Core » Add Compoenents Module to Drupal Core
Project: Components! » Drupal core ideas
Version: 8.x-1.0 »
Component: Code » Idea
Category: Plan » Task

Moving to Drupal core ideas

markconroy’s picture

markconroy CreditAttribution: markconroy at Annertech commented

Thanks @laurii

markconroy’s picture

markconroy CreditAttribution: markconroy at Annertech commented
Title: Add Compoenents Module to Drupal Core » Add Components Module to Drupal Core
yoroy’s picture

yoroy CreditAttribution: yoroy at Roy Scholten commented
Issue summary: View changes

This looks interesting! Adding the idea proposal questions to the issue summary to help clarify why what & how. Thank you.

markconroy’s picture

markconroy CreditAttribution: markconroy as a volunteer and at Annertech commented
Issue summary: View changes
dasjo’s picture

dasjo
he/him
Primary language German
Location Zurich
CreditAttribution: dasjo commented

Is this idea specifically about https://www.drupal.org/project/components ?

markconroy’s picture

markconroy CreditAttribution: markconroy as a volunteer and at Annertech commented

Hi dasjo,

Not necessarily. It stemmed from an issue I created in the components module issue queue but was then moved to here.

I guess it's basically about being able to reference templates outside of the /templates folder so any theme (core/contrib) can use a components-based approach without having to rely on a contrib module.

andypost’s picture

andypost
he/him
Primary language Russian
CreditAttribution: andypost as a volunteer and at Skilld commented

It may help layouts initiative to provide layouts without having theme hooks
Same time there's also a question of integration with kss & styleguide module

btw Usage shows that components module used on 2,5% of d8 sites

evanmwillhite’s picture

evanmwillhite CreditAttribution: evanmwillhite commented

I would like to see this module integrated as well - it's a great way for Drupal to support Twig templates from directories other than /templates in a controlled way.

willthemoor’s picture

willthemoor CreditAttribution: willthemoor as a volunteer commented

Yes yes please. As per the original summary, this is very much in line with current front-end best practices.

The goal for us is to create the components and views (twig templates and associated assets), store them in one spot and be able to generate stand alone views (for QA reference and client approval), a living style guide, Drupal templates and static components/templates for consumption by organizationally branded non-Drupal projects.

Iggy_Lakic’s picture

Iggy_Lakic CreditAttribution: Iggy_Lakic commented

I would like to see this module integrated in the core. That would be a significant D8 improvement and it is very important that such functionality is available out-of-the-box so front-end devs can easier deliver with the best current front-end practises available.

cyb_tachyon’s picture

cyb_tachyon CreditAttribution: cyb_tachyon as a volunteer and at Red Hat commented

What are our blockers to making this happen?

I don't see anything off-hand in the components module as it currently is that blocks adding the components module to core, and I agree with the points made here.

Are we good to move this to Proposed Plan, add an initial patch to this issue, and get it to Approved Plan, or does this still require ongoing discussion?

PS: IMO It is still difficult, even with the components module, to map Drupal fields to twig variables. However, this is outside the current scope of what the Components module does currently and we should probably keep discussion for it within the contrib module for now to avoid bikeshedding.

yoroy’s picture

yoroy CreditAttribution: yoroy at Roy Scholten commented

I'm not a subject matter expert in this, but would be good to clarify whether this could be seen as a first step towards the proposed initiative for component based theming. In spirit I guess that's a yes, but for the architecture?

thamas’s picture

thamas
Primary language Hungarian
Location Hungary
CreditAttribution: thamas at Integral Vision Ltd commented

Any chance to get it into 8.4?

yoroy’s picture

yoroy CreditAttribution: yoroy at Roy Scholten commented

There's 10 days left before 8.4 alpha, after which no big changes are allowed :)

markconroy’s picture

markconroy CreditAttribution: markconroy as a volunteer and at Annertech commented
Category: Task » Feature request
Status: Active » Needs review
FileSize
add-components-module-to-core-2875935-17.patch5.47 KB

Adding patch that adds components 8.x-1.0 to core, so we might have it in 8.4 and available to the developers of the new theme for Drupal Core.

Removed 'Information added by drupal packaging script'
Removed licence.txt (presumably it'll be covered by the Drupal GPL licence)
Fixed some (tiny) coding standards

Todo
- convert arrays to use short syntax
- test

lauriii’s picture

lauriii
he/him
Primary language Finnish
Location Finland
CreditAttribution: lauriii as a volunteer commented
Status: Needs review » Active

I do see that we have to further evolve the theming experience of Drupal. I'm not sure I quite understand how moving the components module would benefit that, so could we list the main reasons why we should add the module into core?

At this point, I see it as a benefit for this module to live in the contrib space since it allows it to evolve faster. The biggest benefit would be the fact that core themes could leverage the module, and that it would get greater exposure.

If we still think we want to work on this, here are some things for consideration:

One of my biggest concerns about the current stage is that we haven't decided yet how this feature would be integrated with modules. Are there any examples of that?

Another concern I have is that there are few remaining issues in Drupal core which would have to be solved to be able to leverage the power of this module in core. These should most likely be included in the scope of the initiative proposal. List of the issues found so far but there might be more.

Given the current stage of the release cycle for 8.4, I see it unlikely that release managers would support adding this feature to 8.4. I suggest that if we decide to work on this, we target for another future release.

evanmwillhite’s picture

evanmwillhite CreditAttribution: evanmwillhite at Four Kitchens commented

I think that this module or an approach like it is necessary to Drupal's future. With so much attention given to component-based design, the model of keeping all markup/Twig in a Drupal-specific directory (/templates) is already antiquated. Also, from what I can tell, there are no blockers in the issue queue you referred to for adding this module. And if there was an initiative to move any core modules/themes to a component-based approach, that would be great, but it could come later too. Basically, the benefits of adding this to core are simple and two-fold:

  1. Ability to store markup in any directory for any organizational methodology, including component-based
  2. Ability to namespace these directories for easy usage within other Twig templates

I do understand the release cycle focus, but I just wanted to put my two cents in here for this or something like it being in core sometime soon. Thanks!

nod_’s picture

nod_
Primary language French
Location Lille
CreditAttribution: nod_ at Acquia commented
Status: Active » Postponed

Postponing to simplify triage of the ideas queue on the component topic.

It would be helpful to highlight the needs addressed by this idea in the issue summary and add it to #3240805: [meta] Organize components-related ideas as well, to help consolidate all the different related issues.