By mid-November 2022, TheDropTimes (TDT) had done a series of interviews with the speakers for NEDCamp, and Brian Perry's was one among those. He is the maintainer of Decoupled Menus Initiative of Drupal and a Senior Technology Consultant/Staff Engineer with Pantheon. Hardly a couple of months have passed since our last interview with Brian, but here we are at it again as the news broke about a new feature as part of the Decoupled Menus initiative that has been committed to Drupal core!

A new menu linkset endpoint will be included in the Drupal 10.1 release, currently targeted for June 2023. The Decoupled Menu Parser package will also be released on NPM^*[1], which provides utilities that simplify the process of consuming data from this endpoint. 

“Decoupled Menus provides the best way for JavaScript front ends to consume configurable menus managed in Drupal. This makes it easy for a front-end developer to consume that menu data to render navigation instead of hard-coding it,”

says initiative coordinator Brian Perry.

“This also means non-developers can manage application menus without writing code.”

[The team later published @drupal/decoupled-menu-parser and @drupal/linkset packages under the Drupal namespace on npm. Brian had put out a message thanking Sally Young and Neil Drumm for helping debug CI issues related to this in the Drupal Slack channel for #decoupled-menus-initiative. By that time, the interview was over.]

In this context, our editor-in-chief, Sebin A. Jacob, contacted Brian, and although there was a dearth of time, he agreed to reply to our queries. Read on the interview to know more:

TDT [1]: Can you provide a brief overview of your background in the Drupal community and your current role at Pantheon?

Brian Perry: I’ve been part of the Drupal community for over 10 years, primarily focused on the front end. For many years in the freelance and agency space, and most recently as a Staff Engineer at Pantheon, where I have been leading a team working on starter projects and open source tools for building decoupled sites.

TDT [2]: What inspired you to lead the Decoupled Menus initiative in Drupal?

Brian Perry: I was asked to take on the role of an initiative coordinator midway through the initiative when another team member moved on to other projects. I had been involved with the initiative as a contributor prior to that—I had worked on a number of decoupled Drupal projects, so staying up to date with efforts to improve Drupal’s interaction with JavaScript front-ends was of particular interest to me. I was also interested in learning about native web components, which happened to complement some of the efforts in this initiative nicely.

TDT [3]: Can you explain the concept of decoupled menus and how they differ from traditional menus in Drupal?

Brian Perry: In some ways, the menus don’t differ at all. The menu data used by the decoupled menus endpoint is the same data that is used by ‘traditional’ Drupal menus, just exposed in a way that can be used in a different context, like a JavaScript application. Much of the focus of this initiative was addressing limitations related to sourcing menu data from Drupal core and providing tools to help make better use of this data outside of Drupal.

TDT [4]: How does the Decoupled Menus feature support the development of “headless” or decoupled Drupal sites?

Brian Perry: The vast majority of sites need a menu of some kind, which is one of the reasons that this area of Drupal was focused on in the first place. In addition to the general need for menus, the data provided by the menu endpoint specifically focuses on representing the hierarchical nature of Drupal menus, which is often challenging to represent in a headless context. The initiative has also created a decoupled-menu-parser package that will be published under the Drupal namespace on NPM, which makes it easier to parse the endpoint response into a hierarchy that more accurately represents a menu.

TDT [5]: Can you provide examples of real-world use cases where decoupled menus might be handy?

Brian Perry: Since menu data is a specialized use case, it was not uncommon for menus to be somewhat hardcoded in decoupled builds. This meant that changes to the menu would require a front-end code deployment. Using this endpoint, content editors can customize menus using the Drupal admin and see the results reflected on their front-end site. Drupal’s menu-related strengths can be even more helpful in Decoupled builds where menus have a complicated hierarchy or are closely tied to content that is updated frequently.

TDT [6]: How does the Decoupled Menus feature support the creation of decoupled multi-language sites?

Brian Perry: This menu endpoint respects Drupal’s standard language negotiation, so it is possible to request a menu in any of your site’s configured languages. Translating menus is a challenging use case, so this is an excellent example of how Drupal’s strengths can be translated (pun intended) directly to a consuming application.

TDT [7]: What are the main benefits of using the new Linkset API endpoint for accessing and rendering configurable menus in Drupal-powered decoupled websites, and how does it compare to other data-fetching technologies like JSON:API and GraphQL? How might developers interested in building decoupled websites with Drupal benefit from this new feature?

Brian Perry: The linkset endpoint follows the Linkset spec, which was chosen because it is specifically intended to represent relationships between a set of links. It does provide a JSON response, so sourcing data from it is similar to working with other Drupal endpoints, including JSON:API.

TDT [8]: How does Decoupled Menu Parser package help developers simplify the process of consuming data from the menu linkset endpoint?

Brian Perry: The primary feature of the Decoupled Menu Parser package is a utility that denormalizes the linkset response, providing both the individual elements of the linkset, and a tree representing the entire menu hierarchy. Re-assembling the menu hierarchy was a common task that had to be handled in consuming front-end applications, so having a utility that handles this task will hopefully help save some time for developers depending on this data.

TDT [9]: Can you discuss any challenges you faced while developing and integrating the Decoupled Menus feature into the Drupal core?

Brian Perry: While there were challenges, getting the menu endpoint code merged into Drupal core, I think the more exciting challenge was related to everything outside of the traditional Drupal codebase. The general project type was created to accommodate Drupal-related projects that were not PHP code (like distributions, modules, or themes.) And we’ve also learned some lessons about managing Drupal JavaScript projects that are not dependencies of Drupal Core as we prepare to publish the decoupled-menu-parser package on NPM.

TDT [10]: Can you provide advice or best practices for developers looking to implement decoupled menus on their Drupal sites?

Brian Perry: Beyond some of the things we’ve hopefully helped improve with these upcoming releases, I think the biggest challenge is aligning your Drupal path structure with your front-end application’s path structure. This challenge can extend to all content consumed outside of Drupal but can be especially relevant due to the nature of menus. If you’re not following the routing structure defined by Drupal, there isn’t necessarily a one size fits all solution for this, and you’ll need to account for it on the front end. In some cases, the Decoupled Router module can help on the Drupal side of things.

TDT [11]: How can the Drupal community get involved in testing and providing feedback on the Decoupled Menus feature before it is released in Drupal 10.1?

Brian Perry: You can try out the functionality on the Drupal 10.1.x branch today. While tinkering with it, if you find any issues related to the decoupled-menu-parser package, submit them on the project page. Things are winding down in the #decoupled-menus-initiative channel in Drupal slack, but we’re still monitoring messages there.

TDT [12]: Can you discuss any plans or ideas for future development or expansion of the Decoupled Menus feature in Drupal?

Brian Perry: The initiative outlined two primary use cases, and our upcoming release focuses on the first, which is a representation of menu data that is global. The second use case focuses on menu data that is context-aware and may vary from page to page. It is a valuable use case, but we don’t have concrete plans to address it at the moment. I’d like to see the community focus on some decoupled use cases beyond menus.

TDT [13]: How can developers and non-developers contribute to the Decoupled Menus initiative?

Brian Perry: This phase is coming to a close, but I think one possible offshoot that could significantly impact is the Decoupled Drupal-related documentation. We’ve carved out a home for Decoupled Drupal content in Drupal’s developer documentation, but outside of menus, much of what is there is a placeholder. That could make a big difference in helping people understand how to build sites using this architecture, and both developers and non-developers can contribute.

TDT [14]: Now that the Decoupled Menus feature has been committed to Drupal core, what are the next steps for the initiative? A few years back, Dries mentioned the possibility of a decoupled admin interface for Drupal. Is this something actively being pursued? If so, what is the roadmap for this development? What challenges or considerations are involved in creating a fully decoupled backend for Drupal, and how might this impact how developers work with the platform in the future?

Brian Perry: I know there were efforts to create a decoupled admin interface in the past, but as far as I am aware, those efforts have been set aside for the time being. From my perspective, I’d like to see Drupal continue to expand its presence in the JavaScript community via official packages on NPM. Specifically, I’d like to see Drupal offer an official JavaScript client to interface with JSON:API. There are no formal plans around that as of yet, but there are a number of existing related projects with similar interests. I’m hoping they can come together and expand Drupal’s footprint in the JavaScript community.

______________________________

*[1] NPM stands for Node Package Manager, the default package manager for JavaScript’s runtime Node.js. There are other funny expansions as well for this abbreviation. It has a website to discover packages, set up profiles, and manage different aspects of your npm experience, CLI (command-line interface) that runs from a terminal, a tool for publishing and downloading packages with which most developers interact with npm, and the registry which is an extensive public database of JavaScript software and the meta-information surrounding it. The free npm Registry has become the center of JavaScript code sharing, and with more than one million packages, the largest software registry in the world. Open-source developers from every continent use npm to share and borrow packages, and many organizations also use npm to manage private development.