Behavior similar to 'firebase-collection'

[gdavalos]

The old firebase-collection was mutable via data-binding which allowed the user to add, remove, or edit elements of the query pretty easily, however, firebase-query is now immutable.

I want to know if you're considering adding those behaviors to firebase-query and if you aren't then how would you recommend us to cope with the lack of them? (Would it be possible using firebase-document somehow or would we need to interact with the javascript API directly?)

[cdata]

Hi, thanks for posing this question about the design.

The design in the old firebase-collection was problematic in a significant subset of use cases. For example, consider a collection where you have limited the results to the first ten, and you already have ten results in data. Then, you push a new item into data. What happens?

1. An eleventh item is added to the array (possibly causing a corresponding thing to be rendered in the DOM somewhere in the distance).
2. This item is added to the Firebase database in the client (which must coordinate asynchronously with the server).
3. Once the item is added - if the limit allows it - the client will fire a child_added event so that we can add it to the collection. However, if the limit does not allow it, no relevant Firebase event will be fired.
4. If we determine that no event will be fired (sometimes the case for our example: a newly added eleventh item of a limited-to-ten collection), we must manually remove the eleventh item from the firebase-collection's data, undoing whatever work was just done to add it.

Furthermore, this is problematic because there is nothing stopping the user from splicing in a new item at any position in the data Array. However, because the data reflects a filtered, ordered query against Firebase, the true order is implicitly immutable until the server tells us it should change.

So it seems most hygienic to think of the results of a query as immutable. One way to mutate the query is to create a new firebase-document without a path and use the save method. If the resulting document matches an existing firebase-query, then Firebase will notify the client and cause the firebase-query's data to be updated appropriately.

One thing that is worth noting is that firebase-query will synchronize updates to the documents it contains. So if you modify the sub-path of a document in the firebase-query, and that modification should cause the firebase-query's data to be re-ordered, it will do so.

[gdavalos]

Thanks a lot for the reply, as you said, firebase-document.save() seems to be the way to go to achieve those behaviors.

[miztroh-zz]

@cdata Wow, glad I found this one. This really needs to be documented in an obvious manner. As a user of the older firebase-element package, I was trying to use firebase-query as a replacement for firebase-collection. Had been beating my head against this for a few days before I stumbled upon this closed issue. I'll create a new issue requesting that this be documented.

[MarcosGalaviz]

Hi, I am just beggining with firebase and Polymer, is there a place where I can see an example about this?

I am very confusing whith this.

Thanks a lot.