component / reactive

Tiny reactive template engine
383 stars 48 forks source link

2.x #136

Closed defunctzombie closed 6 years ago

defunctzombie commented 10 years ago

Issues/features for reactive 2.x next branch

lvivier commented 10 years ago

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

defunctzombie commented 10 years ago

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

yanatan16 commented 10 years ago

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.

vweevers commented 10 years ago

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

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

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

i.e. the plugin wraps bindings.

defunctzombie commented 10 years ago

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.

vweevers commented 10 years ago

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:

ooflorent commented 10 years ago

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.

defunctzombie commented 6 years ago

No longer maintaining