Background

At DrupalCon Global 2020, Dries proposed a new initiative for creating a decoupled menu component written in JavaScript. For Drupal to remain framework agnostic, he proposed to start with building components for Vue.js and React.js.

Idea

Motivation

Popularity of JavaScript has skyrocketed. At the moment, Drupal has a limited offering for catering to that market. Many Drupal developers are building “decoupled" sites, using Drupal for their back end and JS frameworks for their front end. Doing so forces those developers to abandon or recreate many of the features that Drupal provides out-of-the-box. This makes Drupal less attractive to:

  • JavaScript developers since there is less to benefit from by using Drupal.
  • Drupal evaluators* who:
    • would like to use Drupal for its content management features, but would prefer their site to have the more "application-like" experience enabled by modern JavaScript frameworks.
    • would like to be able to hire developers familiar with HTML, CSS and JS, but not necessarily familiar with Drupal.

* A "Drupal evaluator" is anyone deciding to build a website and is considering whether they should use Drupal to do so. This may be a single developer who is "hiring" themselves or an individual within an organization who needs to hire a developer(s)/agency.

Problems we are trying to solve

  • Drupal doesn’t have a process for building, shipping or maintaining modern JavaScript libraries.
  • Drupal does not have much appeal to JavaScript developers because it doesn't solve many of the problems that they encounter.
  • Content editors working on a site using a JavaScript front end have less control over the content and structure of their site.

We can observe an example of a how a decoupled site provides limited control to content editors by looking at menus...

Since Drupal's HTTP APIs have no support for exposing menu links, front-end developers are often forced to to "hard code" their site's navigation. This design means that the content editors working with Drupal can't add, remove, reorder or rename custom menu items. Additionally, PHP code is unable to provide menu items to the front end.

Who is this for?

  • JavaScript framework developers who would like to use Drupal as a back end while also providing user-editable menus.
  • Drupal evaluators who would like to have all of Drupal's CMS features and more choices for their front end

Stakeholders

  • Content editors who would like to continue using Drupal's menu management UI whether their site is decoupled or not (improving this UI is out of scope)

Proposed resolution

We believe that we can address all of the problems outlined above by:

  • Adding read-only menu items to Drupal's HTTP APIs (e.g. the JSON:API module)
  • Making it easy for a front-end developer to consume that menu data in order to render a navigation instead of hardcoding it by:
    • Writing documentation for how to integrate a React or Vue application with Drupal to render a dynamic menu.
    • Removing as many steps as possible and eliminating the most tedious steps by providing JavaScript tools and/or libraries for consuming the HTTP API described above. By providing these tools/libraries, we will document and formalize policies and processes for building modern JavaScript (e.g. establish conventions, workflows), shipping (e.g. use NPM to distribute standalone libraries), and maintaining JavaScript libraries (e.g. who is allowed to publish NPM packages using the Drupal name?)

Not in scope

  • Frontend components with markup and styles
  • Changes to admin UI/editing interface

Process and where to find it

Slack channel: #decoupled-menus-initiative (learn how to join Drupal Slack)

Proposal roadmap

A roadmap is under construction here: https://docs.google.com/document/d/1GPPALh7sQhRkV9dgm8qMde9RmwjYTteP_AE4...

We will copy it to this section soon.

See decoupled menu initiative project.

Contributed projects

None at this time.

Team and resources

Coordinators

  • Théodore Biadala (nod_)
  • Gabe Sullice (gabesullice)

Appointees

  • Onboarding & communications lead: Baddy Sonja Breidert (baddysonja)
  • Meetings and issues secretary: Liam Hockley (lhockley)
  • Weekly meeting lead (Asia & Australia timezone): Ashutosh Gupta (ashu1629)

Active contributors

  • Lauri Eskola (lauriii)
  • Lee Rowlands (larowlan)
  • Mateu Aguiló Bosch (e0ipso)
  • Roy Scholten (yoroy)
  • Sally Young (justafish)
  • Sharique Farooqui (Sharique)

You? Join us in #decoupled-menus-initiative!

Signoffs

Signoffs needed

  • Product manager
  • Release manager
  • Framework manager

Signoffs given

  • BDFL
CommentFileSizeAuthor
#32 3170260-decoupled-menus-32.patch652 bytestim.plunkett
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

lauriii created an issue. See original summary.

ashu1629’s picture

Issue summary: View changes
gabesullice’s picture

Welcome Ashutosh and Sharique! Glad to have you on board :)

baddysonja’s picture

Linking here the JS Menu Component Initiative Questions document: https://bit.ly/367CKdd

