#Needs design

Hey @plopesc.

I was investigating how the contextual module adds the Edit button and the contextual link on the pages.
The Edit is added by the hook toolbar(ContextualHooks:19), by default this link is hidden, and then a javascript is responsible for showing or keeping it hidden. If I'm not wrong, the behavior checks if there is any contextual link on the page, and if the Edit is toggle to visible, otherwise keeps hidden. The contextual_preprocess function adds the contextual links if I'm not wrong.
Please, anyone, correct me if my understanding is wrong.

Based on that, for the entities we already have a solution, since the user is accessing an entity page the local tasks will appear and we add the Preview editable areas. Since this is a temporary solution, I don't think it's feasible to implement a "complexity" custom logic just to make this work for other pages. We probably need a javascript code to check if there are contextual links on the page and then control the top bar items. We probably will add a custom logic just for a temporary solution.

So, here is my suggestion. Based on the "complexity" that can be to adding the Preview editable area for non-entities pages, and this is a temporary solution. I would like to suggest that we could move forward with the current solution, displaying the feature only for entity pages.

What do you guys think?

I took a stab at writing a more descriptive title based on where the conversation went.

Also, I thought it might be helpful to be aware that the designs for code components ( 🌱 [Meta] Plan for code components Active ) introduce the term, group. See ✨ Component groups for code components Postponed . Those are what we previously named category in 📌 Define built-in components and categorization for components Postponed . We may want to resolve that mismatch first before we choose the property name here. I would vote for renaming groups to categories in the code components world.

> Claro prepends the "Edit" words into the title itself, in italics:

Technically, Drupal/the node module does that. If Gin is different then it explicitly overrides and customizes that. So we'll need to figure out who does what. navigation will eventually become the default/only/recommended solution in core but it won't be mandatory, so it might fall to that module to adjust things to fit with information in the top bar, but that's something to figure out once the design/goal is clear.

Adding latest designs for the Top Bar as a reference.

Adding some screenshots to make it easier for designers to understand the needs and current situation.

Some nitpicks but the proposal looks good to me in principle.

Proposed a change to the API spec for the components controller that should power this.

If we agree with this approach we can move to implementation

@effulgentsia asked me if I have thoughts on how to split up the server-side vs client-side responsibilities here and design the API between them.

I think this is where having an OpenAPI spec comes in handy. We can use that as the discussion point. I'll open an MR with some changes to demonstrate what @longwave is articulating in #4

This means that even if the library and top bar have groupings (like the Sections/Components split we have at the moment), the number/names of those groups should be sent from the server.

Agree 💯, this is the same sort of thing I was trying to say in 📌 Implement saving block settings forms Active but I think you've said it better with

we should be flexible in allowing developers to customise the XB UI from PHP wherever possible

- 🙌

Hi, thank you for your interest on this one.

Given that this solution will be probably temporary, we could just provide this feature as part of the existing TopBarItem plugin.
You can just add an extra item to the Local Tasks list calculated using the logic you need, I guess it could be inspired in how contextual's hook_toolbar() works.

If there are no local tasks, you'll have only this new option will be displayed.

Thank you!

Hey @plopesc, thanks for the review.
I'm having a look at the way that the Edit button appears. In the contextual module, they implement the hook toolbar. For the navigation we don't show that toolbar as the other modules do, so the only way that we currently display something similar to the toolbar hook is the top bar item, am I correct? please correct me if I'm wrong.
Since the PageActions plugin displays the Local tasks, how can we implement the edit button without using the local tasks? Should we create another plugin, for example: ToolbarActions, then we could add actions that are similar to the toolbar hook.
Thanks.