gmac / backbone.epoxy

Declarative data binding and computed models for Backbone
http://epoxyjs.org
MIT License
615 stars 89 forks source link

Interface to add a computed to a view #5

Closed dspangen closed 11 years ago

dspangen commented 11 years ago

Epoxy provides a great way of adding computed values to models, but I find that sometimes (a lot of the time) I really want to add a computed to provide very view-specific information. For instance, calculating a set of classes to apply to an element, formatting a value for human display (a value that contains conditional formatting in particular), etc. These type of data shouldn't be living on a model, IMO.

I could always add a binding handler, but having to write some jQuery to add a formatted piece of text to the DOM doesn't feel right. A binding operator may be right, but as far as I can tell, there isn't a hook to add a custom one. Is there a plan to add something of the sort, or do you have any thoughts as to where one might go and add this?

gmac commented 11 years ago

Thanks for the feedback. Can you please provide an example implementation where you feel a custom binding handler is inappropriately limiting? I don't necessarily disagree with anything you said here, although there's always a fine line between what's appropriate for automation versus what is truly unique and requires a custom setup. Also be aware, the current edge branch includes a "template" binding for attaching data to an Underscore template renderer, so this may help with your situation.

As for custom binding operators – yes, they're coming. They've been a bit slower to set up due to their complexity being inappropriate for a public API. The current edge branch does include an API and support docs for adding operators globally, and this will probably be expanded down to the individual view level as well. The current edge branch should be going to master sometime in the next week or two.

gmac commented 11 years ago

Following up: the concept of "operators" is being officially reclassified as "filters". While operators were originally just imagined as boolean evaluation wrappers (not, all, any), I've also been recognizing their value as transformational wrappers for formatting view data without getting into DOM operations. And with a bit of refactoring, their usage has become simple enough to make them ready for primetime. Edge branch now includes a bindingFilters API for defining your own view-specific filter ops. These are still only one-way filters at the moment – I'm not yet convinced at the value (or reliability) of defining two-way filters on the view side. I'm certainly open to perspective on this point though.

dspangen commented 11 years ago

That's great--pretty close to what I was looking for, thanks, and, a lot more extensible than just computed values.

Two-way filters do seem a bit wrong, but I also haven't seen a use case yet that makes them seem useful :)