React-redux-firebase: equalTo, startAt and endAt parses every string starting with digit

[biomorgoth]

I am trying to run a query that consists of email addresses that starts with digit. Let's use [email protected] as an example. When i try to do the following:

firebaseConnect([ 'todos#orderByChild=emailAddress&[email protected]' ])(SomeComponent);

It does not return the same matches as i built the query myself:

getFirebase().database().ref('todos').orderByChild('emailAddress').equalTo('[email protected]')

And researching into the code, i noticed in method applyParamsToQuery from utils/query.js, that when case is equalTo, startAt and endAt, a parseInt is applied on the param value. This makes react-redux-firebase build a different query that equals to this:

getFirebase().database().ref('todos').orderByChild('emailAddress').equalTo(123)

Is there a way to circumvent this situation? I cannot see a way to avoid it without making changes to that method.

[prescottprue]

@biomorgoth Your syntax is correct and should work. This seems to be a bug within the exact method that you pointed out.

I will begin work on reproducing then attempting to solve the issue an post updates here. Thanks for reporting!

[biomorgoth]

@prescottprue As a fast and non-invasive solution to the issue, i thought of adding an equalToStr case in applyParamsToQuery that explicitly skips the parseInt call, avoiding all the situation. But i do not know if you prefer to keep all the same names just like Firebase.

A bigger approach would be providing an object queryParameters to applyParamsToQuery instead of an array, so we can specifically pass Integer/Float/String/etc. values without parsing it internally. But that still leaves the query string in firebaseConnect broken, if anyone would want to use it (and i personally like it a lot!).

[prescottprue]

I think it might be good to better test for if that is a number before parsing. We should keep all the existing functionality (string or object notation).

Either way, starting to look into solutions now.

[biomorgoth]

In fact i have just came with a possible solution by using Number(value) instead of parseInt(value), which gives the following advantages:

• Tests if value is completely a number or returns NaN.
• Returns an Integer or Float result depending of parsed value. Note that with current parseInt doing equalTo(8.9) is not possible either, as it is actually translating to equalTo(8).

I am testing that solution and will make a pull request if everything is fine.

[prescottprue]

Awesome, thanks!

[prescottprue]

Great fix!

Planning on releasing this in a patch sometime today (hopefully after adding to the tests to cover this). Will leave this open until it is released.

[prescottprue]

v1.3.4 has been released and contains these changes. It also has tests that better tests this functionality including a string that has numbers in it.

Thanks for making the pull request.