I have a question: should
"Content authors: able to work in/with user friendly menu creation/management tools despite the menu implementation being decoupled"
be removed from the scope of the initiative?

gabesullice’s picture

I have a question: should
"Content authors: able to work in/with user friendly menu creation/management tools despite the menu implementation being decoupled"
be removed from the scope of the initiative?

@baddysonja, do you think it should be? If so, why?

I don't believe it should be. I think it's important that we keep content editors in mind. Even if we don't have much work to do to support them, I suspect that it will guide some of our implementation decisions.

baddysonja’s picture

Maybe I'm misunderstanding our mission, but according to the slides at DrupalCon Global Dries said:
Mission: Provide the best way for JavaScript front ends to consume configurable menus managed in Drupal.

Success is:

  • We have an official React component for menus
  • We have an official Vue component for menus
  • The developer experience is better than Contentful's
  • We maintain the current Twit templates for traditional sites

See here: https://dri.es/state-of-drupal-presentation-july-2020

The content of menus comes from Drupal and therefore I don't see this as one of the tasks of this initiatives to optimise the menu creation/management tooling for content editors.

gabesullice’s picture

I think we agree @baddysonja :) That statement is there only to keep us accountable. It's out of scope to improve menu management, but I think it should be in our mandate not to degrade menu management even if the menu is will be rendered by a JS application instead of Drupal. Maybe we can word it better? Or maybe it's self-evident and it doesn't need to be said at all?

Edit: s/link/statement

webchick’s picture

I like calling it out explicitly, personally. Helps keep the end goal (the user journey enumerated in the Driesnote) at the forefront, and grounds the technical innovation in practical, real-world situations.

lhockley’s picture

I agree that we ought to not forget about content authors, and they should be mentioned even if it is not a primary objective. Not because that is part of the scope, but because it's an affected party we should consider in decision making.

Do we, perhaps, want to use a weaker heading such as "Affected Stakeholders"? Is stating that this initiative is for content authors a bit on the strong side?

gabesullice’s picture

Issue summary: View changes

I like that! Is this better?

fgm’s picture

AIUI the ones using the menu management UI are not usually just content authors: those tend to just use the menus, not manage them ? Maybe something needs to be clarified here.

gabesullice’s picture

Issue summary: View changes

How about "end users" vs. "content authors"?

larowlan’s picture

Status: Active » Reviewed & tested by the community

🚢Let's do this

baddysonja’s picture

Much better. Happy with the description now and very excited to see this work start.
Thank you gabesullice

justafish’s picture

+1

yoroy’s picture

Status: Reviewed & tested by the community » Needs work

It's always tough to balance "here's what we're going to do" with "we can't know yet", but I think this *idea* could to be a bit more specific about *how* it wants to evolve towards a *plan*:

## Motivation section

I would personally love it if we could avoid the 'end-user' word, it doesn't say anything about what such a person is supposedly allowed to do. In this case, is this about people that can add, remove, edit menus, menu items from the (JavaScript) front end?

## Problems section

"Drupal doesn’t have a preferred, documented process for building, shipping or maintaining modern JavaScript libraries."

Does the proposed resolution account for all of 'building, shipping or(?) maintaining' as mentioned in the 'problems to solve' section? To what extent are these separate concerns? If separate, what are the main challenges for each of building, shipping, maintaining?

A bit of an overview of what is in this 'full range of content authoring tools' leaves a lot of room for assumptions. It would help to make those explicit in the process and or roadmap section.

## Roadmap section

There's nothing in the "Proposal roadmap" section right now :) Some indication of roposed steps and their sequence would be useful, for example:

Once this idea is approved the team will create a more detailed plan for the following:

Building
- identify and confirm the main challenges (through interviews with js devs?)
- establish (agree on) what the recommend approach should be
- agree on initial scope of what can be done to improve things on the Drupal side
- write documentation
- write any necessary code that simplifies the recommended approach

Shipping and maintenance
- to be decided, because depends on the approach chosen and any docs, tooling, code produced to support it.

A more general suggestion: I imagine that there will be a gray area of responsibility in the back and forth between the JS front and Drupal back. Some architecture principles or heuristics to help navigate that could be useful to have. This is not something that can be established up front, but such heuristics could help navigate the many decisions that need to be made.

gabesullice’s picture

Issue summary: View changes

Thanks for the review @yoroy, that's very helpful!

I've integrated a lot of your feedback in these changes, but I did not have time to address most of your remarks on the Roadmap section.

We will continue to work on that section before setting this back to Needs review.

