Closed HasanSahabGlobal closed 3 years ago
Hi @HasanSahabGlobal - my best advice is to trace through (via adding logging output perhaps) the code directly in node_modules in the parts that handle the init sequence in order to see exactly how the config is being set / when it is being set so you can see how and why things are configured the way they are during initialization. That can then serve as the basis for making a pull request to fix the issue - the init sequence hops across a couple of objects if I recall correctly but is not hard to trace. While working on the PR, the https://github.com/ds300/patch-package utility can be used to make sure any changes you create that get things working for you are easily distributed among your whole team and are easy to track etc (it really is a fantastic utility)
If you find that the configuration appears to be doing everything correctly then this will have to be tracked into the upstream firebase-android-sdk and firebase-ios-sdk libraries, each of those have "quickstart" projects that let you quickly create a reproducible demonstration of the problem so you can file a ticket with google firebase team for official support
resolved by "keepSynced" but i think it is not an optimal solution.
const ref = database().ref(path);
/**
* keep it synced.
*/
await ref.keepSynced(true);
/**
* get document by ref.
*/
const document: FirebaseDatabaseTypes.DataSnapshot = await ref.once('value');
/**
* return val from document.
*/
return document;
Hello 👋, to help manage issues we automatically close stale issues. This issue has been automatically marked as stale because it has not had activity for quite some time. Has this issue been fixed, or does it still require the community's attention?
This issue will be closed in 15 days if no further activity occurs. Thank you for your contributions.
Closing this issue after a prolonged period of inactivity. If this is still present in the latest release, please feel free to create a new issue with up-to-date information.
Experiencing the same problem. Offline persistent and the use of ".once" is not predictable.
@nes123 if you can provide an App.js we could drop in a project and use to trigger this we might be able to track it down...
My understanding after reading many discussions on that is that this is the intended behavior of the SDK. If persistence is enabled SingeEvent Snapshot will read from the local database. If sync is needed you must use keepSynced(true)
Very non-intuitive and making migration of an online to offline somehow complicated.
That is non-intuitive, I don't know the database behavior well enough to have known that in advance. This seems like something that could be a note on the API for toggling persistence - maybe also .once or keepsynced - there are edit buttons for a quick web-based PR flow on the top right of all the general usage and specific API docs if you can think of a good place to put this. A link back to any of the upstream docs that mention it would be gold too, could probably save others a lot of confusion
public Task
Gets the server values for this query. Updates the cache and raises events if successful. If not connected, falls back to a locally-cached value.
Any ideas if it is implemented in react-native-firebase?
I'd be happy to work with you on a PR @nes123! Please post one up and we can get it merged here
I started something. I have zero experience in native programming so it is very naive. Please feel free to assist. I will work on that again tomorrow.
as mentioned in docs, persistence is enabled by default, it is not working. it is working only if enabled manually by "database().setPersistenceEnabled(false)" function, it works well (persists data and works offline). but, this STOPS receiving updates from online Firebase database. (This issue appears on both platforms).
package.json
:firebase.json
: