About 'next' branch

[dyu]

The changes in https://github.com/yyx990803/vue/blob/next/changes.md are definitely in the right direction. I've a question regarding Object.observe (now supported in chrome 36 beta). Would there be a possibility to use that underneath if it exists then fallback to the current approach? It seems (reading from blog posts) angular 2.0 is headed in that direction.

[yyx990803]

Yes, it is totally possible. The underlying observer module has been rewritten with a much cleaner interface, and it is trivial to swap the implementation inside. But the next branch is still aimed at full compatibility down to IE9, so upcoming features like Object.observe, custom elements etc. are of lower priority at the moment and will most likely ship as plugins/extensions.

[dyu]

The next branch will still be compatible with IE9 because we're simply falling back to the current approach if Object.observe is not available. Maybe I'm missing something here? If the changes are not huge, it might be good to include it already.
Given the vuejs is perf-optimized, I'm sure with Object.observe it will only boost it more.

[yyx990803]

The main reason is that Object.observe works in Chrome only, and that will probably be the case for quite some time (given it's part of ES7 not even ES6). Bringing in Object.observe early means I have to spend a considerable chunk of time on tweaking Vue specifically for Chrome. Also, Angular benefits more from utilizing it because dirty checking is slow. But in Vue's case, the perf gain from Object.observe could be marginal. On the other hand, the next branch doesn't aim to integrate all the future-facing features at once, since it's positioned as a new starting point. There are many other more imminent issues that need to be addressed in 0.11/next at the moment, that's why Object.observe is low priority on the list.

[dyu]

Alright. I guess maybe the changes needed are not that minimal/pluggable.
Thanks for the replies. "I have to spend a considerable chunk of time on tweaking Vue specifically for Chrome" Indeed. But then you have these other platforms like node-webkit and atom-shell on the desktop where chromium is the only option.

[ayamflow]

Using this thread for some feedbacks/propositions for vue next:

• Differenciating DOM-related lifecycle hooks I feel that the ready hook should be called when the component DOM is compiled AND attached. So the event flow could be something like compiled -> attached -> ready, with the attached hook always called rather than called by some directive (v-if and stuff). Using the same system than ready, so a parent's vm compiled is only called when all of its childs are compiled. Thoughts ?
• Like Angular, make the transition system external (plugin), by listening on transition hooks. Make it more modular, and allow us to listen to these events to roll our own system for websites with complex transitions.
• Directives: a way to pass multiple parameters, perhaps with some kind of data- attributes? I think some github issues were related to that.
• $broadcast: especially on mobile, $broadcast can take a while to proceed. Similarly to what Angular introduced in v1.2.16 (cf this thread), Angular's $broadcast only emit the event to the $scopes actually listening to it. cc @rayfranco

[yyx990803]

@ayamflow Thanks for the feedback! Very appreciated.

• I agree that current hooks are not well defined enough for their use cases, I'll consider your suggestions :)
• Vue's transition system is really minimal (less than 1kb gzipped) and if you think about the JavaScript transition functions, they are essentially custom transition hooks. But yes, I will think about expanding the available hooks to enable users to really write their own transition systems.
• I've thought about this and there's a very simple solution: just add your own attribute flags. e.g. within v-model, check if the element has the lazy attribute to determine if the binding should be lazy or not.
• Yes, I checked out the way angular implemented the optimization and it is indeed something Vue can learn from.

[ayamflow]

Great! I'll definitely try the v-model approach :)

The need for custom transitions hooks comes from the need to have precise control over the timing of these animations. Sometimes I want to play the transitionIn before the transitionOut, for instance. For now we wrote at work a custom v-view handling these use cases but it's not very maintainable (need to update it on every v-view update). The modular approach is not a necessity but the ability to listening to hooks is.

I'll happily contribute with more suggestions as I dig deeper into Vue. We are building at work a lightweight framework on top of Vue (router, transitions timing, preload...) so we sometime need to hack into the core, hence the suggestions!

[yyx990803]

@ayamflow yeah these suggestions are super useful because they come from real-world usage that I haven't run into myself. Glad you guys are digging into the core :)

[hansent]

have you considered using ES6 style classes for vue.next?

[yyx990803]

Using ES6 adds an extra transpile step to the build process and effort to convert every file manually. I'd rather focus on adding features and getting 0.11 out of the door for now. When 0.11 is out and stable I will consider ES6-fying the codebase.

[dyu]

Btw, what triggered the style change? (The var statement per line and the two-space indent) It looks like you're now using google's js style guide?

[yyx990803]

@dyu it's mostly subjective preference change. 4-spaces sometimes makes the indentations too wide to visually scan, and single var looks awkward with 2-spaces indentation (also multi var eliminates the need to remember commas for every declaration).

If anything, the style is very close to what Segment is using in their codebase, except I don't write semicolons: https://github.com/segmentio

[dyu]

@yyx990803 I see.
I actually preferred 4-spaces (most js libs are 2-space indent though).

Btw, what do you think about dynamic partials? (with transclusion) Here's the diff: https://github.com/dyu/vue/compare/yyx990803:next...xnext

Its backwards compatible to regular static partials. My usecase for this is for generating ui's at runtime based on the params (schema) passed to the dynamic partial

Here's a small example on how it can be used.

  <div>[[> headerfooter:{wclass:'content', header_key:'hello'}]]</div>
  <p>========</p>
  <div class="block" v-partial="headerfooter:{wclass:'content', header_key:'hello'}">
    <div>
      <b>I'm injected in-between the header and footer.</b>
    </div>
    <div>another</div>
  </div>

Vue.config.delimiters = ['[[', ']]']

Vue.partial('headerfooter', {
  main: function(param) {
    var data = this.vm.$data
    var buf = ''
    buf += '<div class="header">header'
    if (param.header_key) buf += ' [[*' + param.header_key + ']]'
    buf += '</div>'
    buf += '<div class="' + (param.wclass || data.wclass) + '">'
    buf += '<content>fallback</content>'
    buf += '</div>'
    buf += '<div class="footer">footer [[* hello]]</div>'
    return buf
  }
})

new Vue({
  el: document.body, 
  data: {
    hello: 'world'
  }
})

[yyx990803]

The dynamic partial does have its use cases, however I feel the way params work is a bit too complicated. Also there are two issues with your implementation:

1. When anything in the params change the whole partial is recompiled;
2. When the previous partial is torn down there's a bit of cleanup to do (teardown the directives etc.) which I still need to implement (like a partial de-compile).

In general, the reason I've kept partials static so far is because I want to encourage thinking in components instead of stitching together templates. When you have a component with paramAttributes, it could be something like:

<header-footer wclass="content" header-key="{{hello}}">
</header-footer>

Which is more idiomatic imo.

[dyu]

On Sun, Oct 19, 2014 at 12:10 AM, Evan You notifications@github.com wrote:

The dynamic partial does have its use cases, however I feel the way params work is a bit too complicated. Also there are two issues with your implementation:

1. When anything in the params change the whole partial is recompiled;

Well yes. Though with the way I use it, I only pass a schema object, which does not change.

1. When the previous partial is torn down there's a bit of cleanup to do (teardown the directives etc.) which I still need to implement (like a partial de-compile).

Ok. Any idea how I should achieve that in my fork?

In general, the reason I've kept partials static so far is because I want to encourage thinking in components instead of stitching together templates.

Components are also static btw. They cannot generate a different ui structure based on the argument. The contents (templates) inside the dynamic partial will be the one that contains components (different structure/components based on the param)

When you have a component with paramAttributes, it could be something like:

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

When the cat is away, the mouse is alone.

• David Yu

[yyx990803]

Components can populate arbitrary HTML for its $el in the beforeCompile hook (essentially what you are doing in the main function of a dynamic partial).

The de-compile part is a bit tricky, but in essence what we need to do is keep track of all the directive instances created during the compilation, and call _teardown() on them when the partial is replaced.

[dyu]

On Sun, Oct 19, 2014 at 12:39 AM, Evan You notifications@github.com wrote:

Components can populate arbitrary HTML for its $el in the beforeCompile hook (essentially what you are doing in the main function of a dynamic partial).

Cool. So I'm guessing additional teardown logic is also needed when done this way? The other thing about the dynamic partial is that it doesn't need a new scope unlike components. It's job is to embed the components (dynamically) and not be a component itself.

The de-compile part is a bit tricky, but in essence what we need to do is keep track of all the directive instances created during the compilation, and call _teardown() on them.

I see. Since a regular static partial can embed directives, so I guess there is no teardown for those as well?

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

When the cat is away, the mouse is alone.

• David Yu

[yyx990803]

Ah, actually doing so in beforeCompile will be executed only once, so it's a bit different from dynamic partials. And you are right about the scope. I do agree that a dynamic partial in the sense of v-partial="{{partialId}}" would be useful, but I feel partials with params (like the one in your example) makes the logic quite hard to reason about.

Re static partial, yes at the moment there's no teardown logic for it.

[dyu]

On Sun, Oct 19, 2014 at 1:02 AM, Evan You notifications@github.com wrote:

Ah, actually doing so in beforeCompile will be executed only once, so it's a bit different from dynamic partials. And you are right about the scope. I do agree that a dynamic partial in the sense of v-partial="{{partialId}}" would be useful, but I feel partials with params (like the one in your example) makes the logic quite hard to reason about.

Re static partial, yes at the moment there's no teardown logic for it.

Thanks for the replies! As usual.

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

When the cat is away, the mouse is alone.

• David Yu

[dyu]

On Sun, Oct 19, 2014 at 1:02 AM, Evan You notifications@github.com wrote:

Ah, actually doing so in beforeCompile will be executed only once, so it's a bit different from dynamic partials. And you are right about the scope. I do agree that a dynamic partial in the sense of v-partial="{{partialId}}"

My code is actually something like: v-partial="foo:pojo.$schema" data: { pojo: { $schema: { ... field definitions go here } } }

would be useful, but I feel partials with params (like the one in your example) makes the logic quite hard to reason about.

Re static partial, yes at the moment there's no teardown logic for it.

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

When the cat is away, the mouse is alone.

• David Yu