gabesullice’s picture

Issue summary: View changes
yoroy’s picture

Actually, it's fine to do the actual roadmap work in the planning phase. I'm happy with that doc just being linked here for now. Plan is roadmap is plan. If you could open a new issue for the actual planning work and at that to the roadmap section then I think we're good for this phase.

gabesullice’s picture

Issue summary: View changes

Fixing some grammar and spelling mistakes.

gabesullice’s picture

Planning issue created! Obviously we can re-title or reword that issue as necessary. I wasn't sure what the appropriate format should be.

yoroy’s picture

Status: Needs review » Reviewed & tested by the community

Thanks! And that's a great descriptive title for the planning issue :)

baddysonja’s picture

Issue summary: View changes
lauriii’s picture

Title: JavaScript menu component initiative » Decoupled Menus Initiative
Issue summary: View changes

Changed the initiative name to Decoupled Menus Initiative based on discussions in Slack. I also added new section for work that is out of scope for this initiative.

gabesullice’s picture

Issue summary: View changes

Changed Slack channel name to reflect new initiative name.

gabesullice’s picture

Issue summary: View changes

Forgot one reference.

baddysonja’s picture

Like discussed in our weekly Slack, gabesullice and nod_ should be listed as our official initiative coordinators.

e0ipso’s picture

Issue summary: View changes

Fixed Slack link :-)

gabesullice’s picture

Issue summary: View changes

Updated team & resources

e0ipso’s picture

Issue summary: View changes

+1 from me!


Also, adding myself tentatively in the contributors section given that I'm taking part of the ongoing discussions anyways 😛.

xjm’s picture

Status: Reviewed & tested by the community » Needs work
Issue tags: +Project governance

This initiative is definitely already happening. :) Love the progress already.

Can we add a patch for MAINTAINERS.txt adding the initiative with the proposed initiative coordinators? Then once we have that, we will need the coordinators to confirm they agree with being added and with the roles as described in https://www.drupal.org/contribute/core/maintainers#initiative, and finally have Dries sign off on it.

Finally, https://www.drupal.org/about/strategic-initiatives/javascript-menu is 404 and we should fix that. ;)

tim.plunkett’s picture

Status: Needs work » Needs review
FileSize
652 bytes

Adding coordinators from the IS

Dries’s picture

Approved! Thank you all.

gabesullice’s picture

Issue summary: View changes

we will need the coordinators to confirm they agree with being added and with the roles as described in https://www.drupal.org/contribute/core/maintainers#initiative

Confirmed.

P.S. Fixed some broken links in the IS

nod_’s picture

Confirmed on my end too :)

ashu1629’s picture

Confirmed on my end :)

tim.plunkett’s picture

Issue summary: View changes
Status: Needs review » Reviewed & tested by the community

Fixing the ” vs " in the IS.

https://www.drupal.org/about/core/strategic-initiatives still lists "Javascript Menu Component" instead of "Decoupled Menus"

tim.plunkett’s picture

baddysonja’s picture

Thank you @tim.plunkett. I will work on https://www.drupal.org/about/strategic-initiatives/decoupled-menus during DrupalCon Europe.

Gábor Hojtsy’s picture

Status: Reviewed & tested by the community » Fixed

Thanks all! Committed 0301f10 and pushed to 9.2.x.

Gábor Hojtsy’s picture

Note that I left this in the ideas queue. Normally we have a separate maintainer addition issue, but this is how it went down here :)

Gábor Hojtsy’s picture

Verified that both initiative leads are already maintainers in https://www.drupal.org/node/3060/maintainers due to other roles they have, so no change required there.

gabesullice’s picture

Granting credit for everyone's help! Please let me know if I've forgotten anyone.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

pdureau’s picture

JS frameworks force those developers to abandon or recreate many of the features that Drupal provides out-of-the-box.

would like to use Drupal for its content management features,

IMHO, that's the most important part, to keep the site building abilities from the backoffice while using a JS framework on front-end.

Adding read-only menu items to Drupal's HTTP APIs (e.g. the JSON:API module)

To achieve that we need to expose to front not the menu & menu items entities, but the menu & menu items render array. For example, as JSON serialization of those arrays. And the JS framework need to map each render element to one or many of its components.

Because render arrays are build very late in the Drupal cycle, we benefit from all Drupal features executed server side.

However, Render API is not in a good shape today, and we will need to clean it deeply to expose something tidy and efficient to front-end. There is a core issue about that: https://www.drupal.org/project/ideas/issues/2702061

nod_’s picture

Issue summary: View changes