0.12 Plan - feedback welcome

[yyx990803]

Hi Vue.js users, here is a list of changes I'm planning for the 0.12 release. The goal is to remove some cruft in the API and make things more consistent across the board. The two new features have already been implemented in the dev branch, and I will soon start doing 0.12 beta releases so people can try it out. The breaking changes are pretty much just ideas that I'd like to gather feedback for - in particular, let me know how hard do you think it would be for you to migrate your existing app if these changes went live.

New Features

• async components. Allows defining a component as a function that asynchronous resolves the component definition. This would enable easy lazy-loading mechanisms.
• one-way paramAttributes/props syntax (prop="{{*onetime}}")

  Breaking Changes

• paramAttributes renamed to props.
• Intent to remove: v-partial and {{>partial}} syntax. The partial concept is a legacy from string-based templates, and isn't particularly useful when everything should just be components.
• Intent to remove: v-with syntax.
  • It allows the user to add arbitrary data fields to a child component, which may conflict with the child's default data. At the same time, the child needs to be more explicit about what it expects from the parent.
  • It's also confusing to have two ways of doing the same thing. Everything should just be props (previously paramAttributes).
  • The name v-with isn't super precise for what it does now: passing data down to a child. It is also a legacy from string templates that uses {{#with}} blocks to shift the data context.
• Intent to remove: v-component syntax.
  • Similar to v-with, it doesn't make much sense to have two ways of doing the same thing. Every component should just be a custom tag.
  • For dynamic components, use the special <component is="{{view}}"></component> syntax. "component" is a reserved component name.
  • It should no longer be required to have a hyphen in your component name in order to use it as a custom tag.
• Intent to remove: replace option. A component always replaces its placeholder node.
• Intent to remove: inherit option. Prefer explicitly passing down props.

[holic]

:+1:

I'm not sure on the proposed inherit changes. I was working on an app where I tried to make use of paramAttributes to keep my components isolated without tight coupling, but ran into issues. I'll see if I can remember or recreate them so I can mention them here.

[thelinuxlich]

Agree with everything minus removing the inherit option.

[taylorotwell]

Looks pretty good overall!

[kazupon]

:+1:

Among them, I agree especially with removing the v-with directive. because it breaking the child component data.

[nadirabid]

:+1:

Vue's simple and flexible API is paramount. To be honest, I haven't personally found need for async but I can see it being useful.

Looking forward to 0.12!

[cheapsteak]

Breaking v-with would certainly be a pain to refactor were we to upgrade, but I think it's the right way to go. :+1:

[OEvgeny]

Looks pretty good. Except maybe inheritance. But I think with proper props implementation we will not need to inherit all data. Anyway inherit breaks component system, I think.

As I thought one of the partials purposes was to decrease number of complete Vue instances and replace it with something lightweight. Am I wrong? To be honest, didn't use it overall, but it looks useful.

Also Vue documentation is great, but sometimes I need it to be more reach. Any plans for it?

Waiting for 0.12 too!

[ayamflow]

:+1: pretty good to see Vue move closer to "real" web components.

[pechorin]

:+1:

Removing v-with and v-component is great simplification. Also props look's more like react and this is also nice idea.

[crswll]

:+1:

This all sounds great to me.

[azamat-sharapov]

This is great!!!! Especially async components (which enables lazy loading). I've been spending so many hours to get it work via webpack :D will refactor with pleasure to have lazy loading only from Vue, instead of webpack.

Does "one-way props" have performance advantages? Or it's just for better isolation/protection of prop?

[yyx990803]

@azamat-sharapov performance will be largely the same, it's for better isolation. In some cases you don't want the component to be able to mutate parent state.

[azamat-sharapov]

@yyx990803 thanks. Personally for my projects, if I decide to switch to 0.12, I will have to get rid of v-component, I have been using it since it's not always easy to come up with good name for component without dash. So now dash is not necessary and it's helpful. Never used partials and always avoid use of inherit since it looks like bad practice to me, so +1 for removing it. And I still have v-with in some places, though I lately got used to paramAttributes and think it's better, so +1 for removing v-with too, even though it requires refactoring for many.

[young-steveo]

