FirebaseExtended / polymerfire

Polymer Web Components for Firebase
https://www.webcomponents.org/element/firebase/polymerfire
MIT License
459 stars 142 forks source link

firebase-query not setting exists=false on the first run #349

Open iSuslov opened 6 years ago

iSuslov commented 6 years ago

Description

firebase-query not setting exists=false on the first run

Expected outcome

exists=false on the first run when snapshot.hasChildren() == false

Actual outcome

ignores exists parameter and leaves it as null. Can not track that loading is finished

Steps to reproduce

Create firebase-query for empty collection and check what happens with exists property (Nothing).

andrewspy commented 6 years ago

@iSuslov I have similar issue with <firebase-document>, would you be able to confirm the issue on <firebase-document> and provide a fix as well?

iSuslov commented 6 years ago

@andrewspy I can confirm by reviewing the code in master branch that firebase-document sets exists on the first run, however keep in mind that it does not do that if any error happens, for example permission denied. You have to listen for error event to have a whole picture.

andrewspy commented 6 years ago

@iSuslov Thanks for the info, you are right, exists will remain null if there is no security permission given to the path.

May I know how to listen for error event in <firebase-document>? Using <firebase-document on-error="errorHandler"> doesn't seem to work and I can't find it in polymerfire documentation

iSuslov commented 6 years ago

@andrewspy on-error should work, see firebase-common-behavior.html which is a part of firebase-document

andrewspy commented 6 years ago

@iSuslov I have tried out on-error on another test case, and it works as expected.

The reason on-error doesn't work on my case is that I have an empty path name (i.e. /tenants//users/LSjsiBNv1/data), and running it against the rule simulator resulted "permission denied", but it somehow doesn't emit any error when using it as the path in <firebase-document>. Not exactly sure if it's the expected behaviour.

Anyway, thanks for the help.

iSuslov commented 6 years ago

@andrewspy should be expected behaviour, since it won't make actual request to the server if path is empty or invalid - containing //.