Add a JS based collapse / expand

I think an important concern is to avoid too big a draggable element, to minimize the need for scrolling. For a draggable list which might
a) have many items
b) have nesting (one day)
c) need to be worked with on mobile etc.
it would seem best to keep the height of each item very small: one or 2 lines of text or a small thumbnail if there's an image field.

The name of the paragraph type already provides quite a lot of information, combined with the first 5-10 words of text from the paragraph might be enough.

So either summary formatter or first field could work, provided they were trimmed enough.

One question is the extent to which you try to maintain a preview-like environment (e.g. by keeping multiple columns if multi-column layouts are being used, perhaps preferring shrinking elements over trimming them), vs creating a tree-like abstract environment.

hi,

attached is a patch that ports the current functionality that we have in paragraphs_collapsible into the paragraphs module.

by default, paragraphs will be closed

you can expand them individually using the "+" sign or all by once using the "expand all" link

initially, we also had a nice feature to collapse everything when starting to drag & expand afterwards, but this led to some issues on long form pages with screens & editors getting lost in vertical space. if you are interested in trying it out, you can take a look here:
https://github.com/AmazeeLabs/paragraphs_collapsible/commit/2efb64aa6b6b...

this is intended to be used with the edit mode mainly and definitely needs alignment with the already existing features that paragraphs has (closed, edit & preview modes)

There was a long discussion about the vertical lines since they are not part of core patterns, will they be added anyway?

Might not this approach (#7.2 and #7.3) create undesirable complexity for maintainers and users?

There'd be 3 different edit modes, each with a different logic and distinct code.
In "Closed" mode, paras are closed by default and you use the AJAX action "Edit" to expand and the AJAX action "Collapse" to close them.
In "Edit" mode, paras are open as forms by default, you can't preview them, and you use the + and - to expand and close them.
In "Preview" mode, paras are open to preview by default, you use the AJAX action "Edit" to open as form, the AJAX action "Collapse" to go back to preview, and you can't close them.

Maybe it's worth a little extra care at this point to make a simpler solution, by cutting out some of the current AJAX logic at the same time as adding the new frontend-only functionality?

How about this?
1) We keep the 3 choices in the configuration: Closed, Edit, Preview
2) But Closed just means Edit mode, but with everything closed initially on the frontend using CSS /js as @dasjo's patch does. In terms of AJAX and the backend, we only have 2 states/actions/codepaths (Edit & Preview).
3) + and - for expand/collapse are available in both preview and edit modes . (working in the frontend only exactly as they do in edit mode in @dasjo's patch)
4) The actions "Preview" or "Edit" are always available, and there is no "Collapse" (which is just how preview mode currently works, except that the action to preview after editing is perversely called "Collapse").

To do this would require:
A) tweaking dasjo's code to apply in preview mode also
B) Removing AJAX collapse
C) Simplifying the conditional logic about when to show Preview/Edit/Collapse actions

P.S. There's quite a few out-of-scope CSS tweaks in the patch, not just the vertical lines, and quite a few tweaks of uncertain purpose that may or may not be in scope.