2.x

[Roman Shtylman]

Issues/features for reactive 2.x next branch

• {{ }} instead of { } #125
• document bindings stuff better (maybe revisit some apis)
• drop data-text (I think interpolation handles any builtin case and this just adds confusion)
• arguments to event handlers?
• update examples
• make sure component works

[Luke Vivier]

@defunctzombie I'm happy to step up to maintain component.json going forward

[Roman Shtylman]

@lvivier awesome. I will remove that item and replace it with "make sure component works"

[Jon Eisen]

Would be nice to be able to have plugins that add bindings. Right now that would be done with .bind() which doesn't get contexts of each or other bindings that create sub-views. The only way to do that now is to wrap the reactive object.

[Vincent Weevers]

@yanatan16 agreed. Would be nice for 2.x to either:

• Reinstate .use and add explicit render step: reactive().use(plugin).render()
• Have something like a plugins option

There is another way though, for current 1.x branch:

reactive(template, model, {
  bindings: plugin()
})

i.e. the plugin wraps bindings.

[Roman Shtylman]

It use to be possible to have plugins that added bindings but I wasn't happy with this. I liked having control over the name of the binding and felt that the current approach of listing the bindings in an object with key -> value while more cumbersome, also allows you to easily look at the js code for a template and know where custom keywords are coming from. If you have plugins that add the binding then you might have to research all the various plugins to see what words they use for bindings to identify the plugin of interest.

I am not against this but want to see what some of the use cases look like and whether having plugins add bindings actually leads to easier to maintain code or not.

I see the "wrapping the reactive object" approach as actually a benefit where you are creating a custom "View" base setup for your project which you might want to do anyway to avoid having to type the same base plugins over and over.

[Vincent Weevers]

It'd be useful for plugins that add multiple bindings (especially if those are linked in some way), override built-ins, bundle an adapter and a binding, or do something else entirely (I don't think this discussion should be limited to bindings).

reactive(tpl, model, {
  plugins: [touch, stream, markdown, removeIf]
})

// Or with a custom name:
reactive(tpl, model, {
  plugins: [touch, stream, removeIf],
  bindings: {
    md: markdown.binding
  }
})

Instead of:

var constructor = touch(reactive)

constructor(tpl, model, {
  bindings: {
    md: markdown,
    stream: stream,
    'remove-if': removeIf
  }
})

// Or without wrapping
reactive(tpl, model, {
  bindings: {
    md: markdown,
    stream: stream,
    'remove-if': removeIf,
    'on-tap': touch.tap,
    'on-swipe': touch.swipe,
    etc
  }
})

The benefits of the first:

• Easier to read. Immediately see which plugins are used.
  And if plugin names reflect binding names (most will),
  it's not difficult to recognize the origin/meaning of custom
  keywords in the template.
• Easier to maintain (no extra step)
• A standard mechanism to include a plugin avoids confusion.
  "Should i wrap the reactive constructor? Or an instance? Or the bindings object?"
• As shown in the example, a user still has control over the
  binding name. You can get both ease of use and control.
• Furthermore, assuming a plugin is called by the reactive constructor,
  it can do anything it wants. Set options, add an adapter, create a view (delegate), extend the view, whatever. Anchors away.

[Florent Cailhol]

It would be great to introduce tag binding or composite views. I known that ripple.js does it great but it does not work well in browserify environment.

Another great improvement would be the ability generate a view constructor, once again like ripple.

[Roman Shtylman]

No longer maintaining