roadmap

[yyx990803]

Core

• v0.9.x: Animation and Transition ✓
• v0.10.x: API and internal improvements ✓
• v0.11.x: Consolidate API for future specs ✓
• v0.12.x: Improve API to make it easier to ship standalone, reusable components and build larger-scale applications.

Tooling

• Chrome dev tools extension ✓
• CSP-compliant build ✓ (See csp branch)
• CommonJS-based build setup ✓
  • Browserify + Vueify ✓
  • Webpack + vue-loader ✓
    • Scoped CSS (WIP)
• Server-side rendering
• Starter Kit

Plugins

Please discuss plugin specific topics in each plugin's respective repo. The general philosophy for these plugins is to be light, self-contained, and most importantly avoid reinventing the wheel. Build on top of solid low level solutions and mostly just make them Vue-friendly.

• vue-touch ✓
• vue-resource ✓
• vue-router ✓ (WIP)
• vue-validator ✓

Community

• Calling for user-contributed examples for tutorials!
• Open for blog post submissions once the blog is set up

[bpierre]

Awesome. Another vue-router option: tildeio/router.js, which looks nice to build things on top of it.

[yyx990803]

Thanks for the suggestion, but I feel tilde.io's implementation is too heavy (it's about 2/3 the size of Vue itself) and I don't want to enforce promises on users.

[bpierre]

Indeed! Just for the sake of completeness, router.js is based itself on https://github.com/tildeio/route-recognizer, which is more lightweight.

[yyx990803]

Ah nice! That looks like a valid choice.

[mitel]

https://github.com/tkambler/edison.js/

[duckbox]

Completely random. Would it be beneficial on having a server-side compiler to render out the relative vuejs view on initial load ( First Time speed, SEO etc ), then on this sceanario, vue.js would be able to read the rendered markup to establish state etc ( or an accompanied Object rendered out as bootstrap )

Its something I always wanted Angular to establish. Fully possible with the likes of Backbone/Handlebars.

[yyx990803]

This is something I've been thinking about, currently only React does that because it has virtual DOM. I will probably mess with jsdom to see how big an effort this would be, but it will be low priority unless someone wants to work on it.

[duckbox]

I would not mind having a look in the future. Something like that ( working to a degree ) would be awesome.

[bjornlll]

Currently components/directives/filters are registered in a global context where it is accessible to anyone, or a local context accessible within the scope of the current Vue instance. My question is: How can I bring expose re-usable assets without cluttering the global namespace?

An example to illustrate my point:

<!-- src="common-js-module-path" as="directive|filter|component prefix" -->
<v-import src="ui.viz.graph" as="graph" />

<!-- Later on -->
<div v-component="graph-linechart" />
<div v-component="graph-piechart" />

FYI - I just started reading about Vue 20 mins ago. It shows great potential. If this is already possible, but I happened to miss out on how it's done, then please disregard this post.

Thanks for all the great work.

[yyx990803]

@bjornlll when I'm using Vue with a module system, e.g. Component or Browserify, all these assets can simply be a module of its own that can be required when needed. In general Vue tries to avoid imposing rules on how the user organize his/her code - somehow I feel that asset import functionality is beyond the scope of Vue.

[bjornlll]

@yyx990803: Thanks for replying. Good point.

It is not as much about importing as it is about name-spacing the access of a particular component.

In my own context, I would be using Vue together with RequireJS. I've seen how vue integrates with CommonJS/AMD loaders to source assets from where the require() call points to, but I don't see how I can avoid Vue registering them in a globally accessible context? The point of the import call would be to scope down the accessibility of the imported component within the template scope that it is in. That being said, an "import"-call might not be the solution, it was just an example to highlight my point.

I am still wondering: How can I scope down access to a registered component so that it's only accessible within the templates of my choosing?

I will read up more on the docs / source

[yyx990803]

@bjornlll http://vuejs.org/guide/composition.html#Encapsulating_Private_Assets

