ready property for <firebase-document> and <firebase-query>

[andrewspy]

Can we have a ready boolean property which will be true when data has at least been fetch once (much like in the firestore branch)? I have seen similar proposal of using exists in #33, but it's not exactly same as ready.

The use case that I have is for access control, which I need to grant permission to the user when the path/data is ready. Without knowing if the data is ready, user will always see a brief "Permission denied" page until the data has been fetched, which is not a great user experience. Thanks!

[tjmonsi]

@andrewspy let me see what we can do. You can also do a PR for it if you have time.

So the use case for it are:

• first boot
• ready: false
• once data is streaming -> ready: true

So will it be true always after it has retrieved its first data (even if it is null)?

[andrewspy]

@tjmonsi Thanks for looking into this! I don't think I am skillful enough to do a PR, but I can help do the testing.

Personally, I would like ready to be true, after the initial data has been loaded (instead of start of data streaming), but the behaviour should be consistance with other firebase product/SDK (i.e. firestore), I think.

ready property should also be reset on path/query changed.

It should always be true after it has retrieved it's first data, but I am not too sure if the data will ever be null as <firebase-document> always return {} even if data does not exist (can't be 100% sure), while <firebase-query> always return [] with empty query result.

[tjmonsi]

I was thinking of using exists which is part of the spec but it also means that either the data is not yet ready or null. Let me check the spec again and see what I can do

[christophe-g]

@tjmonsi - you might be referring to #234 ; )

It has some merge conflict - which I can look into if you consider including the PR. The exist attribute has been truly useful in my use of firebase.

[andrewspy]

I think exist attribute should be good enough for my use case also.

[andrewspy]

@tjmonsi Any findings on using exists from the official spec? I think this attribute is fundamentally necessary for polymerfire to make it complete, but unfortunately was not implemented despite being discussed a few rounds previously by the community.

[tjmonsi]

@andrewspy the best way was to connect it via exists() method. The current implementation of the PR is not good because it assumes that it exists without using the exists() method. So either I create a new PR or edit the existing PR. I'm going to do the review on it and let the PR creator decide.

As for ready I think I know I can work on it.

[andrewspy]

@tjmonsi Any update on ready?

[andrewspy]

@tjmonsi Friendly ping on ready or exists attributes, or may I know the plan in the pipeline?

[andrewspy]

I have tried out the exists from #234, it is working as expected. However when applying it in my code base, I notice what I really need is the ready attribute which will be true when data is fetched for the first time, so that I can show a spinner if the data is not ready (even thought the data may not exists in the path)

[andrewspy]

After reading #349, I also notice that <firebase-document> in #234 does not change exists to false from null in the first run when the path does not exist, which is also why I can't track when loading is done.

[andrewspy]

Just found out that in order for exists to work properly, it has to have the proper permission in database rules. Without the permission, exists will always be null.

Since exists feature has been merged into master, I hope we can get a release soon. Closing the issue.