Open stalniy opened 8 years ago
@stalniy Can you describe what you mean? Rivets wraps observed properties in getters and setters. If you have a custom getter on a obj property that getter will be overwritten.
@Duder-onomy according to this it's not https://github.com/mikeric/rivets/blob/master/src/adapter.coffee#L65
Oh, Dang. That is interesting.
So, it seems like if you define a custom getter or setter on property than the binding does not work at all.
Should Rivets wrap customer getters and setters. This could be a good use case of the decorator pattern. My question is, if we wrap any custom getters and setters, what order will they fire? My gut tells me that the custom one should always fire last.
The getter seems pretty easy to decorate: http://jsfiddle.net/Vornagreg/zps5ksqy/ The setter will probably be harder.
Isn't this precisely a job for a custom adapter? Would it be enough to say in the docs "the included "."
adapter uses getters and setters, if you are using your own getters and setters then you'll need to roll your own adapter"?
@Leeds-eBooks this is ECMA5 getters/setters which looks the same as object properties (which are supported from IE9, same as rivets default adapter by the way). So, wouldn't it be logical to add support for existing .
adapter to observe almost the same kind of stuff instead of pushing people to override/create own adapters?
The default adapter seems like it observes any object but in fact it doesn't. This can be disturbing and could cost time to devs. I also think the default adapter should observe getters. Or at least it should be explicitly explained in docs (or logs?).
Currently rivets doesn't support observing of custom getters for some reason.