@yyx990803 I seem to be in the minority when it comes to v-component; I'm a fan of the <div v-component="{{ view }}"></div> syntax. I never use custom tags in my projects (no strong opinion against custom tags, I just prefer the aesthetics of attributes). This isn't the end of the world, and I love using Vue, so I'll migrate to <dynamic-component type="{{ view }}"></dynamic-component> if this change is set in stone.

Love the idea of async components! :+1:

[crswll]

@young-steveo Agreed, but I think it's just us being stubborn. It's definitely going to be the norm in the future.

[yyx990803]

Update:

• Simplified <dynamic-component type="{{view}}"> to just <component type="{{view}}">.
• replace option will be preserved, due to it requiring some significant refactoring for some existing apps. For those of you would like to have it default to true, you can do so by setting Vue.options.replace = true.
• inherit option will be preserved, although it should be treated as "only use if you know what you are doing"...

[steffans]

:+1:

What about naming dynamic components <v-component type="{{ view }}"><v-component>, it's shorter and it matches the current attribute namespace style.

[holic]

replace option will be preserved, due to it requiring some significant refactoring for some existing apps.

Curious what these use-cases are that would require major refactoring?

[285858315]

async components 这个真的很赞！

[sjoerdvisscher]

If <component type="{{view}}"> is only used for dynamic content, you could make type a reactive directive, instead of a literal one: <component type="view">

[azamat-sharapov]

Why is it type anyway? how about name or variable or maybe source ? can't understand meaning of type..

[yyx990803]

@sjoerdvisscher you can still do <component type="component-id"> and it resolves to the component-id literal value. type here is similar to a prop and the braces make it explicit that it is bound to a dynamic value.

[taylorotwell]

Agree that name "type" is not very intuitive.

On Saturday, May 16, 2015, Evan You notifications@github.com wrote:

@sjoerdvisscher https://github.com/sjoerdvisscher you can still do <component type="component-id"> and it resolves to the component-id literal value. type here is similar to a prop and the braces make it explicit that it is bound to a dynamic value.

— Reply to this email directly or view it on GitHub https://github.com/vuejs/Discussion/issues/158#issuecomment-102650522.

[yyx990803]

What would be better though? I don't think name, variable or source is any better than type.

[crswll]

It tells you what type of component it is just like <input type="password"> tells you it's an <input> of type password. I think it makes sense.

[RangerMauve]

I agree that type makes sense. However, might I suggest borrowing is from the web components spec? Or would that just make things more confusing like having a dash in the name did.

[yyx990803]

@RangerMauve is sounds like a plausible idea, and it resembles real Web Components...

Just to get a feeling of what it looks like:

<component is="{{view}}"></component>

Although personally I still prefer type.

[kzima]

+1 for async components and lazy-loading mechanisms. However, I wonder how would that play with webpack?

[yyx990803]

@kzima like this:

components: {
  'my-async-component': function (resolve) {
    // require.ensure is webpack's code-splitting point
    require.ensure(['./my-async-component.js'], function (require) {
      resolve(require('./my-async-component.js'))
    })
  }
}

It could be even simpler using webpack's AMD syntax:

components: {
  'my-async-component': function (resolve) {
    require(['./my-async-component'], resolve)
  }
}

[azamat-sharapov]

@yyx990803 no passing require parameter?

[yyx990803]

@azamat-sharapov fixed

[ayamflow]

@yyx990803 the only thing that feels "unatural" is the <component type=".."> syntax. I saw something about a <{{component}} />in the ractive repo issues but I don't think it's functional. I guess there's not a lot of alternatives tho.

[azamat-sharapov]

type sounded wierd for me in the beginning too, but when @crswll mentioned that it's like <input type="something">, it made sense. But for newcomers, it will probably be confusing, especially if they are not much into frontend stuff. For example Taylor Otwell is more server-side-code guru and thinks that type is not very intuitive, whereas Evan - Javascript/HTML5 ninja prefers type. Although is sounds very easy as mentioned here and probably is better choice overall :)

[thelinuxlich]

+1 for "is"

[OEvgeny]

For me type sounds good.

[kazupon]

+1 for is

[nirazul]

+1 for is

I wonder why v-partial was removed and what the altermative would look like. I especially liked it for really flexible components that have multiple appearances (f. ex. selector-modules that could assume the form of a dropdown, a list or something other). The appearance could be decided by choosing a type, which was very convenient!

