Can write but not read data with firebase-document

[giubil]

Description

When using a computed binding for the path property in firebase-document, such as path="{{createPath(user)}}", the data is empty, although I can write to it and it's updating in the firebase database.

Expected outcome

firebase-document fill the data property with the content of the database.

Actual outcome

data is empty.

Live Demo

N.A.

Steps to reproduce

1. Declare a firebase-document with path equal to a computed binding, such as {{createPath(user)}}
2. Declare the computed binding, such as createPath: function(user) {return "/users/" + user.uid;}
3. Observe that you can't read from data but you can write to it

Browsers Affected

• Chrome
• Firefox
• Safari 9
• Safari 8
• Safari 7
• Edge
• IE 11
• IE 10

[cdata]

Hi @giubil , thanks for reporting. I will try to reproduce.

[e111077]

Heya, @giubil, I have not been able to reproduce this issue. Here is an example application where I have this working:

http://jsbin.com/fuhuqolida/1/edit?html,output

N.B. My firebase database rules also allow for reading but no writing.

A shot in the blue is that you might be having issues with your application observing on the object but not the properties inside the object. e.g. you have the binding {{createPath(user)}} and when you change user you set it like this:

this.user.uid = newUid

instead of:
this.user = {uid: newUid, otherproperties: ...}

or using the set function. Alternatively, you can also observe paths: e.g. {{createPath(user.*)}} or {{createPath(user.uid)}}

See this link for more info on object path observation.

[giubil]

Hey @e111077 , thanks for your feedback.

Unfortunatly even when listening on {{createPath(user.uid)}} it does not work. In my createPath(user) fuction I added a console.log(user); and I can see it updating twice, first it's undifined and then it's going to the userId that I have (and btw, I am binding to the user variable from <firebase-auth user="{{user}}">). And I have still the same symptoms, I can write but not read.

My rules in my firebase DB allow for read and write from anyone, logged or not. So I am pretty sure that's not coming from there either.

Edit: to help you reproduce it, I just took the note-app tutorial files and added in this code :

<firebase-document id="playlist_data" app-name="notes" path="{{createPath(user.uid)}}" data="{{playlistInfos}}"> </firebase-document> <paper-input value="{{playlistInfos.username}}" label="test"></paper-intput>

[...]

createPath(user) { console.log(user); if (user == null) return null; return "/users/" + user + "/"; },

[mraerino]

I can reproduce this issue.

Code:

<firebase-document id="user" path="/users/[[ uid ]]" data="{{ data }}"></firebase-document>

What seems to happen:

• At one time the data attribute gets populated from firebase. If I debug my app, I can see values for one data-changed event
• The data seems to get overwritten shortly after that by the AppStorageBehavior in line 178

It strangely works if I don't use a binding in the path attribute.

I guess: The AppStorageBehavior does weird things if the path is based partly on a binding.

[e111077]

Heya, guys, I've tried implementing your suggestions to replicate the issues with zero luck.

Would it be possible to provide a jsbin or some equivalent where this fails? The jsbin in my earlier post should provide the polygit / jsbin boilerplate for polymerfire / firebase.

Thanks!

[giubil]

Hey,

This is weird, I can't reproduce it basing on your jsbin and my code.

However the bug is still present in my code. If you want to reproduce it, just grab the note-app demo and add those lines to the note-app.html in the base code

<firebase-document id="playlist_data" app-name="notes" path="{{createPath(user.uid)}}" data="{{playlistInfos}}">
</firebase-document>
<paper-input value="{{playlistInfos.username}}" label="test"></paper-intput>

[...]

createPath(user) {
     console.log(user);
      if (user == null)
            return null;
      return "/users/" + user + "/";
},

My guess is, could it have some problem with the <platinium-sw-register> ? I don't actually really know how it works, so I may just say stupid stuff.

Also to be noted, I don't use gulp serve, I use firebase serve as stated in the tutorial. Although I am not sure if that could be a problem.

If you still can't reproduce the bug, I would happily send you my code, or a link to the firebase hosted site for you to play with.

Thanks

[e111077]

@giubil in your example can you change that final return statement from
return "/users/" + user + "/";

to
return "/users/" + user;

does that seem to resolve any issues? Additionally, I assume that you created a /users collection in your firebase database, is this correct?

[e111077]

Heya, @mraerino, I see that you had a PR open as a potential fix, and I would love to take another look at it, but I am still unable to reproduce the initial issue and confirm the fix. Would it be possible for you to send me your code that causes this failure?

[mraerino]

Thanks for the reply ☺

Unfortunately I haven't been able to reproduce this error outside my app yet. I'm going to try it soon though.

It seems to happen with multiple firebase-document elements whose path attributes are set and which are attached at different times.

I closed my PR because it didn't quite do the right things.

The bug has been hard to debug but seems to boil down to the function getStoredValue. In that function a firebase request to an invalid path is made, which sets the elements value to the zero value.

I'm running my app with some adjustments to this function (not those from the PR) and everything is fine.
I can submit another PR if you like.

[e111077]

I do see that there is an issue with this.ref being null because it is calculated with the db and the path. When the path is /users/[[uid]], the path used to calculate the ref in the beginning is /users/ (trailing slash) which is invalid and thus produces a nullifed ref. Despite that, changes to uid seem to produce valid data objects.

I'll look into the multiple firebase-document approach as well.

[mraerino]

I also pointed to this in #32 because I'm pretty sure most of my fixing had to do with that bug.

In getStoredValue I sometimes got a path of /users/123446/users/123456 which could explain wrong values as well.

[e111077]

@giubil @mraerino We were able to land #54; I have also been unable to replicate this issue. Has #54 fixed this?

[mraerino]

Reading from Firebase through firebase-document works fine for me now.

There are still some issues where I can't write changes to Firebase because this.__initialized of app-storage-behavior stays false, but I'll make a different issue for that.

[e111077]

Please do! And thanks a lot for the cooperation