[bjornlll]

@yyx990803 Thanks. I could accomplish it using

function include(privateDirectives, module1, module2, ...) {
  // requires and patches in modules to 'privateDirectives'
}

var MyComponent = Vue.extend({
    directives: include({}, 'ui.viz.graph', 'ui.listable.grid'),
    filters: {
        // ...
    },
    components: {
        // ...
    },
    transitions: {
        // ...
    },
    partials: {
        // ...
    }
})

[yyx990803]

Edited goals for v0.10 to include preparations for adopting future specs.

[tiye]

Typo in plguin's

Please discuss plugin specific topics in each plguin's own repo.

And what's the address of Vue's community?

[yyx990803]

@jiyinyiyong thanks, fixed. Currently GitHub is the community, essentially. There's also an IRC channel on freenode (#vuejs) although I'm not always active there.

[thelinuxlich]

Another very lightweight routing lib:

https://github.com/olav/dispatch.js?source=cc

[marfalkov]

I'm using this one with vue: https://github.com/paulmillr/exoskeleton/blob/master/lib/router.js

[kaiinui]

Awesome work! Vue.js is the best for me. Very intuitive, compact, no-jquery, and perf consideration. (good for mobile!)

Talking about vue-validate, I think validation rules are better to be written in model. I feel something strange to write them in specific view.

(Just an idea syntax)

var someThing = {
  ..
  validate : {
    attr1: "presence",
    attr2: "presence email",
    attr3: "someFunc",
    ..
    someFunc : function(value){..}
  },
  ..
};

And how is providing vue-scope to do like v-repeat="things | someScope"?

[yyx990803]

@kaiinui cool, I like the validation idea. The syntax for intuitive validation is still open to suggestions and this looks like a good option. I'm not sure what your vue-scope example is for though.

[kaiinui]

@yyx990803 Currently, when I want to filter data, the code is like

<li v-repeat="things" v-if="methodToFilter(this)">

and defining methods in created hook (or somewhere)

created: function(){
  this.filters = {
    fooFilter: function(thing){},
    barFilter: function(thing){},
    ..
  }
}

It is not intuitive way to filter data.(and not normalized) I think Vue should provide the normalized way. Filtering data is enough basic.

It's great if I can do like,

<li v-repeat="things | somescope">

And scopes are written in model.scopes. Not somewhere.

This syntax is scope. (| is an idea from duality to filter.)

[yyx990803]

@kaiinui in fact you can pipe a repeated Array through a filter if you want to.

Example:

function fooFilter (thing){}
function barFilter (thing){}
var currentFilter = fooFilter

// in your VM's options:
filters: {
  thingFilter: function (things) {
    return things.filter(currentFilter)
  }
}

<li v-repeat="things | thingFilter">

The only thing to note is when you change currentFilter, you need to force an update with the new filter because the external filter cannot be tracked by Vue.

currentFilter = barFilter
// force an update with the new filter
vm.things = vm.things

[ErikAndreas]

Continuing on @duckbox's path, any status/plans on being "isomorphic", i.e support rendering on both client and server (node.js)? Ractive, for example, is listed by express.js as an alternative template engine.

Context: progressive enhancement, pjax, seo friendliness/ease, twitter remake (content first), dust (linkedin) etc.

[yyx990803]

@ErikAndreas see #114 . I don't think it's an option at the moment. The very fact that Vue.js uses DOM-based templating makes it DOM dependent (similar to Angular and Knockout). Ractive and React both have their own implementation of a simulated DOM and that's why they are isomorphic, but heavier.

[rdsubhas]

Hi! Any plans to support variable naming when repeating? e.g.

<div v-repeat="items as item">
  <span>{{ item.discount }}</span>
</div>

