Skip to content

Conversation

@sebamarynissen
Copy link

@sebamarynissen sebamarynissen commented Dec 4, 2017

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
Copy link
Contributor

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

@sebamarynissen
Copy link
Author

@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
Copy link
Contributor

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. 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants