RFC: Slice Variations Usage

Summary

Improving slices workflow for developers by preventing code duplication and for content writers by improving the writing room with a new feature allowing variations of a same slice. This thread is meant to discuss their usage more than the actual interface.

Concept

The concept of slice variation is about allowing variations within fields used/displayed in the writing room for a given slice. Goals of them are to:

• Improve the writing room interface, only fields relevant to the current variation are being displayed to the content writer;
• Turning slice labels into variation, therefore empowering developers to create more powerful slices.

Example

Considering a SimpleHero slice with two variations:

For the Basic variation, the editor will only display those fields:

• Title (title);
• Description (rich text);
• Featured Image (image).

For the With CTA variation, the editor will also come with additional fields inside its repeatable zone:

• CTA Link (link);
• CTA Label (key text).

To Consider

1. What is happening to fields content if the editor switch from the first variation to a second?

Using the above example if the content writer was using the With CTA variation but decide to switch back to the Basic one:

• What fields are returned by the API?
• If they switch back to the With CTA variation are fields resumed?

2. What is happening if two variations feature a field with the same API ID but the field type is actually different?

Considering a TextMedia slice with a variation with an image field under the API ID media and another variation with an embed field under the same media API ID

Related

Discussing GraphQL/GraphQuery interface for Slice Variations

[Duaner]

Hey all thanks for the great feedback, it’s fantastic to have your input on that.

I completely agree with you @ReeceM we were thinking about that from the beginning of the project. We will support the content migration from a variation to another as soon as the field is having the same key in both variations.

For the design, we were thinking about something like that. Does it correspond to what you’re looking for @davidparys?

Let me know what you think

[hv-prov]

I have another perspective on variations, so allow me share my 2 cents 😊

To me, variations are not satisfying in their current state: the fact that variations don’t truly share fields (just copies of configuration) brings a lot of overhead and is error prone on the long run. Pretty much like sharing slices between custom types before we introduced real shared slices.

Because fields are not shared, changing a field in one variation won’t rapport the change in other variations, although you would tend to think it does. It also means that you’d have to manually propagate a change everywhere. Preserving state between variations in the editor would be somewhat possible but subject to errors too: consider 2 RichTexts with different options: copying content 1 to content 2 might break the constraint on content type (which would let the editor in a pretty weird state).

It’s also much more difficult to handle in the editor and forces everything to be scoped: Storybook stories, both automatic and custom screenshots and mocks. I guess this part is not a major blocker of course 😊

Something I really like at Prismic is that we try to consider if a new feature enforces better practices before releasing it, but following @lihbr 's second message: as is, variations could be used both well and poorly. They require to be thought through carefully and by experience, we know that modelling things the right way is hard, especially in your first projects.

That being said, I would love to be able to preview variations screenshots in my editor, whatever variations mean!