I have a shopping cart with items. The cart itself has discount. Some individual items may have a discount, and some might not, but unfortunately it silently falls back to the parent and shows wrong discounts! When I say discount inside the repeat, I want to be absolutely sure that it doesn't fall back to the parent, and it would be very nice if I can intentionally avoid the parent fallback... And also sometimes looks good because with more and more repeaters, the namespace gets polluted quite a lot...

Can I use this as a starting point to contribute back to Vue (if the syntax sounds fine)?

[ghost]

Here's a fiddle illustrating @rdsubhas problem. The quick solution is to explicitly define a discount of 0 on the list items.

http://jsfiddle.net/N4JJJ/

[yyx990803]

@rdsubhas thanks for the suggestion! I'd like to keep the syntax for all directives consistent, so here's what I added in cea54de :

<div v-repeat="item : items">
    <span>{{ item.discount }}</span>
</div>

Note this basically wraps the repeated data, so when you are working with a repeated child VM you need to access its bound data as this.item instead of this.

[rdsubhas]

@yyx990803 that looks perfect! and yes, inside the repeated child VM as well, accessing it as this.item solves the namespacing issues in both view & model...

[paglias]

@yyx990803 great work, really, I'm loving this framework.

Seeing @kaiinui proposal for validation rules I'm wondering wheter there should be a more clearer separation of the model data.

For example:

var ViewModel = new Vue({
    data: {
        name: 'Bob',
        message: 'Hello Vue.js!',
        editing: false
    }
})

I feel like data.editing should be separate from the real model (name and message).

Do I have a wrong approach or maybe this is more related to vue-resource?

[yyx990803]

@paglias the data option holds the entire ViewModel's state, so it is something similar to Angular's $scope. If you have something that's strictly a "model" then it's best to nest it.

[azamat-sharapov]

@dominiquedutra Actually the guy who created Slack channel called users of Gitter channel, through gitter itself, so he knows about it (and I think he knew before making that Slack channel). Not sure what he didn't like about gitter, it has much more users and it's growing everyday :) Gitter is meant to be for open source project hosted on github. It even has Activity sidebar which shows activity of repo in real time.

Also, if you look at README of main repo, you will see Questions section telling you use Gitter for more than 5 month already.

If you are on laracasts, maybe comment under vuejs videos about gitter channel? I already did so, in first lesson (and even before vuejs videos).

[dominiquedutra]

@azamat-sharapov Thanks. Just glad to know there is a place to chat.

I must admit I really didnt even glance at the README. Just used a CDN for vue.js and started coding. I am still going trough the docs 👍

[fergaldoyle]

Great looking project you have here.

Would you consider 0.12 ready for production? I'm planning on using this in a large application framework which will evolve over time but will need to always maintain backward compatibility.

Would you consider the API final? As you release new versions, would maintain backward compatibility of deprecated features or remove them completely?

[yyx990803]

@fergaldoyle 0.12 is intended to be the last point release before 1.0, and yes, I think it is suitable for production now.

[Pandahisham]

just saw the angular 2 docs , i thinks their implementation of () for model methods , [] for property and {} for interpolation is quite pleasing , (just laughed seeing how angular 2 dumping gibberishes to become something simillar to vue. ) is there any thoughts on implementing such syntax ?

[yyx990803]

@Pandahisham I personally don't really like angular 2's binding syntax, they don't struck me as being very intuitive, and I'm not sure if they provide any meaningful advantage over the traditional directive syntax (or, at least not enough to warrant a breaking change for Vue).

[Pandahisham]

thanks , i am more than happy with the current syntax

[FWeinb]

Will vue be merged into the vuejs organization once it hits 1.0? It is a little confusing to have it here.

[yyx990803]

@FWeinb I've been thinking about it for a while, but there's a bunch of logistics to be sorted out. Moving after 1.0 sounds like a good plan.

[yolio2003]

look forward to Server-side rendering !!!

[niallobrien]

I'd love to server-side rendering too. :)

[karevn]

Thumbs up for server-side rendering, too!

[yyx990803]

Moving this to the wiki.