[DOC release] Change misleading documentation for AdapterPopulatedRecordArray - #5620
Conversation
|
I'm about to force push to change the commit message to meet your standards. |
3795c00 to
1a56572
Compare
In my experimentation, I've discovered that though the promise returned from `store.query()` does have array-like methods on it, the actual `AdapterPopulatedRecordArray` is what the promise *resolves to*. For example, the `length` property of the object returned from `store.query` will always be `0`. The object which the promise resolves to will represent the actual length of the records that were queried.
The documentation for `store.query` states plainly that the AdapterPopulatedRecordArray is the *resolution* of the promise, but the documentation here misrepresented that.
For example, the original code actually would behave like this:
```javascript
// GET /users?isAdmin=true
var admins = store.query('user', { isAdmin: true });
admins.then(function() {
console.log(admins.get("length")); // Throws: "admins.get" is not a function
});
```
1a56572 to
f8c0983
Compare
|
And once more to remove things inside the commit message where I am speaking a little bit about things I don't know. I realize that when I read commit messages that are merged, I take them to be the actual truth. In my original commit message, I made a comment referring to Ember's ProxyObjects, but I am really not 100% sure how those work. And that comment is actually not pertinent to this change anyhow. |
|
I'm in favor of this documentation change; however, historically speaking |
2 participants
In my experimentation, I've discovered that though the promise returned from
store.query()does have array-like methods on it, the actualAdapterPopulatedRecordArrayis what the promise resolves to. The promise does not behave like a proxy (or what I think Ember Proxies do...). The documentation forstore.querystates this plainly, but the documentation here misrepresented that.For example, the original code actually would behave like this: