| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
|
|
||
| // Null values are still reported as null. | ||
| populate({ myKey: null }); | ||
| expect(subject.val()).to.deep.equal({ myKey: null }); |
There was a problem hiding this comment.
I've removed this test case as its incorrect compared to the Firebase SDK, the correct version is now in should deal with null-values appropriately.
Sorry, something went wrong.
| if (numKeys === 0) { | ||
| // Empty node | ||
| return null; | ||
| } | ||
|
|
There was a problem hiding this comment.
This simulates the previously mentioned this.isEmpty() check the Firebase SDK does.
Sorry, something went wrong.
| describe('#hasChildren()', () => { | ||
| it('should true for objects', () => { | ||
| populate({ | ||
| a: 'b', | ||
| c: 'd', | ||
| nullChild: null, | ||
| emptyObjectChild: {}, | ||
| emptyArrayChild: [], | ||
| }); | ||
| expect(subject.hasChildren()).to.be.true; | ||
| }); | ||
|
|
||
| it('should be false for non-objects', () => { | ||
| populate(23); | ||
| expect(subject.hasChildren()).to.be.false; | ||
|
|
||
| populate({ | ||
| nullChild: null, | ||
| emptyObjectChild: {}, | ||
| emptyArrayChild: [], | ||
| }); | ||
| expect(subject.hasChildren()).to.be.false; |
There was a problem hiding this comment.
.hasChildren() had no tests so added some by mirroring the .numChildren() tests above.
Sorry, something went wrong.
|
Let me get back to you. We got rid of the v1 directory temporarily to unbreak the emulator and people depending on undocumented behavior. We want to move everything back ASAP by releasing a breaking change. That breaking change might actually be the best time to accept your change since it's a good change but changes behavior notably. |
Sorry, something went wrong.
Any update on this @inlined ? |
Sorry, something went wrong.
|
Haven't forgotten about you. We just haven't made a breaking change yet. Your PR is actually listed on an internal checklist for changes to be made before our next breaking change. |
Sorry, something went wrong.
|
Thanks (and sorry for the pestering then)! Shall I rebase (/keep rebasing) or wait till you guys are ready and give me a bump? |
Sorry, something went wrong.
|
I don't want to waste your time chasing after a moving target. I'll reach out or rebase myself. |
Sorry, something went wrong.
|
Closing this since the changes have been ported to the launch.next branch and will be included in the v4 SDK. Thank you very much for both your technical contribution and your patience. |
Sorry, something went wrong.
|
[gh pr checkout 926] |
Sorry, something went wrong.
Sorry, something went wrong.
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
Description
I've noticed[1] a difference between DataSnapshots methods in this SDK compared to the one used when fetching data (when using the admin SDK).
When setting values that are (or contain) empty object/arrays and null values using the admin SDK, when fetching these values back, they're always null when calling .val().
However when creating a DataSnapshot with these values and calling .val() the results don't match.
I'm only raising this as an issue because when the functions are being called, I'd expect the DataSnapshot provided to the function handler to match the DataSnapshot when fetched from the same location - currently this isn't the case.
Code sample
Using the following data: { child: 'foo', nullChild: null, emptyChild: {}, emptyArray: [], child: { nullVal: null, key: 'bar' } }
Setting and then getting this value using the admin SDK [2] results in { child1: 'foo', child2: { key: 'bar } } when calling .val(), which is what you'd expect - all the empty/null nodes are dropped.
However using the firebase-functions database.DataSnapshot constructor the result includes these empty/null values { child: 'foo', nullChild: null, emptyChild: {}, emptyArray: {}, child: { nullVal: null, key: 'bar' } } when calling .val().
I think this is mostly due to the lack of this check the @firebase/database does when calling .val().
The discrepancies are mainly when using .val() but I've updated the other methods and their tests (.exists(), .numChildren(), .hasChildren(), etc.) for completeness...
[1] noticed when using firebase-functions-test makeDataSnapshot method (which calls this repos database.DataSnapshot constructor) for mocking parameters for testing a Firebase Function.
[2] By using: