How to set up a "read-only" firebase-document (or, "read-first")

[mm-gmbd]

I'm building a single page application that has two tabs. A firebase-document to a particular location is called by an element on the first tab. The second tab is lazily loaded, and a firebase-document to the same location is set up by an element in that second tab.

The user only has read privileges to this location, but I'm getting the following error when the second firebase-document is loaded:

Uncaught Error: Firebase.update failed: First argument  must be an object containing the children to replace.

This is because the data attribute that is supplied to the second Firebase document is null because I am awaiting the value to be supplied by the firebase-document. Instead, it immediately updates the local cache (I think) to null, which is why I think the error is happening (as it calls _dataChanged).

I'd like a way to instantiate multiple firebase-document's that reference the same location without this happening. I had hoped to do this by binding the data from the firebase-document in such a way that it is child-to-host, but that requires the child element (in this case, firebase-document) to have the readOnly property set to true for data.

A potential solution is to include a "readOnly" property to the firebase-document itself, that, if set to true, would set the readOnly property of data to true, which would then allow for child-to-host data binding. Another solution would be to include a readFirst to firebase-document property which would read the data if it was in the local Firebase cache, if it wasn't in the Firebase cache, it would attempt to update the remote document.

Otherwise, I'm forced to load the data at location only once and then pass it around through Polymer variables (which is not going to happen because I am uncertain of how nested these elements may be), or through something like akc-meta, which I'd rather not use.

Thoughts?

[mm-gmbd]

@brogers4

[mm-gmbd]

Bump for some action...

[cdata]

@mm-gmbd Hi! firebase-document should be able to support two instances pointed at the same location without the error condition you are describing. So, the behavior you describe sounds like a bug. Could you provide a reduced test case in the form of a JSBin or code snippet that we can review to assess what is going? For help getting started, please check out our contribution guidelines.

[mm-gmbd]

In the process up putting together a repro now... thanks for the attention, @cdata!

[brogers4]

@cdata @mm-gmbd This doesn't exactly reproduce the scenario described above but it is related. I added the code to my github (link below) which includes a fairly detailed description of the issue.

https://github.com/brogers4/firebase-test

[brogers4]

@cdata, I just realized you may not make the connection that @mm-gmbd and I are working on this together. The above link is the repro that @mm-gmbd was referring to. Also, if a JSFiddle or JSBin would be better, let me know.

[brogers4]

Here's a JSBin reproduction:

http://jsbin.com/yejoxa/edit?html,console,output

[brogers4]

Any update? We weren't able to reproduce the error where the same location is referenced multiple times (still exploring it though). It looks like at least part of the original bug was due to putting the <firebase-document> inside a dynamically generated dom-repeat of <firebase-document>'s as described here.

[cdata]

Sorry, there seems to be some conflated discussion here.

This doesn't exactly reproduce the scenario described above

@brogers4 Please keep unrelated repro cases to a separate issue (unless you are collaborating directly with @mm-gmbd and he agrees that this repros his case).

[brogers4]

@cdata, Yes, I am collaborating with @mm-gmbd (he is on vacation which is why I am now responding). I was trying to reproduce the error described originally; however, I now think the description as to the potential cause of the error originally proposed by @mm-gmbd to be incorrect (though, we are still debating).

Our original thought was that since the <firebase-document>'s were being generated dynamically it was creating some kind of conflict with <firebase-document>'s that were defined statically to the same location. However, the reproduction attempt I linked to disproves this.

What we did discover is that the error originally encountered by @mm-gmbd occurred not because it was lazily loaded in a second tab, but because it was lazily loaded inside a dom-repeat template. The GitHub repro describes the error in detail, but basically the <firebase-document> initially resolves to the correct value but then receives an undefined object which causes the error that @mm-gmbd refers to.