API changes for easier lazy loading

[PaulUithol]

I'd like to make some API changes to accommodate more transparent lazy loading. There's more than one option here, so feedback would be appreciated.

What I'm planning to do:

1. Change fetchRelated to only return a single promise, which resolves when all requests are done (or a single one fails..)
2. Create a Model.lookup( attr ) method which acts like Model.get, but always return a promise which resolves with the attribute's value as its first argument. If the contents of the attribute/relation are found locally, it would resolve immediately; if not, it would resolve after the contents of the attribute/relation have been fetched.

Any thoughts about this?

[philfreo]

I'd give it a more clear name than lookup to indicate that it's async. More ideas: Model#fetchAttr or Model#asyncGet

[philfreo]

I'd give it a more clear name than lookup to indicate that it's async. More ideas: Model#fetchAttr or Model#asyncGet

[PaulUithol]

We could also overload Model.get; give it an extra fetch or async option/parameter. That would be pretty nice as well (at least, as long as Backbone itself doesn't add something similar-but-different).

Also: do we still need fetchRelated as a separate method?

[PaulUithol]

We could also overload Model.get; give it an extra fetch or async option/parameter. That would be pretty nice as well (at least, as long as Backbone itself doesn't add something similar-but-different).

Also: do we still need fetchRelated as a separate method?

[PaulUithol]

After sleeping on it for a night, I'm definitely leaning towards a separate method; how's getAsync (like your suggestion, just a different word order)? A quick search seems to show more libs are using that convention.

I also think this function could straight up replace fetchRelated (maybe alias it for a while), now that we're messing with its signature anyway.

[PaulUithol]

After sleeping on it for a night, I'm definitely leaning towards a separate method; how's getAsync (like your suggestion, just a different word order)? A quick search seems to show more libs are using that convention.

I also think this function could straight up replace fetchRelated (maybe alias it for a while), now that we're messing with its signature anyway.

[philfreo]

sounds good, +1 for not complicating Model#get

[philfreo]

sounds good, +1 for not complicating Model#get