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
Comment | File | Size | Author |
---|---|---|---|
#32 | 3170260-decoupled-menus-32.patch | 652 bytes | tim.plunkett |
Comments
Comment #2
ashu1629 CreditAttribution: ashu1629 at Acquia commentedComment #3
gabesulliceWelcome Ashutosh and Sharique! Glad to have you on board :)
Comment #4
baddysonjaLinking 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?
Comment #5
gabesullice@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.
Comment #6
baddysonjaMaybe 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:
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.
Comment #7
gabesulliceI 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
Comment #8
webchickI 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.
Comment #9
lhockleyI 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?
Comment #10
gabesulliceI like that! Is this better?
Comment #11
fgmAIUI 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.
Comment #12
gabesulliceHow about "end users" vs. "content authors"?
Comment #13
larowlan🚢Let's do this
Comment #14
baddysonjaMuch better. Happy with the description now and very excited to see this work start.
Thank you gabesullice
Comment #15
justafish+1
Comment #16
yoroy CreditAttribution: yoroy at Roy Scholten commentedIt'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.
Comment #17
gabesulliceThanks 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.
Comment #18
gabesulliceComment #19
yoroy CreditAttribution: yoroy at Roy Scholten commentedActually, 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.
Comment #20
gabesulliceFixing some grammar and spelling mistakes.
Comment #21
gabesullicePlanning issue created! Obviously we can re-title or reword that issue as necessary. I wasn't sure what the appropriate format should be.
Comment #22
yoroy CreditAttribution: yoroy at Roy Scholten commentedThanks! And that's a great descriptive title for the planning issue :)
Comment #23
baddysonjaComment #24
lauriiiChanged 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.
Comment #25
gabesulliceChanged Slack channel name to reflect new initiative name.
Comment #26
gabesulliceForgot one reference.
Comment #27
baddysonjaLike discussed in our weekly Slack, gabesullice and nod_ should be listed as our official initiative coordinators.
Comment #28
e0ipsoFixed Slack link :-)
Comment #29
gabesulliceUpdated team & resources
Comment #30
e0ipso+1 from me!
Also, adding myself tentatively in the contributors section given that I'm taking part of the ongoing discussions anyways 😛.
Comment #31
xjmThis 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. ;)
Comment #32
tim.plunkettAdding coordinators from the IS
Comment #33
Dries CreditAttribution: Dries commentedApproved! Thank you all.
Comment #34
gabesulliceConfirmed.
P.S. Fixed some broken links in the IS
Comment #35
nod_Confirmed on my end too :)
Comment #36
ashu1629 CreditAttribution: ashu1629 at Acquia commentedConfirmed on my end :)
Comment #37
tim.plunkettFixing the ” vs " in the IS.
https://www.drupal.org/about/core/strategic-initiatives still lists "Javascript Menu Component" instead of "Decoupled Menus"
Comment #38
tim.plunkettI fixed https://www.drupal.org/about/core/strategic-initiatives#decoupled-menus
Comment #39
baddysonjaThank you @tim.plunkett. I will work on https://www.drupal.org/about/strategic-initiatives/decoupled-menus during DrupalCon Europe.
Comment #40
Gábor HojtsyThanks all! Committed 0301f10 and pushed to 9.2.x.
Comment #41
Gábor HojtsyNote that I left this in the ideas queue. Normally we have a separate maintainer addition issue, but this is how it went down here :)
Comment #42
Gábor HojtsyVerified 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.
Comment #43
gabesulliceGranting credit for everyone's help! Please let me know if I've forgotten anyone.
Comment #45
pdureau CreditAttribution: pdureau as a volunteer commentedIMHO, that's the most important part, to keep the site building abilities from the backoffice while using a JS framework on front-end.
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
Comment #46
nod_