Implement edit perspectives with tabs when editing

1. +++ b/js/paragraphs.js
   @@ -0,0 +1,16 @@
   +   * For body tag, adds tabs for selecting how the content will be displayed.
   ...
   +      $('.layout-region > ul', context).each(function () {
   
   +++ b/paragraphs.libraries.yml
   @@ -8,6 +8,9 @@ drupal.paragraphs.admin:
   +    js/paragraphs.js: {}
   

   I guess this is limited to Drupal admin UI, thus should be paragraphs.admin.js.

   The selector is not properly limited. It needs to be limited to a paragraphs specific list.

2. +++ b/src/Plugin/Field/FieldWidget/InlineParagraphsWidget.php
   @@ -624,6 +624,17 @@ class InlineParagraphsWidget extends WidgetBase {
   +              'id' => [
   +                'paragraphs-feature-fields'
   
   @@ -773,6 +786,11 @@ class InlineParagraphsWidget extends WidgetBase {
   +      '#markup' => '<ul><li><a href="#paragraphs-subform-fields"> Content</a></li><li><a href="#paragraphs-feature-fields">Feature</a></li></ul>',
   

   Don't use IDs as they would need to be unique per DOM. Use classes.

   Also, i thought this makes the region assignment configurable (title "allow to manage") but instead it just makes the defined regions visible. So is the other patch already defining the regions?

The title "Label" and description "Label for the paragraphs type" is much unfortunate as it doesn't really introduce a real case example. Instead we should implement an example such as a Layout selector, offering a drop down, and then adding a class to the output.

Note that this switcher is supposed to be present only on the top (host entity field) level and affect all children.

We don't want to commit an intermediate version that is overloading the UI. Thus we need to use a nested example as reference.

The issue was not properly linked to the parent META. I created a new issue for feature plugin META.

Discussed with miro to leave out the configuration/UI part from this issue. Lets focus on the edit UI here and open an issue for that, as we think that will end up being complicated.

1. +++ b/src/Plugin/Field/FieldWidget/InlineParagraphsWidget.php
   @@ -594,6 +607,7 @@ class InlineParagraphsWidget extends WidgetBase {
   +      $element['subform']['#attributes']['id'][] = 'paragraphs-subform';
   

   this doesn't work, an id needs to be unique. You need to do this relative from your current position based on button you clicked, go up from there to the parent parent container, then select the subform of it.

2. +++ b/src/Plugin/Field/FieldWidget/InlineParagraphsWidget.php
   @@ -708,9 +722,19 @@ class InlineParagraphsWidget extends WidgetBase {
   +    if ($items->getEntity()->getEntityTypeId() != 'paragraph') {
   +      $tabs = '<ul class="paragraphs-tabs"><li id="content"><a href="#paragraphs-subform">Content</a></li><li id="behavior"><a href="#paragraphs-behavior">Behavior</a></li></ul>';
   +    }
   

   this should probably be template. I also don't think that this is limited to sub-paragraphs only?

   But it should probably be limited to having any plugins enabled, at least for now.

The issue needs an update of title and description due to rescoping and (creation of the) the related / separated issue too.

We discussed the approach of the tabs. The summary and goal description should also contain HOW we want to achieve this.

Do we already have the follow-ups created?

Re-rolled and tried to make the #group work, but it is very tricky, because #group needs the full tree, including the parents, which we do not know yet. Also had to change a few other things, #group needs a container, and we need to change our logic to not overwrite it.

The attached example hardcodes the path for the paragraphs_demo field, but only works for the first item, just to show how it needs to look like.

The JS also doesn't really seem to work, and keep in mind that you need to figure out how to show the things even in nested fields, wich the current approach isn't going to be able to do at all. I also don't think that we should use jquery ui tabs.

I guess we need to move the grouping logic complety to JS and add classes to fields and behavior plugin structures that allow it to dynamically hide/show things, exclude paragraph fields and so on.

Not much point for an interdiff, as many things changed a lot with the reroll anyway.

Hm reuploading to trigger Mr. Testbot.

Patch wasn't applying

Fixed #31, which was missing the JS.
Also renamed js/paragraphs.js to js/paragraphs.admin.js as per Miro's suggestion in #6.

I tested #32 and basically it works.
But there is an issue, that the background image field for example is displayed both in the "content" and the "behavior" perspective when using nested paragraphs. After a discussion with Berdir, we decided to implement it a little differently, cause the approach with the #group property is not working for every case (e.g. fields attached to a paragraph that are not entity reference revision fields).

Promoting, since now that we have behavior plugins it is highly important to get edit perspectives. I am still not sure if we need focus on validation errors. For example, if we add invalid file type in the image field of article content type, it is also not in focus after we press submit.

+++ b/css/paragraphs.widget.css
@@ -108,6 +108,23 @@
+.js .ui-tabs-nav.ui-widget-header {
...
+.js .ui-tabs-nav li {
...
+.js .ui-tabs-nav .ui-state-default {
...
+.js .ui-tabs-nav .ui-state-active {
...
+.js .ui-tabs-panel {

This is not limited to Paragraphs in any kind.
It seems to have a high risk of clashes if we combine Paragraphs with Field Group or something using tabs.

I only see screens above with yellow background...

As this is a UI issue, please provide a final UX screen of the effective proposed state.

Also, the patch doesn't apply currently.

This patch should fix merge conflicts. Did renaming as suggested in #38. Moved ui-tabs-panel to field-multiple-table since it is limited to paragraphs only. Uploading screenshots for both perspectives.
There is a possibility to remove paragraph in both perspectives. However, after removing one paragraph, perspective is changed and locked to content only. This should be fixed. Easiest way to do it is to limit remove button to content perspective only.

I will keep working on this.

The order of Behavior/Content is still wrong, looks very weird to me that Behavior is first but not selected by default.

I don't see what using jquery ui tabs brings us, we're doing the show/hide ourself anyway? Why not just have those two buttons/divs/things and register events on them? I suspect it will just get more in the way once we'll try to implement something that looks remotely like the mockups? I think making the elements smaller and adding an icon would already help a lot, looks quite... clunky to me right now.

And i see the Style plugin settings in the Content tab. So hiding doesn't work?

I'm confused UX wise, why Content is not the first tab... This right-to-left is against our standard UX expetation IMHO.

Adding a patch to update the progress. Resolved many merge conflicts due to Paragraphs recent commits. Removed jQuerry UI tabs, using lightweight solution now. There are still multiple things that need to be investigated and done here.

Working in both normal and nested case. Added CSS classes and changed layout a bit. Currently working on adding JS test.

Forgot the screenshot.

While on it, i really like to have the plugin fields first and then the content field such as the add buttons too.

And i tested a deeply nested paragraphs setup with layout plugin fields on a child.
After reload, the nested plugin fields also / still show on the content tab (for my second paragraph in a child).
It is possible that the filtering is limited to the first child only?

Also the collapse action is broken for me with this patch. It simply reloads without any effect.

UX follow-up: The paragraphs that are filtered (no content field) in behavior tab have no summary. Thus you don't know what a paragraph has inside. The problem here is, if we pre-generate the summary, it will be out of date. And regenerating it again with AJAX is not wanted as it makes it slow...

Fixed and re-rolled patch against latest dev so it cleanly applies again. Reviewing this.

With this patch applied, this setup based on paragraphs collection demo was broken:
- setting the paragraph fields to closed mode (content type, paragraph type container)
- editing the front page
- click edit on first container
- click edit - the paragraph doesn't expand

Patch re-rolled after sass commit. Provided JS test placeholder for the future changes that will require testing.

So, we proposed a JS based approach to have the UI fast.
This though contains 2 problems:
- High JS complexity
- All behavior forms are always rendered even if hidden, making the server side form generation and the browser slow

I think we should restart this implementation with an ajax based approach. After 55 comments, i think it's best in a new issue.
Here's why:
- The content form is slim, fast
- Switching between content and settings is likely not happening THAT much
- The added complexity is small. Two ajax buttons and a new widget state property. A few additional lines if / else to either call content form or behavior settings form.

Created this issue about tristate behavior enabling:
#2856008: Enable behavior plugins with a tristate

After discussion with @Berdir we realized that ajax approach would be much more complex. If there are changes applied to the content and/or behavior fields we would have multiple changes in field widgets leading to complexity in further ajax requests. It would require much more work than a two buttons and a new widget state property.

Uploading patch so the feature can be tested with special cases. I need to fix the tests, write small JS test and move CSS to .scss

Promoting it to critical... The current UX is super cumbersome as soon as plugins are enabled.

I have tested this with a paragraph and nesting. The top level paragrpah had a style and layout selection. The style switched. But layout - and similarly all layout settings of children - were not hidden ever.

Undo prio change. :-)

Added small change to remove overriding the form with an empty array.

Adding a check to make sure that we stay on the same perspective after an action (Duplicate, Remove etc.) being performed. Moving the setting of an active class from back-end to front.

This start to look good. Added this patch to our test environment. :-)

Let's get this in as-is because it significantly improves the UX. But first, let's create the follow-ups that deal with all the problems...
- Deduplicating the JS
- Fix NoJS fallback and improve accessibility
- Switch to collapsed paragraphs widget mode by default
- Only display the tabs if there is a behavior element
-- (Should we display element count in the tab "Behavior (15)"?)
- Hide children / tree if they have no content
- Extend JS test coverage to a case with multiple plugins and nesting. Test each field expectation.

Our top prio is on improving visual language and declutter those plugin settings now.

Ah yeah and... tests are still failing? :-)

Tested functionality of #64, but didn't work.
If i click the behavior tab, i can see the behavior fields.
Then when expanding / collapsing some other paragraph, the behavior tab is staying active, but the behavior fields disappear.
I need to reclick the tab to make them visible.

The patch is addressing the issue of duplicating or editing on Behavior tab, which led to switching back to Content perspective in Ajax form reload. We are assigning class to the layout container and in that way keeping it, without losing it due to form reload. Other changes are test fixes.

Re-rolling.

Improved and fixed JS test.

OK, wanted to commit this as WIP, but still some issues we need to fix first.

1. +++ b/css/paragraphs.widget.css
   @@ -111,3 +111,7 @@
   +.is-horizontal .tabs__tab {
   
   +++ b/css/paragraphs.widget.scss
   @@ -122,3 +122,7 @@
   +.is-horizontal .tabs__tab {
   

   This is not properly prefixed. We can not change ALL horizontal tabs.

2. +++ b/js/paragraphs.admin.js
   @@ -0,0 +1,58 @@
   +      /** Set content fields to visible when tabs are created. After an action being performed, stay on the same
   ...
   +        /** Activate content tab visually if there is no previously activated tab. */
   

   Consider our character limit per line.

Also i see many child items here. Child means we first need to fix children until we can commit the parent and close it.
Instead those should be related. Also they should be more child of our parent META #2825557.
Finally, not all issues listed in comment 66 are created as issues.

This all should be fixed first before a WIP commit.

Addressing comment #74

Another follow-up: The JS only works on nodes. Note that paragraphs could similarly exist on terms or other entities.

+++ b/src/Plugin/Field/FieldWidget/ParagraphsWidget.php
@@ -1264,16 +1306,18 @@ class ParagraphsWidget extends WidgetBase {
-        if (isset($item['behavior_plugins'])) {
+        if (isset($item['subform'])) {

These (and other subform) changes are not related. It even makes things inconsistent here. We should leave this transformation to the other existing issues and limit us here to the purpose only.

Addressing comment #76

Thx, committed. Back to needs-work for complete follow-up management.

What is really critical from #66 is a regression we created.
Everyone switching to the new widget now sees the tabs even if there is (likely) no behavior plugin at all.
Originally worded: "Only display the tabs if there is a behavior element"

Let's try to address this soon.

Adding all follow-ups here:
#2852041: Allow plugins to declare fields as behavior
#2852044: Expose plugins as extra fields to allow configuring the order
#2862929: Refactor JS code for Edit perspectives
#2862933: [META] Edit perspectives user experience
#2862935: Only display tabs if there is a behavior element
#2867035: Add element count display on edit perspectives
#2867049: Extend JS tests for edit perspectives
#2867068: Switch to collapsed paragraphs widget mode by default
Discussing the possible follow-up from comment #66 for hiding children/trees if they have no content/behavior plugins:
In my opinion, for the best UX, we shouldn't hide the elements even if they don't have plugins or content.
Simply because it can be confusing, user can create structure, and then in behavior tab, the structure is different which leads to losing more time when changing the settings and content.

Closing this issue and moving discussion to #2862933: [META] Edit perspectives user experience.

This issue introduced a bug: the javascript is incompatible with Drupal Form API #states. I created a follow-up: #2946856: Perspectives tabs break Form API #states