[META] Reuse paragraphs / Library

Nice. Didn't know something like this exists.
At least we have some idea from D7. :-)

Note that with the entity_reference_revision field currently, this would result in trouble.

If a reusable paragraph would be updated, the using nodes would still point to previous revisions.
Thus, reusable paragraphs would need to be referred without revision id... which means to always use latest revision.

I understand the argument of using a different content entity. And we could create a paragraph wrapper of type "Reusable content" with a further entity reference... possibly even using the entity browser to browse or add a new one.

But for the use case of reusing a "paragraph" in the mindset of a user (and not any known other entity) i have the feeling this direction makes the UI more complicated.

People asked me immediately about reuse when i have shown them paragraphs.
No need to take actions or decisions now. I would keep it as common feature request open... And one day we can also offer some best practice recommendation if the feature won't be provided by paragraphs on its own.

I recently found multiple references about making paragraphs reusable. Including:
https://www.commercialprogression.com/post/paragraphs-are-drupals-answer...

Note also that people compare Paragraphs with Atoms that offers reusability / considers it a key concept. ;-)
https://www.drupal.org/project/atoms

We decided that paragraphs are embedded / composite by design and separately maintain them is against our architecture.
The composite relationship will be cleanly managed by ERR in #2641824: Maintain composite relationship

Thus, reuse needs a separate entity where metadata such as labels makes sense.
For paragraphs itself though, we will not support it ever.

I'm leaving this issue still open as a feature request and updating the issue summary.
See also #2601096: Merge with Bricks / Atoms where i hope collaboration and reuse can evolve.

From Paragraphs workshop:
Not a common use case, possibly also because it's not really supported out of the box.
But for advanced Paragraphs based strongly content driven applications, it can be very helpful.

Examples: Testimonials or predefined marketing statements to place the same multiple times accross a site.

Slashrsm mentioned there is overlap with Media projects and other entities.
We discussed some examples to understand why an own entity makes sense:
Block have probles with cluttering admin UI because each block instance appears.
Node based approaches need rabbithole and search exclusion.
The Media entity is usually not used for this kind of content.

Note that a custom entity type would sync bundles and fields. Each paragraph type would automatically also have a corresponding reusable type. Thus we can easily convert paragraphs back and forth, without the need to build the reusable types and configure a mapping.

@DamienMcKennna: That's the whole idea. Let me explain in a bit more detail.

But we want to make this separate entity type:
- Autosync with bundles + fields of Paragraphs
- Still add a label (plus more administrational fields if needed for managing them).

A reusable paragraph will be typically stored as a clone of a previous paragraph. It is NOT a composite of the original.
Reusable paragraphs have an own separate edit form and can also be creted independently through the Add form.

A user can click the action "Add to library" that makes a paragraph reusable.
This clones the paragraph and the original host entity will have a new paragraph instance added that contains a reference to the effective reusable paragraph.

The paragraph type "From Library" contains nothing but a entity reference to the reusable paragraph.
Initially, using autocomplete widget here is fine.

@Frando Yeah agree. This might fit better in simplicity.

It adds one limitation though. We only create one bundle (in case you need extra fields for management of the library).
Say, you might want to create extra fields to browse your huge collections of testimonials, thus attach terms... while that term field doesn't make sense to classify other paragraph types.
This classification might only make sense in the library as when simply creating the paragraphs inline it's unneeded management field clutter.
Keep in mind, this needs to be made for huge collections with rich data types.

So while not syncing fields (through putting an ER field) we might still need to sync bundles to make use of bundles.

One caveat is, now a reused paragraph involves 3 entities inside the host entity with the ERR paragraph field:
- The paragraph entity that represents the reused placement with the ER field
- The library entity with label with an ER field
- The paragraph entity containing the content
So that's one entity more. Hope we will still perform well in complex datasets.

@johnkirkilis The screens you have seen are mockups. The implementation is a first step. And there are many follow-ups to improve. Both picking an item and converting an item is not yet implemented.
Also we have decided that with our initial version:
- Everywhere you use the library it points to the latest version (an entity reference, not an ERR field!)
- The user is made aware that the change affects all usages immediately.

Note that ERR doesn't offer a selection widget that allows a user to pick the used version or even make the user aware of the fact that it points to an outdated version. Also, maintaining workflows as you wish is more related to the Drupal core workflow initiative.
Once tools are reliable and available, we can look into how we want to deal with it.
A follow-up (we will postpone it) would be great.

Picking an item and clone it is how Templates (a concept on top of the library) works. We want to avoid mixing the two cases:
Picking a library item makes it a reference. Picking a library item that is marked as being a template, will clone it.
#2826687: [META] Introduce Templates

The mockups are misleading. What you see is the drag&drop mode that will be introduced here:
#2825575: Introduce a Drag & Drop Mode
But this mode will likely not offer the conversion action. Instead it is offered in regular edit/collapsed mode.

@Pasqualle We have added the Paragraphs Library module in the most recent release. It's a first step towards optional reusability with some basic transformation workflows (into the library and back to unlink from the library). That's a great start and time to assess additional requirements so we can put the priorities right to make this more mature.

I didn't know the Box module, so i would like to hear a bit more if it has some advantages to the library in the current version.