gmac / backbone.epoxy

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

Expose modelMap #146

Open sebamarynissen opened 6 years ago

sebamarynissen commented 6 years ago

When a model has computed properties, it's only possible to specify dependencies that are attributes to that model. However, I have a case where it would be useful to do something like this:

var Model = Epoxy.Model.extend({
  "computeds": {
    "b": {
      "deps": ['model:a'],
      get: function(a) {
        return 2*a;
      }
    }
  }
});
var sub = new Epoxy.Model({
  "a": 1
});
var main = new Model({
  "model": sub
});

// true
main.get('b') === 2;

It can be more or less compared to the concept of binding sources with Views.

I don't think that this should be integrated into Epoxy itself, but I found out that it's easy to implement this myself if the modelMap that Epoxy uses to define dependencies for computed properties was exposed. Right now this is a private variable in the Epoxy library which can't be accessed from outside the library. If it was possible to access it - for example as Epoxy.modelMap - I could implement the functionality described above by overriding the get method as

var Model = Epoxy.Model.extend({
  get: function(attr) {
    var match;
    // Detect model.get('submodel:attr');
    if (match = attr.match(/([^:]*):(.*)/)) {
      var sub = this.get(match[1]);
      return sub.get(match[2]);
    }
    Epoxy.modelMap && Epoxy.modelMap.push(['change'+attr, this]);
    if (this.hasComputed(attr)) {
      return this.c()[ attr ].get();
    }
    return Epoxy.Model.prototype.get.apply(this, arguments);
  }
});

I fully understand why in principle the modelMap should be a private variable - you don't want other people to mess with how the library works internally - but I think that it can be useful to have the opportunity to access it if one wants to extend Epoxy.

disruptek commented 6 years ago

Is there a reason you didn't simply use so-called "raw values"?

sebamarynissen commented 6 years ago

@disruptek The reason is that I have a lot of computed properties, so I would like to "group" them within separate models where the models containing the "raw values" serve as dependencies, rather than the "raw values" itself.

disruptek commented 6 years ago

I understand the schema; I just would have hacked it together more explicitly using the mechanics we already have. That said, this seems like a pretty harmless change that opens up potential for this and other (magical) use cases. :+1: