• The biggest selling point of the library in my opinion is not stated in the docs. For me, it's not so much about avoiding writing my own boilerplate than providing an abstraction for the cloud persistence. With this library, you make no calls to Firestore yourself. You don't have to care about how Firebase works, you just speak to your very own Vuex and the rest gets taken care of behind the scenes. Tomorrow, maybe this library could support other providers and my app wouldn't have to know about it, there would just be another connector to configure to switch to CouchDB, Appolo or whatever
• Also, it's not clearly stated that the library is built upon the concept of optimistic UI, unlike Vuexfire: changes are brought immediately to your store before the xhr calls are made, and you deal with conflicts later if need be (or rather it will hopefully be possible at some point haha), which is the philosophy of the Firestore SDK too.
• I'd emphasize a bit more that your way of doing things is to have a module per collection and/or per document. It became obvious soon, but since I never really felt the need for modules before, I wasn't organized like that, and it required more than 4 lines of code to adjust ;)
• You say "It's very important that we take the user to an error page when something went wrong with the Firestore initialisation" but actually you're saying that about the success of enablePersistence, which does not garantee at all that you'll get your initial data right. It's rather upon the failure of openDBChannel or an initial fetch that we need to suspend the app.