Create code examples: Resource details layout

[SeanyB]

Design tasks
- [ ] Summarize what UI elements that should be included in template scope
- [ ] Summarize what content that should exemplify the merchant activity
- [ ] Specify any important defaults, such as fullWidth prop
- [ ] List places/decisions that might require code comments

^ We didn't explicitly complete these, but I believe the code example on staging meets the needs. It's s simplified reproduction a product details page with skeleton content.

Remaining tasks:

• Replace actionGroups prop with secondaryActions prop
• Use the common object actions listed in this comment below

[raquelbreternitz]

As for 1. and 2., is there anything that would be different from the existing annotated cover-image? My gut feeling is that that would be a red flag, but I wanted to make sure I understood what was desired here.

[johanstromqvist]

Is there an opinion or decision about using a code example with skeleton like placeholders? It comes across as a loading state to me and I would assume builders can infer a lot of important decision-making from realistic examples, which might both speed up workflow and increase quality.

is there anything that would be different from the existing annotated cover-image?

@raquelbreternitz Are you asking if we need to update the annotated image based on the look of the code example?

[gwyneplaine]

Is there an opinion or decision about using a code example with skeleton like placeholders? It comes across as a loading state to me and I would assume builders can infer a lot of important decision-making from realistic examples, which might both speed up workflow and increase quality.

We discussed this in our sync earlier, and glad this isn't a blocker for MVP. Just wanted to add more detail here for future context 🎉.

The resource details layout (as shown in the cover image) includes a WYSIWYG editor. We don't have a WYSIWYG component in Polaris. This is a good example of the tension we were talking about. Its a tension between two principles we've touched on a few times now:

• Providing useful and realistic pattern examples
• Ensuring patterns only encapsulate Polaris components

This also segues into the question of where the line is between providing enough guidance to admin builders, and shouldering too much engineering complexity outside of the domain of Polaris. This is good stuff though I think teasing apart this problem will help us understand what a good pattern should look like for all builders

[alex-page]

Can we remove the Editor buttons in the screenshots. This is a super requested Polaris feature which we cannot support. See this thread #303