Open burtonator opened 3 years ago
burtonator
commented
3 years ago Also, if you guys think this is an acceptable feature I might add it myself if I can bang it out in an hour or so.
I suspect that I might be able to implement it quickly then send a PR...
schmidt-sebastian
commented
3 years ago @burtonator Thanks for filing this! We actually do want to build this feature, but haven't had the chance to prioritize this yet. If you are able to contribute a PR, we would be more than happy to work with you to get it merged and released.
JacobWeisenburger
commented
3 years ago did this feature get added yet?
schmidt-sebastian
commented
3 years ago Not yet, we are still busy working on other projects.
burtonator
commented
2 years ago I'm trying to be constructive here when I'm saying this but you guys have to do a MUCH better job at prioritizing features and fixing bugs.
We've been using Firestore for two years and have had numerous issues with the platform but only once has one of our issues been resolved and that was after months of reporting the problem. Safari was just flat out broken for all of our users for months. We reported the issue over and over and it was only after users piled on did you guys do something about it.
I mean it's super cool that you guys implemented tree shaking in the latest release but I literally do not care about feature.
There are major flaws with Firestore that haven't been fixed in years.
server-side snapshots don't send progress events to clients so I can't show my users any progress on their data on a clean login.
indexes aren't supported in the IndexedDB cache (ironic I know) so we're told to not put much data into the offline cache.
The offline cache, even for simple datasets is bloated and insanely slow. You guys could never ship gmail or another google product on Firestore as it would just be too slow.
Can you please provide a document for us on how you prioritize fixes and features? We've only ever had one feature/fix that you've implemented and it was one where we actively had to point you to the solution to the problem.
Right now, because of these issues, we're probably going to have to migrate away from Firestore and to something like Apollo or Replicache and use Firestore just as a backend database or migrate away entirely.
burtonator
commented
2 years ago Could a Firestore product manager please reach out to me on this issue? I'm burton at getpolarized ... dot io
schmidt-sebastian
commented
2 years ago We understand your concerns and I am sorry that we have not always been able to provide timely updates. We are a pretty small team that is responsible to for a large number of SDKs and as such, we need to prioritize features against both internal and external requests. Adding a feature just to the Web SDK is not a small task as it requires us to add the same feature to all of our supported platforms. That being said, I do think that the feature being asked for here is a valuable addition.
One of the main complaints for our Web SDK was its size, so we fixed that first. The second complaint is its speed, and we are working on this as we speak. Implementing other features would slow down this work and also hinder development of the next generation of functionality that we are working on. onSnapshot(source:Server) can probably be implemented during spare development cycles, but it is difficult to prioritize when the entire team is needed for already committed feature work.
We can reach out via Email for more details.
gabrielnvian
commented
2 years ago Any updates on this feature?
[REQUIRED] Describe your environment
[REQUIRED] Describe the problem
I'm trying to build a workaround for:
https://github.com/firebase/firebase-js-sdk/issues/3993
my idea is to implement our own cache and have our snapshot listeners only resolve from the server.
I'm going to build my own IndexedDB cache to put in front of firestore.
The problem is that if I initialize firestore and tell it to use the local cache it will first read from cache (which is super slow for us) and then read from the server.
for get() I can specify a source with GetOptions as 'default' | 'server' | 'cache'
... but I can't do this with onSnapshot.
I'd like to tell it to use 'server' so that the local cache is skipped for certain queries in favor of our own cache.
After that our caching layer will use a write through so that every onNext updates the local cache with the most recent value and pass the recent value onto the listener.
But I'd really love fro you guys to fix https://github.com/firebase/firebase-js-sdk/issues/3993 ... but even if you do I think this is a good feature to have!
Thanks!