Reconsider XB entity path strategy for consistency and felxibility

Lol. "felxibility" 😅

How does this scale once we want to enable opening something other than a Node in the Experience Builder? Like let's imagine, XB supports editing a View, and you now want to navigate to XB to edit a specific View. What would the URL be in that case?

I think that's intrinsic to the scope of this issue. Nodes are the presenting question (and the answer seems obvious to me). I assume most other entity types already have their own conventions--Views, blocks, media, etc. Maybe we should break this issue up a little bit: 1) keep this one but scope it at Nodes only, 2) create one for deciding on other entity types when we're getting ready to implement them, and 3) expose the ability the define the behavior in the API. What do you think?

This might not be how Experience Builder works today, but eventually Experience Builder should be able to open any Drupal URL regardless of how it's defined. Experience Builder would allow users to navigate outside of XB for concepts that are not editable by XB (similar to contextual links).

This is described in the requirement 11. Component hover:

As a builder or creator, I expect to be able to inspect any visual element on the page by hovering/clicking on it. This will either let me edit it (if editable), and/or tell me what rendered it and tell me how to edit it. For example, an instance of component would be editable within the current page, but would also provide builders with guidance to how to edit the structure of the component.

AFAIK @lauriii and @traviscarden discussed this in a meeting, to clarify #6. Can we please get this issue summary updated to capture that, @traviscarden?

That being said: I think adding experience_builder.links.task.yml akin to node.links.task.yml is a fine interim step. Because what is described in the first paragraph of #6 is a very long way off, with no designs for it yet whatsoever, nor is it part of the 🌱 Milestone 0.2.0: Experience Builder-rendered nodes Active scope, because that first paragraph describes product requirement 18. Navigate between layers — which is not targeted for 0.2.0.

Adding these links takes mere minutes and will make XB easier to discover. Retitling per my understanding above. Feel free to course correct 😊

Thanks, @wim leers. I agree with your assessment. I think the original impetus of this issue was based on a misunderstanding, and the value to be derived now is just findability in the short term. I've updated the summary accordingly.

Also, like you, I assumed that adding the local task would be a matter of minutes, but I must be missing something. I can get a local task to appear if I hard-code the node ID, but I can't get it dynamically. Anything I try results in either a fatal error or just not showing the task. I'll create an MR with the hard-coded nid. I need someone to help me figure out the last part.

Ah, I bet this is related to the difference in route parameters: everything in node.links.task.yml uses the same route parameters (i.e. the same names such as {{node}}) in the route definitions.

But Experience Builder is generic!

We may want/need to add a separate (temporary) route definition just for nodes to make this work for now. But before doing that, we should step through how node task links are constructed using xdebug.

I'd say: spend a time-boxed amount of time on it, e.g. 30 mins, and if you can't figure it out in that time, assign it to @longwave — chances are he's debugged this area previously 😄