- Issue created by @camilo.escobar
- 🇺🇸United States kevinquillen
+1 to this, would you be willing to share the code in a fork?
I'd like to initiate a discussion to gather opinions on the utility and feasibility of introducing a new feature, potentially controlled by a new configuration option or as a submodule. This feature would provide a new resource capable of returning a response with nested menu items that match the tree hierarchy from Drupal.
Let's consider a scenario with four links: A, B, C, and D. In this case, A is a first-level element and the parent of B; B is the parent of C; and D is another first-level element, a sibling of A, without children.
Currently, the JSON:API resource provided by the module returns a flattened representation of the menu tree. The response might look like this:
"data": [
{
"type": "menu_link_content--menu_id",
"id": "menu_link_content:A",
"attributes": {
"menu_name": "main",
"title": "A",
"url": "/node/1",
"parent": ""
}
},
{
"type": "menu_link_content--menu_id",
"id": "menu_link_content:B",
"attributes": {
"menu_name": "main",
"title": "B",
"url": "/node/2",
"parent": "menu_link_content:A"
}
},
{
"type": "menu_link_content--menu_id",
"id": "menu_link_content:C",
"attributes": {
"menu_name": "main",
"title": "C",
"url": "/node/3",
"parent": "menu_link_content:B"
}
},
{
"type": "menu_link_content--menu_id",
"id": "menu_link_content:D",
"attributes": {
"menu_name": "main",
"title": "D",
"url": "/node/4",
"parent": ""
}
}
]
This approach is great and very aligned with JSON:API; however, it places the burden of sorting out the menu hierarchy and constructing the tree on the consumers or frontend applications. To streamline this process, we could consider the introduction of a new route and a new resource that returns a nested tree structure directly from Drupal, instead of a flattened array, simplifying menu building for external applications by eliminating the need to handle hierarchy on the client side. Here's an example of how the new resource could look:
"data": [
{
"type": "menu_link_content--menu_id",
"id": "menu_link_content:A",
"attributes": {
"menu_name": "main",
"title": "A",
"url": "/node/1",
"parent": "",
"children": [
{
"type": "menu_link_content--menu_id",
"id": "menu_link_content:B",
"attributes": {
"menu_name": "main",
"title": "B",
"url": "/node/2",
"parent": "menu_link_content:A",
"children": [
{
"type": "menu_link_content--menu_id",
"id": "menu_link_content:C",
"attributes": {
"menu_name": "main",
"title": "C",
"url": "/node/3",
"parent": "menu_link_content:B"
}
}
]
}
}
]
}
},
{
"type": "menu_link_content--menu_id",
"id": "menu_link_content:D",
"attributes": {
"menu_name": "main",
"title": "D",
"url": "/node/4",
"parent": ""
}
}
]
In this structure, child menu items are nested within each parent menu item under the children attribute.
There was a real use case in one of my projects where I already implemented this feature, and it was highly appreciated by frontend developers. That's why instead of maintaining that separate module for this functionality, I'm proposing to incorporate it within this module. Since this module is actively maintained, I believe incorporating this new feature into it is the right approach, rather than maintaining a separate forked module. Integrating the feature here offers several advantages. For example, the new "nested items" resource will seamlessly integrate with existing functionality, leveraging what has already been built. For example, it could benefit from aspects such as compatibility with the Menu Item Extras module ✨ Add support for the Menu Item Extras module Needs review , which was recently added in version 1.2.5 → .
Of course, the proposal aims to introduce a new resource, either as a manageable setting through the user interface or as a sub-module. To be clear, this is not about replacing the current and very useful resource, which will remain intact.
Use this issue to discuss the approach.
I'd like to gather opinions on this proposal, particularly regarding its feasibility and usefulness. Would incorporating this feature into the module be beneficial for others? Are there any potential challenges or concerns with this approach? Your feedback will help determine the best path forward.
If the proposal is accepted, I will provide the merge request and nominate myself as a co-maintainer of the module.
Active
1.2
Code
+1 to this, would you be willing to share the code in a fork?