Cloud Firestore Support

[JGSolutions]

So just found out that firebase has released a new feature called firestore. Lovely (sarcastic way). I read about it and it does seem interesting and looks more powerful than the real time database. Now the question is any plans on creating polymerfirestore? LOL LOL

[mbleigh]

I've been prototyping something and hope to work with @tjmonsi to get it in releasable shape soon. Stay tuned!

[JGSolutions]

WOW nice! Would be another component not part of the polymerfire? For example another web component called polymerfirestore?

[mbleigh]

TBD, as I said, stay tuned!

[JGSolutions]

Thanks I will :)

[mbleigh]

Re-opening to leave as a single feature request.

[tjmonsi]

Should we do it as a behavior/mixin or a component?

[stemuk]

@tjmonsi A component like firebase-query would be great since it would make the 'getting started' part much easier.

[Scarygami]

I guess a similar approach to how it's done with the real-time database would be best.

Have a firebase-firestore-behavior as a basis, and implement firebase-firestore-document (to allow writing data) and firebase-firestore-query based on it.

With the extended query functionality (like chaining wheres/orders) it will be challenging to implement an all-purpose query component...

[Scarygami]

Btw, I'm open to testing this as soon as you have a branch/repo public somewhere :)

[tjmonsi]

@Scarygami will ping you once I am done. (Just finishing a devfest site and some experiments)

[mbleigh]

FWIW, I don't know that the existing approach is going to work well for Cloud Firestore, especially due to the query complexity that is possible as compared to the Realtime Database. I'm probably going to try to pull my experimental library into a branch so everyone can take a look and see if you like my approach (it's a class mixin, not an element).

[tjmonsi]

@mbleigh yeah that's my thought as well.

[phidias51]

I'm curious what this might look like. Suppose you could simply modify the firebase-app tag to point to your firestore database. The firebase-query and firebase-document elements would still work. If you want to add pagination you would simply add a "page-size" attribute to your query, and advance the start-at pointer. This would cut down on the amount of work required to migrate over to firestore.

[mbleigh]

In general, if you try to treat things that aren't the same as being the same, you're going to have a bad time. Cloud Firestore is fundamentally different from the RTDB in many ways, so trying to shoehorn it will have negative tradeoffs when the square peg doesn't actually fit the round hole.

Again, I'm trying to get my experimental library in a branch for people to try out as a potential approach.

[phidias51]

Here's the problem. If anyone has an existing project, they're going to have to touch every query and document element to get this to work. There's nothing that says that there has to be a 1-to-1 correspondence between firebase elements and underlying classes and the JavaScript library.

[tjmonsi]

@phidias51 As for the firebase-app. I think I just merged a preparation for having a firestore just now at #273. But I don't think it is a good idea to change the firebase-query and firebase-document's functionality to accommodate firestore. Firebase and Firestore are very different from each other. That means we could work with having a firestore-query and firestore-document. But the problem is how to set the path just only using strings. @mbleigh already has a mixin much like PolymerRedux where you can set the path to automatically save it to a particular property, and I am going to experiment on it next week.

[imarian97]

@mbleigh I love your implementation ;) I hope to be well received by the community and be available in polymerfire. Also, I'm writing a blog post about my experience with Polymer and Firestore. Do you have any plans to make the repo public? I want to know how much can I describe and refer your class mixin implementation in my post.

[mbleigh]

@imarian97 if you wait until next week I think we'll have it in a branch on this repo :smile:

I'd love to see your blog post if you have a way to share drafts before you publish.

[imarian97]

Perfect, I'm planning to publish it next week and for sure I'll share it before

[mbleigh]

All right, I've gone ahead and taken a rough pass at porting my experimental work into PolymerFire, and you can check it out at #278. Folks who are interested, feel free to install the firestore branch and give it a spin. Feedback welcome!

[Scarygami]

Played a little bit with the mixin and really liking it so far.

Send a PR for an issue I ran into with firebase-app not being ready before the mixin tried to do something with firestore.

Some questions/suggestions:

• How should the mixin best handle the persistance option? Since the option needs to be enabled before doing anything with firestore it would make sense to include a property on firebase-app which triggers firebase.firestore.enablePersistance and maybe checks for errors/fires error events.

• The way the observes option is implemented now it requires all observed properties to be truthy before triggering a query. This seems rather strict, and I think this should be changed to checking against !== undefined, or leaving it up to the user entirely to handle the logic when constructing the query. Or there could be two different options for requiredObserves and optionalObserves but I think the first option is cleaner.

• The element strips away the snapshots, only returning the data. I've wanted to implement pagination, but that requires a documentSnapshot for startsAfter. Including the snapshot similiar to how you include the __id__ would be a possibility. This could also be done by giving another option to the users whether they want to have data or snapshots returned. Additionally having the reference of the document would be helpful in some cases as well, e.g. for easy access to subcollections.

I leave these topics up for discussion and can send PRs for ideas we agree upon.

[tograd]

I was a little anxious how it would work as a mixin, but the solution seems really neat and tidy. I like not having to add non-rendering dom.

* * <propname>Ready: will be true when all path segments are present and data has been fetched at least once Been a long-standing complaint of mine for firebase-query and firebase-document that you couldn't figure out if request hadn't been done yet or just had no data. So this is really appreciated!

[imarian97]

@mbleigh Here is my blog post on our new blog (built with Firestore and polymer) 😄 https://goldielabsite.firebaseapp.com/post/firestore-new-blog. We are planning to publish it tomorrow (to our domain: goldielab.com) and I hope you like it. I'm looking forward to receiving feedback

[PFElements]

So far looks very promising. Kudos.

[merlinnot]

@mbleigh @tjmonsi Any chance to work on this in the near future? I've made few PRs fixing various issues. There's plenty more work to do, but some feedback from the repo owners would be nice.

[tjmonsi]

@merlinnot I'll try this out this coming week and would check if it is good for the next push for version. :) thanks for the catching this part :)

[do-io]

@imarian97 do you happen to have a git of the firestore implementation? I am working through right now and working on the firestore bit.

Thanks in advance.

[imarian97]

@DObD all my project that uses firestore are private. I am planning to publish the repo of my company blog/site but is not 'publishable' yet. I suggest you use the #firestore branch of this repo and you can find more info on my blog post (linked in my previous comment). If you have any specific questions I can help you here or in private ;)

[merlinnot]

@DObD please note there are multiple issues with this branch, I’ve made few PRs to fix them, but they’re all waiting to be reviewed by the repo owners. These PRs do not cover all of the issues with this branch but I’m not willing to make more since there will be too much conflicts later on.

I’d strongly advise not to use this branch unless you can debug these issues with ease.

If there will be no progress till the end of the week, I’ll merge all of my fixes into one branch and link it here for everyone to use.

[do-io]

@merlinnot - Good information! I'll come at the posts a different way until the next Polyfire release.