[yyx990803]

Update:

• Dynamic component syntax now uses is since people like it and it also brings the concept closer to the real web components spec.

The change is included in 0.12.0-beta3.

[OEvgeny]

Wonder why people love is so much. At first is is a verb. Now we have (only one?) attribute what is verb instead of noun. Anyway, it's not very important. I'm only trying to understand why :smile:

[azamat-sharapov]

It's not about they love it :) It began, because type was little hard to figure out, for most people. As noted earlier, is it's more near to real web components specs (http://webcomponents.org/articles/introduction-to-custom-elements/). Also, I personally think vue should be simple to understand for everybody, so they focus on code, read through code faster. is is more readable.

<components type="{{currentView}}">

vs.

<components is="{{currentView}}">

[OEvgeny]

Wow, thanks for the link. Now I see is is a good choice.

[ayamflow]

@yyx990803 By the way, have you considered moving some of the Vue internals to external modules/repos? Since the library is getting a bit bigger that it originally was, it might be useful for code reuse, debugging and maintainability to not have everything under the same repo. Thoughts?

I'm thinking with the observation and templating in mind, since this is something that will come soon to the browser with ES6/7. Since you are trying to follow as much as possible the Webcomponents spec, maybe using Object.observe() specs as well for instance? It would make it easy to switch to the native API when supported, thus lightening the compiled script.

For instance, I've been using Ampersand lately and I love that everything is a module that you can change. A good example is their observation module: ampersand-state (though they are not really following any specs).

[yyx990803]

Update: Filter Syntax Change

Some thoughts on filter arguments syntax improvements:

• Currently filter arguments are treated as plain strings, and can be enclosed in quotes.
• In filterBy and orderBy, in order to differentiate between dynamic key and static key, the quotes in arguments are preserved.
• A problem with this though, is that quotes are also preserved for other filters such as pluralize, and all custom filters as well.
• This is also inconsistent, because in filterBy and orderBy you need quotes to indicate a plain string, but in other filters you don't.

Proposed fix (breaking):

All arguments to filters, if not in quotes, are treated as dynamic paths (and the argument will be auto-retrieved from the vm when the filter function is called); only arguments enclosed in quotes are passed in as plain strings.

This means the usage of some existing filters will have to change:

<a v-on="keyup: onKeyUp | key 'enter'"></a>
{{ items.length | pluralize 'item' }}

This would also make writing custom filters a bit easier, e.g.

{{ msg | concat otherMsg }}

Here the first argument to the concat filter will be the value of this.otherMsg.

Ref: https://github.com/yyx990803/vue/issues/865

[RangerMauve]

Yeah, having quotes around arguments that should be strings makes sense. It feels less "magical", too.

[yyx990803]

@ayamflow I've been thinking about this, and my general opinion is that there is no "right level of modularization". People have different preferences on how fine-grained modularization should be: some people like monolithic solutions; some people like picking their own view-layer, persistence-layer and router; some people like going even lower level and hand-pick every single component (e.g. AmpersandJS). But being finer-grained is not strictly better than the other solutions, because the choice is really about how much flexibility you want VS. how much time you are willing to invest in picking your own components.

From a library's perspective, it is about what the core value the library is designed to provide: the whole system consisted of these modules, or the reusability of the modules out of the system context. The latter is what AmpersandJS is all about, but is not what defines Vue as a project.

Finally, I can assure you breaking Vue into smaller modules would increase the cost of maintenance rather decreasing it. So given the limited energy I can put into Vue, I don't think I'll do that in the foreseeable future. (Maybe when Object.observe reaches candidate stage)

[holic]

:+1: For the proposed filter syntax change.

[ayamflow]

@yyx990803 yes this totally makes sense. Thanks for the detailed answer. I think the true benefit would be for all things related to specs so at some point it can be dropped for the native implementation. But since none of that is ready yet... :)

[kazupon]

:+1: For filter syntax change

[steffans]

@yyx990803 I like the new filter syntax :+1: Support for object definitions would be also nice, see pull request: https://github.com/yyx990803/vue/pull/834

[fullfs]

Great changes! Though I prety much never used components as custom elements. Used to v-component syntax. Will be A LOT of pain refactoring my project for those changes. Probably will have to delay the migration for a few months