`firebase-document` defaults to `{}` before resolving

[43081j]

Description

When using firebase-document, somewhere it defaults to the empty object (this).

This means in the common use case we observe the following values (in order):

• undefined
• {}
• { "foo": "bar" }

Where the last object is the actual document from Firebase.

In the old firebase elements, we would observe:

• undefined
• { "foo": "bar" }

This is a problem because we can no longer expect a well structured (essentially "typed") object.

If we write a component for fetching and displaying posts, for example, we are forced to add a condition to ensure the document is the right "shape". We cannot safely assume that any object we get in our property is the correct structure/shape.

Additionally, this means if for some reason you try to fetch an array, you observe the following:

• undefined
• {}
• []

Which of course is crazy. The only values we should see are the resolved ones from the database and undefined (or maybe null for when it doesn't exist).

[mbleigh]

This isn't unfortunately as straightforward as just removing the empty object behavior. Ultimately this is a tradeoff in binding behavior. If we reverted to the old firebase element ways, then you have to explicitly initialize an empty object to be able to bind to sub-properties. This is a really easy recipe for accidentally blowing away documents by setting to {} and having that propagate to the server.

I agree that the behavior as-is isn't perfect either. I'd like to find some way to support both sub-property bindings and clear "type structures" like you suggest. Any thoughts?

[nakleiderer]

My $0.02: Have a Boolean property on firebase-query, firebase-document, etc that says if the latest request has been completed. You can look to iron-ajax for inspiration regarding the elements properties. In many cases, I've elected to use firebase's JSON api with iron-ajax to avoid issue like this, but that only works for non-reactive data.

[43081j]

@mbleigh, Can we not just set zeroValue to undefined? Then after fetching the result, set the data to empty object (if val() === null)?

This way you go from undefined -> {...}.

Been a while since I read the code thoroughly, but isn't the problem here caused by the fact that data defaults to zeroValue? So it'll go:

• before initialisation (undefined)
• default (zeroValue)
• val() is null, so we set value again to zeroValue, or we set the actual data here

So the freaky one here is the default value, is it not? This means we can still bind when it is non-existent, because it'll resolve to null and be set to {}.

Unless i'm missing something, we'd then end up with:

• before initialisation (undefined)
• default (undefined)
• val() is null, so we set value to {}, or we set the actual data here

[iw2rmb]

I'll duplicate my thoughts here from #121.
At least, dom-if is not working with {}.
Is it possible to have parameter that handles behavior of zeroValue (null or {})?
If it's undefined before binding and null when no data — I can manage every state of.

[kvnapavl]

Could we create a null or isNull property object to use as an attribute to set default values? Then you could pass it some JSON to make custom default value?

e.g.

<firebase-document path="/" data="firebaseData" null="{key: value}"></firebase-document>

[mbleigh]

What if there were a separate bindable "exists" property that would return false for empty object, null, undefined, and true for everything else?

[kvnapavl]

That sounds awesome.

[kvnapavl]

It would be nice to be able to access that data for loading templates.

[n1ywb]

the exists property seems like a band-aid

it would still be impossible to distinguish between a truly empty firebase node and a firebase node containing {}

{} before value is loaded also makes computed bindings and observers fire prematurely; polymer doesn't call computing functions or observers until all the dependencies are defined; this is very helpful; the {} behavior demands a bunch of additional guard code inside observers and computation functions to avoid side effects; subtle side effects which I am tripping all over as I try to learn polymer & firebase; it's really quite bad; along with the dom-if issue it breaks polymer in many unfortunate ways

UPDATE: all I really want to do is set new firebase nodes to default values the first time they're loaded and it's been insanely difficult to figure out a working reliable way to do that seemingly trivial task. zeroValue {} seems to introduce some sort of race condition between firebase-document and my imperative code to set the default value using the firebase JS API. Finally I just commented out the zeroValue {} override in firebase-document and now EVERYTHING JUST WORKS. But what I'd really like is a way to DECLARE the default value rather than set it imperatively. E.g. by making zeroValue bindable. I tried hacking that in but it didn't persist the zeroValue to the store so it wasn't really useful.

@43081j if the node getting returned is {}, then exists is false untill the first transactionComplete is returned, then exists = true?

[43081j]

To be honest, the whole idea of zeroValue being an empty object is a bad idea imo.

I understand why its there, because, without it, binding would be much less straight forward (what if you bind to a sub-property of a non-existent document?).

However, things like adding an exists state are just workarounds and avoidance of having to change the default.

It is impossible to have an empty firebase node ({}), so the way everyone should/would expect it to work is:

• value is initialised (null)
• request begins (still null)
• response is non-null (set the object)
• response is null (still null)

@mbleigh can you see any obvious problems in simply having the zeroValue as undefined (or null), then, if the response is null, set the value to {}, otherwise set to the response? would that not work?

[mbleigh]

The empty object is there because without it, it's super-easy to accidentally blow away the data. You write code like:

this.data = this.data || {default: 'value'};

And it blows away whatever was already there. I agree that there are drawbacks to the empty object, too, but I've seen the bad effects of null default value in firebase-element and I don't want to see it come back.

[derhuebiii]

I am facing the same situation now, I would like to figure out if user data already exists (e.g. uid-node or sub-nodes) but I cannot distinguish between loading or empty. Has there been any update how to deal with this?

[kvnapavl]

Could we have an attribute that determines return type and/or return sequence?