Custom Elements Interop Improvements

[yyx990803]

• Breaking: Custom Elements whitelisting is now performed during template compilation, and should be configured via compiler options instead of runtime config.
  • This removes the runtime overhead for custom elements support.
• Breaking: Restrict the special is prop usage to the reserved <component> tag only.
  • This improves support for customized built-in elements.
• New: Introduce a new v-is directive to support 2.x use cases where is was used on native elements to work around native HTML parsing restrictions.

Full Rendered Proposal

[backbone87]

just some thoughts:

• builtin/custom element: <my-element>
• dynamic builtin/custom element: <[myElementName]>
• component: <!my-component> - registered globally/locally
• dynamic component: <![MyComponent]> - returned by setup/instance prop

(the ! meta char is up to debate)

pros:

• no more is
• clear distinction between components and elements directly inside the template
• removes the need to declare locally registered components when using setup functions
• consistent and aligned syntax for dynamic artifacts (square brackets)

con:

• builtin browser html parser may not be able to parse this
  edit:
  can be worked around by defining expanded forms in case the browser parser is used:
  • <[myElementName]> -> <vue v-element="myElementName">
  • <!my-component> -> <vue v-component="'my-component'">
  • <![MyComponent]> -> <vue v-component="MyComponent">

[yyx990803]

@backbone87 we are not considering any drastic template syntax change at this point.

[jods4]

The idea of <[comp]> as an additional syntax meant to replace <component :is=comp> feels very natural, though, considering the existing dynamic syntaxes.
Could be an idea for 3.1! 💭

[yyx990803]

<[comp]> is not valid HTML (it would be interpreted as plain text by native parsers) so that would not work for in-DOM templates. I'm afraid it's not an option.

[jods4]

so are self-closing tags? They are really handy, I love them.

[yyx990803]

@jods4 yeah, that's an exception for string-only templates (so are CamelCase components). We already have these special cases and it would be wise to avoid adding more, especially when you are not adding new capabilities.

[backbone87]

I provided an expanded form, which the browser should be able to parse

[leopiccionia]

Would the following pattern be removed (guide)?

<table>
  <!-- CustomRow resolves to a function or object, not a string -->
  <tr :is="CustomRow">
    <td>1</td>
  </tr>
</table>

As of today, my evergreen browser still parses:

<table>
  <custom-row>
    <td>1</td>
  </custom-row>
</table>

Like the following:

<custom-row></custom-row>
<table>
  <tr>
    <td>1</td>
  </tr>
</table>

[yyx990803]

@leopiccionia that's a good point. We should still support this case when is binding value is not a string. <- I think different behavior based on binding value can be confusing, especially when this means you have to expose the component directly to the render context instead of normally registering it.

Maybe we need to introduce a separate v-is directive for the in-DOM use cases:

<table>
  <tr v-is="CustomRow">
    <td>1</td>
  </tr>
</table>

And if the user registered CustomRow via the components option:

<table>
  <tr v-is="'CustomRow'">
    <td>1</td>
  </tr>
</table>

[Justineo]

Code style seems inconsistent with the later part of the RFC, maybe something wrong with the formatter?

[posva]

We could add a .prettierrc file to make it automatic for people using a plugin with their IDE

[yyx990803]

done

[yyx990803]

This RFC is now in final comments stage. An RFC in final comments stage means that:

The core team has reviewed the feedback and reached consensus about the general direction of the RFC and believe that this RFC is a worthwhile addition to the framework.
Final comments stage does not mean the RFC's design details are final - we may still tweak the details as we implement it and discover new technical insights or constraints. It may even be further adjusted based on user feedback after it lands in an alpha/beta release.
If no major objections with solid supporting arguments have been presented after a week, the RFC will be merged and become an active RFC.