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.

[azamat-sharapov]

@fullfs do "file/replace in all files using some regex". This might save some time for you or anybody who is refactoring: https://regex101.com/r/yH5iU8/2 (achtung! that's quick regex, don't take it too serious).

[fullfs]

@azamat-sharapov aye, but simple replace won't be enough in my case. Have to do some logic corretions too.

[fullfs]

Oh and I use partials a lot. It's very useful sometimes. Definitely don't want to convert them all into components...

[young-steveo]

@fullfs It seems you have built a pretty large body of work around a pre-v1.0.0 library. That can sometimes get pretty painful as the API stabilizes.

[fullfs]

@young-steveo true. And I'm aware it. It was a risk to begin with. But I can give some useful feedback :D So I'd like partials to be kept :)

[yyx990803]

@fullfs if you really want partials that bad, we can maybe ship it as a standalone directive separately.

[mark-hahn]

@OEvgeny said ... Wonder why people love is so much. At first is is a verb.

The word "is" is an indicative which is nothing like a noun or verb. An indicative indicates what something is. So its usage is perfect here.

[kazupon]

In async components feature, when the undefined component found, if we can resolve lazy-loading with hook function, I think that is very useful.

like this:

var Vue = require('Vue')
var _ = Vue.util

new Vue({
  ...

  components: {
    // with object
    component1: {
      ...
    },
    // with url path
    component2: 'components/component2.js',
    ...
  },
  ...

  // lazy-loading hook function
  loading: function (raw, resolve) {
    if (_.isPlainObject(raw) { // component plain object
      resolve(raw)
    } else if (typeof raw === 'string') { // component url path
      // lazy-loading with require.js
      require([raw], resolve)

      /* lazy-loading with webpack
      require.ensure([raw], function (require) {
        resolve(require(raw))
      })
      */
    }
  },
  ...
}).$mount('#app')
...

what do you think about it ?

[yyx990803]

@kazupon one problem with this is that module bundler like Browserify and Webpack rely on seeing the literal string of module id (e.g. require('my-component')) in order to resolve dependencies between modules. When you require(dynamicVar), they won't be able to tell which module you are trying to require.

This should work with requirejs though. You can make a helper function:

function async (path) {
  return function (resolve) {
    require([path], resolve)
  }
}

Vue.component(async('my-component.js'))

[fullfs]

@yyx990803 by the way, please notice error handling while getting async components. There is a problem with the case while using webpack.

[yyx990803]

@fullfs can you elaborate?

[fullfs]

@yyx990803 Ok, for example we've got an async component require. In webpack we go like this first:

var component = require('bundle?lazy&name=component!My/Async/Component');

Then we try to pull the component:

component(function (file) {
    resolve(file);
});

The thing is there is no way we can catch an error if server didn't respond (server may go down or something). The callback just won't fire. I've tried a plugin for the case, but it didn't work properly too. Then my app just will be freezed.

So there is a need for some way to catch the error (timeout?) and say something like "oops we couldn't get the component, so lets fall back".

It could be a reject callback, for example:

components: {
  'my-async-component': function (resolve, reject) {
    var timeout = setTimeout(function () {
      reject('timeout');
    }, 3000);
    require(['./my-async-component'], function (file) {
      clearTimeout(timeout)
      resolve(file)
    })
  }
}

[kazupon]

@yyx990803 I see !! I will try to use helper function. :)

[yyx990803]

@fullfs it might be helpful to have some warning, but if you failed to resolve an async component, what would you expect as the fallback? There's no component to render, so the app can't really do anything. Calling the callback when the component resolution has failed will just result in an error.

You can actually create a generic "oops" component and just resolve(oops) when something goes wrong...

[fullfs]

@yyx990803 When async component's failed to resolve I want a way for my app to react, that's it. Resolving another component is a good thing. It's actually the fallback I'd like to have (for some reason didn't think I could do that :D). Thanks :)

[yyx990803]

Some thoughts on improving DOM event and Vue event handling syntax: https://github.com/yyx990803/vue/issues/722#issuecomment-109849898

[nirazul]

I don't like the proposal concerning v-on. I imagine that it can get very sluggish when you want to handle multiple dom-events on the same element. For me it's no improvement to switch out a custom tag with an also namespaced tag which is different for every event that exists and is to come in the future. I like the possibility to pass a dynamic object to v-on, rather than writing custom tags for everything.

As for v-events I've recently had some struggle to differenciate between using v-events as a Directive and the events property. Maybe these two could be made clearer.

[fullfs]

@yyx990803 By the way, talking about version 0.12. Is there any hope to have 0.11 -> 0.12 migration plugin? :) I would have really hard time with the migration if no, after all. There are 3 things I'd like to have there: v-component, v-with and partials.

[thelinuxlich]

I don't see any benefits for the new event syntax :(

[yyx990803]

Looks like most people want to stick with v- directives, we'll keep things as is for now then. Maybe v-events can have a better name, e.g. v-callbacks?

[nirazul]

v-callbacks sounds alright, maybe v-listeners would be clearer for the purpose. It sort of "listens" for events happening in its child.

[yyx990803]

@Nirazul I've decided to just remove it. You can now just pass down parent methods as props and let children call them.

[federicodionisi]

@yyx990803 As @fullfs suggested, would be really nice to have a migration plugin from 0.11.0 to 0.12.0

All new features inside 0.12.0 are amazing but most of them are breaking changes and for those who are using Vue in production will be painful to update it.

[cjsaylor]

@fullfs @federicodionisi You guys should collaborate and make one. I don't think it's necessary for a library author of pre-release software to also have to contend with writing migration scripts.

[fullfs]

@yyx990803 Can I ask you for solution about partials? Now it's gone and they need to be replaced by something. I usully use partials as something similar to template includes to make my templates smaller. For example, I'm selling apartments and I've got a page with about one with several sets of props. There are a lot of props there, but all of them are just a part of single data object. And so I've got several partials with sets of the params for each view case. What should I do now? The simplest solution is to make them into components with inherit: true, but it looks overhead to me, I don't want to create extra VMs. Is there any recommended way?

[yyx990803]

@fullfs does making v-html auto compile its content sound like a solution?

[fullfs]

@yyx990803 I'm afraid it's not. I won't be able to use v-on and etc. there, right? Basically I just want to split one big template into several small templates

[nirazul]

I have the same feeling about v-partial. It was the excellent solution for a component that can take multiple shapes that differ in markup and css, but not in functionality. Now I'm forced to use v-if, v-html or make a new component.

[yyx990803]

Yeah, ever since 0.12 I've seen people run into cases where partial just makes more sense. I'll consider adding it back in 0.12.2.

[fullfs]

@yyx990803 That would be absolutely great! Thanks!