Component-level delimiter option

[yyx990803]

In #915 it is pointed out that the global delimiter option makes an application with custom delimiters incompatible with 3rd-party components that assumes the default delimiter settings. The solution would be either

• A: Allow components to define a component-level delimiter setting that overwrites the global, so that 3rd-party components that are intended to be generally reusable can lock down its own delimiters.

or

• B: Remove the global delimiter setting and make it strictly component-level.

Option A is backwards compatible but it requires component authors to be aware of this requirement.

Option B is breaking and requires this option in every component that needs custom delimiters. However it should be noted that in most cases, the only component that needs a custom delimiter is the root instance in the HTML (so that it can be compatible with server-side templating languages that also uses mustaches)

[young-steveo]

Option B makes sense.

I think the vast majority of users rely on classic mustache tags. Arguing over custom tags is akin to the spaces-v.s.-tabs debate. With option B, an opinionated component remains compatible with the ecosystem, and an opinionated app can still use common third party components.

I vote for option B too.

The only reason I liked this syntax is that you can easily see if the string will be or not escaped just scanning without wasting time by checking if is a triple braces.

[iCodeForBananas]

I agree with @young-steveo, in the grand scheme of things this appears to be a "spaces vs tabs" argument with fairly low importance. Unless I'm missing something.

[yyx990803]

@michaeljcalkins it's mostly for situations where people are writing direct HTML Vue.js templates inside another templating system that also happens to use mustache tags.

[yyx990803]

After some experimentation, implementing this change actually affects many parts of the compilation chain and requires non-trivial refactoring, while the benefits of it is marginal (one can always put the root template into a string instead of raw HTML.) So we are not going to move forward with this.

[martywallace]

Was this ever revisited or was an alternative solution available? We use alternate delimiters in all of our projects to avoid Twig conflicts but I've just started putting some of our components on Bower. Obviously they need to use the default delimiters to be of any use to anyone but they don't work in our projects if we do that. A more detailed version of this query is here in my question on StackOverflow.

[JoshTheDerf]

I'm looking into the template compiler to see if this is possible. In theory, depending on how vue 2.0 generates its AST, it should be possible to add component-level delimiters, but I'm not sure of this.

[JoshTheDerf]

@yyx990803 Should you be interested in reconsidering this, I believe this could be implemented in Vue 2.0 by overriding delimiters in https://github.com/vuejs/vue/blob/next/src/compiler/parser/index.js#L219 and https://github.com/vuejs/vue/blob/next/src/compiler/parser/index.js#L407
That just leaves the question as to how it would be specified in a component's source.

[fnlctrl]

@martywallace @tribex FYI 2.0 already has component-level delimiters. [https://github.com//issues/2873](2.0 changes) Options -> Misc -> delimiters new, replacing the original global config option. Only available in standalone build.

[JoshTheDerf]

@fnlctrl Oh. Well then, that simplifies things.
Btw, is that the correct link? I believe you meant this: #2873

[martywallace]

Is there no even "hacky" way to achieve this within the component JavaScript in 1.x? At the moment I can only achieve what I want by forcing the update of the delimiters between the include for Vue and any component includes like this.