firebase-document only works with static locations

[sfeast]

For example something like:

<firebase-document
 location="{{getLocation()}}"
 data="{{dinosaurs}}">

with getLocation defined as:

getLocation: function() {
 return "https://dinosaur-facts.firebaseio.com/dinosaurs";
}

gives the following:

Looks like an issue in _applyLocalDataChanges since it tries to update the remote doc here even when there is no data or query but not certain how to best address.

[curtiscovington]

@sfeast

Try a computed value.

Polymer({
 is: 'example-element',

 properties: {
 route: {
 type: String,
 value: "dinosaurs"
 }
 location: {
 type: String,
 computed: '_computeLocation(route)'
 }
 },
 _computeLocation: function(route) {
 return "https://dinosaur-facts.firebaseio.com/" + route;
 }
 });

This will change the location variable anytime the route variable changes.

[curtiscovington]

@sfeast actually, the code you provided appears to work for me. Are you using the latest version?

[sfeast]

Thanks for taking a look. Looks like it's also tied to the data property.

Here's an example (only works in chrome I think since I'm defining an element in the main html doc) - https://jsbin.com/mohifu/edit

The example spits out the error I mentioned but if you replace location="{{getLocation()}}" with location="https://dinosaur-facts.firebaseio.com/dinosaurs" then it works. Or if you replace the property definition:

 dinosaurs: {
 type: Object,
 value: function() { return {}; }
 }

with

 dinosaurs: {}

then it will also start working.

[albertolobrano]

I had the same issue and i solved changing the following method in firebase-document

_updateRemoteDocument: function() {
 this._log('Updating remote document');
 if(this.query){
 this.query.update(this.dataAsObject);
 }
},

[mm-gmbd]

After performing a fresh clone of my project repository, I'm now receiving this issue. I was on firebase-element v1.0.10, and after the clone I'm on the latest v.1.0.12, but nothing in the change logs would seem to affect this behavior... regardless, I'm receiving the error.

I'm at a loss after some debugging... the code is as follows:

<firebase-document
 location="[[_computeUserLocation(location, _user)]]"
 data={{userData}}>
</firebase-document>

The property userData was originally set to an empty object in the element's properties:

properties: {
 ...,
 userData: {
 type: Object,
 value: function(){ return {} }
 }
}

But, removing the value, or removing the property entirely has no effect.

I've added the following logs to firebase-document:

_localDataChanged: function(change) {
 var pathFragments = change.path.split('.');

 console.log("change",change);
 console.log("this.location: ",this.location)
 console.log("this.query: ",this.query)

 if (pathFragments.length === 1) {
 // this._updateRemoteDocument();
 return;
 }

 this._setRemoteDocumentChild(
 pathFragments[1],
 change.base[pathFragments[1]]
 );
},

> change Object {path: "data", value: Object, base: Object } //both value and base are empty objects
> this.location: undefined
> this.query: undefined

Obviously, the last line of output is an issue. But, considering "query" is a property of firebase-document, I'm confused as to how it is simply undefined...

The suggestion by @albertolobrano works fine, but this needs to be addressed in an official update!

[ebidel]

Can someone submit PR?

On Thu, Feb 4, 2016, 5:02 AM Max Mueller notifications@github.com wrote:

After performing a fresh clone of my project repository, I'm now receiving
this issue. I was on firebase-element v1.0.10, and after the clone I'm on
the latest v.1.0.12, but nothing in the change logs would seem to affect
this behavior... regardless, I'm receiving the error.

I'm at a loss after some debugging... the code is as follows:

The property userData was originally set to an empty object in the
element's properties:

properties: {
...,
userData: {
type: Object,
value: function(){ return {} }
}
}

But, removing the value, or removing the property entirely has no effect
.

I've added the following logs to firebase-document:

_localDataChanged: function(change) {
var pathFragments = change.path.split('.');

console.log("change",change);
console.log("this.location: ",this.location)
console.log("this.query: ",this.query)

if (pathFragments.length === 1) {
// this._updateRemoteDocument();
return;
}

this._setRemoteDocumentChild(
pathFragments[1],
change.base[pathFragments[1]]
);
},

change Object {path: "data", value: Object, base: Object } //both value and base are empty objects
this.location: undefined
this.query: undefined

Obviously, the last line of output is an issue. But, considering "query"
is a property of firebase-document, I'm confused as to how it is simply
undefined...

The suggestion by @albertolobrano https://github.com/albertolobrano
works fine, but this needs to be addressed in an official update!

—
Reply to this email directly or view it on GitHub
#31 (comment)
.

[mm-gmbd]

I'd be happy to, but I'm just wondering if that fix is sufficient. Also, does the same have to be considered for firebase-collection?

[GeoloeG-IsT]

@ebidel this? #109

[mm-gmbd]

I think the title is misleading for this issue -- it's not really the location that is causing the error described in the issue, its the fact that query doesn't exist at the time _applyLocalDataChanges is called. So, I'm not sure if #109 fully addresses the underlying bug.

Now, maybe that only happens when the location isn't a static string, but performing a check for existence of query should still be considered/implemented in my opinion.

[ebidel]

I'm not sure #109 is the best fix. From reading all the comments, this does seem like a timing issue with this.query being set.

Something like #31 (comment) seems like a good approach.

If someone can throw together a simple jsbin that uses dynamic locations that would be really helpful. There's a couple of open issues on dynamic locations not working, so we should make sure everything is covered.

[mm-gmbd]

@ebidel, note about the comment that you referenced. _updateRemoteDocument is called from _localDataChanged, which, depending on the path provided could call _setRemoteDocumentChild which also includes a call to query.

IMO, the fix (at least, in firebase-document), should be in _localDataChanged just to err on the side of caution:

_localDataChanged: function(change) {

 if (!this.query) {
 return;
 }

 var pathFragments = change.path.split('.');

 if (pathFragments.length === 1) {
 this._updateRemoteDocument();
 return;
 }

 this._setRemoteDocumentChild(
 pathFragments[1],
 change.base[pathFragments[1]]
 );
},

[ebidel]

Yea, we should add checks everywhere where methods depend on query but it hasn't been defined yet.

Just so I'm clear, it's not that setting a location dynamically doesn't work, but that it throws JS errors propagating through the system?

[mm-gmbd]

In many cases have I set a location dynamically through a compute or simple data binding, but in some rare instances, yes, the query error completely breaks my application.

[Gnesan]

`<firebase-query` id="query"
 path="/resident/[[bizKey]]/[[grpKey]]"
 data="{{resident}}">
 </firebase-query>
 <vaadin-grid visible-rows="{{resident.length}}">
 <table>
 <colgroup>
 <col>
 <col>
 <col>
 <col>
 <col>
 </colgroup>
 <thead>
 <tr>
 <th>Name</th>
 <th>Email</th>
 <th>Mobile</th>
 <th>Department</th>
 <th>Date</th>
 </tr>
 </thead>
 <tbody>
 <template is="dom-repeat" items="[[resident]]" as="res">
 <tr>
 <td>[[res.name]]</td>
 <td>[[res.email]]</td>
 <td>[[res.mobile]]</td>
 <td>[[res.department]]</td>
 <td>[[res.dated]]</td>
 </tr>
 </template>
 </tbody>
 </table>
 </vaadin-grid>
 </div>

 </template>

 This is my code .
 i want to change [[grpKey]] dynamically and also update items="[[resident]]" .please help me