Query: First argument passed to startAt(), endAt(), or equalTo() cannot be an object.

[vkniazeu]

Version info

Angular:
4.0.2

Firebase:
3.7.6

AngularFire:
2.0.0-beta.8

Other (e.g. Ionic/Cordova, Node, browser, operating system):
Ionic Framework: 3.0.1
Ionic App Scripts: 1.3.2
Angular Core: 4.0.2
Angular Compiler CLI: 4.0.2
Node: 7.9.0
OS Platform: Windows 10
Navigator Platform: Win32
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36

How to reproduce these conditions

Failing test unit, Plunkr, or JSFiddle demonstrating the problem

Steps to set up and reproduce

this.af.database.list('/items', {
      query: {
        orderByChild: 'keyA',
        equalTo: { value: 'valueB', key: 'keyB'}
      }
})

Debug output

** Errors in the JavaScript console **

Error: Query: First argument passed to startAt(), endAt(), or equalTo() cannot be an object.

Expected behavior

As described in the footnote 1 at https://github.com/angular/angularfire2/blob/master/docs/4-querying-lists.md.

Actual behavior

Error: Query: First argument passed to startAt(), endAt(), or equalTo() cannot be an object.

[cartant]

@vkniazeu If I mentioned on Stack Overflow that support for the optional key for equalTo and endAt was in verion 2.0.0-beta.8, I was mistaken. The changes were introduced in this commit: e146492

Which is two commits after 2.0.0-beta.8. So the changes have been merged into master, but they are not in a published release. Apologies for any confusion I've caused.

[vkniazeu]

@cartant , thank you for a quick reply!
I did find #838 and erroneously commented there (comment deleted) to ask about this feature.
But I wasn't going by any of your comments per se, but rather by the footnote 1 at https://github.com/angular/angularfire2/blob/master/docs/4-querying-lists.md.
It clearly suggests that I can specify the key parameter to equalTo.
Perhaps it's best to update that footnote to only apply to startAt until the feature is released, what do you think?

[cartant]

@vkniazeu Currently, the documentation is essentially whatever is in master and, as the PR that was merged included the code changes, the tests and the documentation, it's reflected in what you see on the GitHub site. If/when the documentation is published to a separate site - upon the publishing of a release - this would be less of a problem, but, at the moment, it is what it is.

[vkniazeu]

@cartant , got it. I was treating the docs as something that was updated post release.
In any case, thank you for the PR and looking forward to using the feature in my code when it's released.
This issue is resolved then.

[cartant]

@vkniazeu No worries. For what it's worth, when I look around in GitHub repos for source and docs I often make a point of selecting the branch that corresponds with the latest release - or the release that I'm using - to see the source and docs as they were at the time.

[lucasmafra]

please, I need this feature for now! How can I play with the latest changes in master?