vuejs / vue Goto Github PK

options:

• seed-router as a separate module
• embedded in core to enable tighter integration with the ViewModel

• pros:
  • slightly smaller code size
  • slightly better performance (no resolving relative require paths on startup, everything is in the same closure)
• cons:
  • have to avoid naming collisions
  • have to duplicate emitter when used with component

Use CasperJS (see travis integration from ghost)

• simple directive
• template
• form elements
• expressions
• component encapsulation
• nested properties
• nested viewmodels
• repeated items
• repeated viewmodels
• sharing data between viewmodels
• todomvc

This should probably be a separate module / extension / plugin / whatever

use sd-id to be able to reference a child Seed from a parent Seed.

Example:

<div id="parent">
    <div sd-id="child" sd-viewmodel="abc"></div>
</div>

var parent = new Seed({ el: '#parent' })
// a node with `sd-viewmodel` and `sd-id` both present will
// have its corresponding VM instance registered under parent VM's "$" property
var child = parent.$.child

Rip out the default filters into a separate module. Basic case transforms can be done with CSS since we are IE9+; More complicated filters are better customized anyway.

General Thoughts

• Allow component encapsulation and easy reuse.
• Flexible while not being too confusing
• a defined VM constructor should not be able to use a different template for consistency. (i.e. when you new something, it should always look the same) If you want the same logic but a different template, you should extend it as a new VM constructor. Therefore, no more sd-template
• If you want to inline a template you should use sd-partial.
• add seed.vm('id', VM) so it can be used inline via sd-vm, id should be no longer an init option.
• add seed.partial('id', 'partial')

Options Spec for seed.ViewModel.extend

• el
  • if present
    • if string: querySelector
    • if node: use as is
  • if not
    • create per tagName
  • apply elProps/className etc
• template
  • if present
    • if starts with '#': getElementById
    • else: use as is
    • replace current el innerHTML
• id, className, attributes: stuff to add to el (same as Backbone)
• init: init function to call when instantiating
• props: stuff that will be put onto the constructor's prototype
• data: stuff that will be copied to each instance

Tentative

How can we allow access to nested component VMs in code, while allowing declarative compositing in markup?

• directives: hash of directives to register
• filters: hash of filter functions to register
• vms: hash of VM constructors to register
• partials: private partials that can be used in the template

References

Currently I'm torn on how the final API should look like. There are three main references: Angular, Backbone & Ractive.

Angular

Markup everything, define everything, bootstrap() once
Declarative

Backbone

Creates .el if not exist using options like tagName, properties, etc...

Ractive

Takes a string template, also allows inline by treating it as an ID if it starts with '#'

Basically a component can be distributed alone with an extended VM constructor and a template string. So globally there needs to be a method that registers these VMs to a unique id so they can be nested in other views.

e.g. <div sd-editbox></div>

Seed.directive('editbox', {
    bind: function () {
        // ...
    },
    unbind: function () {
        // ...
    }
})

When an object is observed by many anonymous expression bindings (>100) the new ViewModel instantiation gets increasingly slow. Currently has no idea why - but it has something to do with the exp parser / anon directive thing. Need to do more profiling.

simply a function to be called during vm.$destroy.

This should be a separate module.

• just providing an easier API to do validations.
• use vm.$watch to validate stuff and trigger things.
• or just provide a set of validation filters.
• consider: https://github.com/wrapp/validate.js

see TODO in src.

• api
  • class Vue
  • instantiation options
  • instance properties
  • instance methods
  • global methods
  • directives
  • filters
• guide
  • installation
  • getting started
  • displaying a list
  • listening for events
  • Directives in depth
  • Filters in depth
  • computed properties
  • handling forms
  • using transitions
  • composing viewmodels
  • app architecture

This should be a separate module.

• parse stuff on hash change / history push
• can build on top of an existing router component, e.g. page.js
• store parsed data somewhere
• ViewModels automatically observes $route if the router is present.

should just wrap existing hook

sd-transition comes in two flavors:

• CSS class toggle
• JavaScript functions
• tests

CSS class toggle

Use sd-transition-class. e.g:

<div class="test" sd-transition-class="fade">

.test {
    transition: opacity .5s linear;
}
.test.fade {
    opacity: 0;
}

<div class="test" sd-transition="fade">

Seed.transition('fade',  {
    enter: function (el, attach) {
        // ...
        attach()
    },
    leave: function (el, detach) {
       // ...
       detach()
    }
})

Potential XSS vulnerability

• api
• viewmodel
• directives
• filters
• events

RESTful sync for seed as a separate module

• sd-model
• lazy option

e.g. different types of <input>:

• radio
• checkbox
• text-based

and <select>

• break v-component into its own file
• v-component="component-name[:object-to-bind-as-model]"
• remove custom elements

Is contextual bindings really needed any more now that we have expression bindings?
It looks unused in current implementation.

• style design
• home redesign
• live examples

This is a far reach, God knows when will I get to these.

• seed-restful
• seed-tailbone
• seed-firebase

Instead of changing the global/default prefix, allow users to create namespaced directives with their own prefixes.

Should also remove these extra listeners in unbind()

should be able to include partial templates...

Like this:

<div sd-partial="#temp"></div>

Or like this:

{{>#temp}}

template should simply be a string. the VM constructor makes real nodes out of it and then cache it for future instantiation, because cloneNode() is faster than innerHTML. So - remove util.collectTemplates() and let the users handle where/how to store templates. This also allows better capsulation for component distribution.

e.g. {{ a.b + a.c }} doesn't catch any dependencies

Define a custom element!

Pass in a simple function:

Seed.element('tabs', function (el) {
  // ...
})

Seed.element('tabs', {
  tagName: 'ul',
  replace: true,
  template: '...',
  init: function () {
    // ...
  }
})

sd-pre

• change the exposed entity to Seed
• change sd-each to sd-repeat
• put all API methods on Seed
• rename data option to scope
• rename props option to proto
• properties that start with _ should also be ignored and used as a convention: $ is library properties, _ is user properties and non-prefixed properties are data.

This probably should be a separate module.

provide these methods for nested VMs to communicate with each other (Angular style): $on, $off, $broadcast, $emit

e.g.

ok ? yesMsg : noMsg

With the current deps tracking, because of the short-circuiting of the ternary expression, if ok is true then only yesMsg gets tracked and we will miss noMsg.

Solution

access everything with a var statement...

Currently over 20 tests fail in IE9.

Convenience methods for VMs created off-DOM; also applies transitions automatically.

• implementation
• unit test for batch.js
• fix functional tests

Pseudo code

• for each created binding, give it a uid;
• on each binding update
  • check its uid in the global update hash.
    • if not waiting for update
      • push itself to a global update stack
      • if a nextTick stack flush callback is not registered, register it;
    • set its uid to true in the global update hash.
• in the flush callback, update every binding in the queue.

This should indicate whether to replace the VM root node being compiled with the template. Only works if the template has only one node.

• Currently child objects nested under an observed object cannot be observed again... The proper way to do it is probably make EVERY object self-contained with an __observer__ and propagate the events up.
• This would make data objects completely decoupled from each other and allow a VM to simply observe its scope instead of copying stuff over.