Closed markerikson closed 9 years ago
I'll need to think about this one. The "raw value" feature of computeds is more of an edge case than a core feature. In general, computed attributes should be functions that don't really define their own value; they assemble one from other model values. When accepting presets within an attributes hash, it's not obvious as to whats supposed to be a computed attribute and what's a normal attribute. I'm going to leave this one for now and consider if its something that should have exceptions made for.
Understandable. In my case, I've been using computed raw values effectively as viewmodel attributes. We're not doing any syncing back to a server, just pulling in data and using it clientside. I define my models that will contain the server data, and add the view-related computed attributes.
This is also my first Backbone app, so it's entirely possible there's a better way to do things that I haven't seen yet.
Welcome to Camp Backbone. It's Better Here (tm). ;-)
We're not going down this road. In general, computeds are better used as getters than as setters... the setter feature is offered as a nicety, but isn't all that practical as an integral data manager. Initialize with real model fields, then leverage computeds as a nicety.
I'm looking to do something like this:
where someComputedAttribute is a "raw value" computed attribute. However, if I understand the Epoxy.Model source correctly, this does not currently work. Epoxy.Model calls initComputeds() after the initial Model construction process is complete. The Model construction calls set(), but that's before initComputeds().
It would be nice if Epoxy.Model would support setting computed values through the constructor, the same as normal attributes.