feat: created generic Codepen Snippet component

[ErickPetru]

Description of Problem

Right now, more than 20 files along the documentation have Codepen embeds with small changes on each one, like this:

<p class="codepen" data-height="300" data-theme-id="39028" data-default-tab="result" data-user="Vue" data-slug-hash="KKpRVvJ" data-preview="true" data-editable="true" style="height: 300px; box-sizing: border-box; display: flex; align-items: center; justify-content: center; border: 2px solid; margin: 1em 0; padding: 1em;" data-pen-title="Attribute dynamic binding">
  <span>See the Pen <a href="https://codepen.io/team/Vue/pen/KKpRVvJ">
  Attribute dynamic binding</a> by Vue (<a href="https://codepen.io/Vue">@Vue</a>)
  on <a href="https://codepen.io">CodePen</a>.</span>
</p>
<script async src="https://static.codepen.io/assets/embed/ei.js"></script>

This large block of copied-and-pasted content takes up a lot of space in each place and is hard to maintain.

Also, as a documentation translation maintainer, I feel how it's annoying to keep all embeds translated in the same way when we have different collaborators translating different files.

And last but not least, using Single File Components inside Markdown with VuePress is so cool! Why not take advantage of this tool one more time to improve this scenario?

Proposed Solution

A generic Codepen Snippet component, with props covering all different situations where Codepen embeds are use a little different across the documentation, but with good defaults that cover the majority of the use cases, to keep the usage simple.

Additional Information

I took the liberty of changing all the Codepen embeds currently used in the documentation to use the new component, in order to test its effectiveness (and also to facilitate the work of the core team). I am available to make any additional adjustments to it if necessary.

[NataliaTepluhina]

@ErickPetru I like the idea! I've left one nitpick to codepen component but overall it looks good to me 👍🏻

[skirtles-code]

A few suggestions from me.

[bencodezen]

Thanks for the work on this @ErickPetru! Your refactoring has shown us that there's some clean up that needs to do in terms of standardizing some things so it's easier to turn into a component. I think we should probably hold on this until those changes are made so you can update the PR.

[ErickPetru]

Hi @bencodezen, my intention with this PR was not to change current behavior.

I really forgot some possible adaptations at the first pass, but after @skirtles-code review, I've already sent more commits with everything (I hope) in the same way it was before.

I believe it's secure to merge after the next review phase. Indeed, even future standardization on the embeds will be a lot easier with the new component. Also, feel free to ask for more changes if you want.

[skirtles-code]

@ErickPetru Currently there are conflicts with master.

Given what @bencodezen said, I'm unclear whether more conflicts are coming or if this is now good to proceed.

I'm happy to do another review but I'd rather wait for confirmation that there aren't more conflicts coming first.

[ErickPetru]

@skirtles-code and @bencodezen I saw the recent changes on examples/modal.md and examples/grid-component.md adding the updated Codepen URLs. So I just sent these two updated using the CodepenSnippet component.

[skirtles-code]

Some more suggestions from me.

I've not made any subjective decisions about whether things matter, I've just reported anything that seems to have changed from what was there previously.

I agree that this component should make it easier to remove the current inconsistencies.

[ErickPetru]

Sorry for the delay, hard job weeks here currently.
I've just updated with the corrections after the second @skirtles-code review.

[skirtles-code]

There's a new CodePen example at the bottom of transitions-enterleave.md.

Usually I'd suggest migrating it post-merge but in this case it seems that the component can't co-exist with non-component CodePens. That new example gets a thick, black border around it as a result.

I did a bit of debugging and it seems to be a consequence of how SSR and the CodePen script interact with each other. So long as everything is using the component it should be fine.

As SSR is involved you can only see the problem by going directly to the right page:

https://deploy-preview-548--vue-docs-next-preview.netlify.app/guide/transitions-enterleave.html#transitioning-between-components

If you navigate there via another page it all behaves.

[ErickPetru]

Incredible was your catch about SSR with Codepen embeds without the new component, @skirtles-code!

So as you suggested, I just updated guide/transitions-enterleave.md changing the last embed to also use the component.

Then I just realized that the project could have direct <iframe> embeds to, and I was right. So I changed to use the component also in the files guide/optimizations.md and guide/reactivity.md. While the way it works becomes a little different (from an direct <iframe> to a <p> converted to an <iframe> by https://static.codepen.io/assets/embed/ei.js), in my tests it offers the same experience to the end user and finally standardize all the guide to use the CodepenSnippet component.

Please take a look and talk to me if something more is needed.

[bencodezen]

Thanks for your hard work on this @ErickPetru!

[bencodezen]

When defining props, it's best to choose either default or required. Otherwise, they basically cancel each other out.

In this case, it should most likely be required with no default property.

[bencodezen]

Same as above

[bencodezen]

If the type should be String, then we should set the default to '' instead to be consistent.