Fix the plugin system

[yanatan16]

Currently the plugin system and the .bind() method are kaput because they can't alter the functionality of dommit wholesale. After construction of the Dommit object, the view has been rendered. Adding a new binding (a common plugin practice) has no effect. The only way to do this is to wrap the dommit() method. Furthermore, subviews created by each and other custom bindings have no way of reproducing the same object, which can cause many bugs.

I suggest creating a plugin system that will allow arbitrary bindings before rendering of the view. This could be done like so (a suggestion only):

var view = dommit(state, options).use(onChangePlugin).render('<div on-change="yoyoes"></div>')

[defunctzombie]

Interesting approach with creating a view-ish object that you can then given a template to render. Would you want to pass the model in during the view-ish creation or during the render call?

What do you call the instance that dommit(state, options) returns before you have rendered anything? That would be some sort of "pre view" type object that you would reuse? Or would you not re-use it because it has the model and delegates already bound?

[yanatan16]

One option is to have it all return "views", but the view won't have an .el attribute until you call .render(). The state could be passed in either spot, but I like the current way I guess.

Another thing we do is mirror values between views. Something like this happens a lot:

var abc = anotherView.get('abc')
  , view = dommit(template, {abc: abc})
anotherView.sub('abc', function (val) { view.set('abc', val) })

I'd like to be able to reduce this so that we only have to state the mirroring once (but not have to update the DOM, which would happen if we did this in 1.x):

var view = dommit({})
mirrorValue(anotherView, view, 'abc')
view.render(template)

[yanatan16]

@defunctzombie can you push your next branch so I can work off of that for this?

[yanatan16]

Another thing: since .render().bind() won't work correctly in many cases (hence why it was deprecated in 1.x), lets remove the ability to call .bind() after render. If you call it before, it just acts like you think it should, .bindings[name] = fn, otherwise it throws.

[yanatan16]

This system nicely reduces the bindings({ bind: /* ... */ }) hack to this.use(bindings)

[defunctzombie]

The next branch only had the {{ }} change which is now in master.

For sharing values between views I would recommend using a a model layer
like bamboo or an adapter.

The flip side is sharing a view between different models so one could make
arguments about binding to one or the other first.
On Sep 26, 2014 11:56 AM, "Jon Eisen" [email protected] wrote:

@defunctzombie https://github.com/defunctzombie can you push your next
branch so I can work off of that for this?

—
Reply to this email directly or view it on GitHub
#1 (comment).

[defunctzombie]

I agree that calling bind after render won't work. I think the distinction
between a view that has not yet been rendered versus one that has could be
interesting.

Also check out backbone views extend for some ideas.
On Sep 26, 2014 12:01 PM, "Jon Eisen" [email protected] wrote:

Another thing: since .render().bind() won't work correctly in many cases
(hence why it was deprecated in 1.x), lets remove the ability to call
.bind() after render. If you call it before, it just acts like you think
it should, .bindings[name] = fn, otherwise it throws.

—
Reply to this email directly or view it on GitHub
#1 (comment).

[yanatan16]

I pushed some code that adds .render() and makes the .use(plugin) system useful again for adding bindings. I made view.subview() a thing so that custom bindings can use that to exactly copy the view in question (or at least its bindings/adapter constructor), much like the each binding does now. I fixed all the tests and added some new ones (plugin.js).