IE8 still has significant market share

[ericelliott]

Any chance of adding support?

[anthonyshort]

I'm actually not using anything at the moment that isn't supported in IE8. You might need a couple of shims, but http://polyfill.io should have you covered.

I'll probably add a plugin for adding getters and setters on the model, so that'll be optional and won't support IE8.

Glad to see you're checking out the project and I even haven't finished it yet :) Pretty website and docs coming soon

[queckezz]

I think we shouldn't add getters and setters as a seperate plugin. Instead, I think we should have them in the core. In the readme you strictly defined ie9+ as a feature and thats a good thing. Even Vue.js doesn't support ie8 and below so that they can take advantage of getters and setters. Theres no point I can think of, for not adding support for it :)

.get and .set methods can get really messy when you get and set multiple properties.

[anthonyshort]

I have been pretty tempted to just copy the way Vue does getters/setters and use $-prefixed variables for private methods, then we could do:

person.name = 'foo';
person.$change('name', fn);

Or I could just go through the model and not make the functionality part of the view.

person.data.name = 'foo';
person.change('name', fn);

The second approach would be nicer technically, but the first one is a really, really nice API.

[anthonyshort]

Or I could flip it and prefix data properties:

person.$name = 'foo';
person.change('name', fn);

[ericelliott]

I'm confused. The whole point of a setter is that it can be the public API that triggers your change events, right? So why make .name private, in that case? IMO, the only reason to make .name private would be to force users to use the .set() API to make changes to it so that you know when to call the .change() handlers.

And why would you hide .change()? You don't want to expose it so that users can hook onto changes for things other than view updates?

Also, if you're going to do data privacy, why not go all the way and hide private stuff inside a closure so it can't be accessed from the outside at all?

[anthonyshort]

Ah no, sorry, I didn't mean I was going to make anything private. Private was the wrong word to use.

I meant that I would want to avoid clashes between the model getters/setters (which could have potentially any name) and view properties.

[queckezz]

If we would go with adding properties to the .data attribute we could hide it in most cases:

View.on('created', function () {
  this.prop = true; // model.data.prop = true
});

And from a consumer's perspective you would add properties like normal:

var view = new View()
view.data.prop = false;

If you would go down this route, we should also maybe think about an alternative name for data like props or something :p

[anthonyshort]

I've updated the way state works now. It works like react, there are props and state. State is for internal properties and props are passed in.

var view = new View({
  user: userModel
});
view.props.user // userModel

view.set('foo', 'bar');
view.state.get('foo') === 'bar'

You can't add or remove props once they've been set, but you can change the value itself. This will allow for passing models down the view-chain.

The accessors for props are optional. You can do this.props.get('user') too.