Should I build a local data layer/app state to maintain state in a React Native/Firestore App?

Question

A main selling point of Firestore is the ability to use it as a online/offline source of truth. I\'m using it in this way right now: updating the Firestore document directly on

Answer 1

This not an answer, just a long comment :)

@learningAngular For example, in toggleNotifications just need to call an async action creator and don't worry about putting any logic inside react component.

Instead Redux pattern gives space to do some logics, in this case because user's last moment decision is source of truth so dispatch function would always set a local tempState and updatingStatus before start updating firestore, then after firestore promise either resolved or rejected dispatches an action to reducer to reset updatingStatus. Then a selector would check if updatingStatus is true to just rely on local tempState otherwise rely on listened firestore state. Finally, react component use selector result as currently valid state.

I am not answering this question because I don't have that much experience. I am also curious if a good solution is out there, but this is what I think is the solution at this moment.

Answer 2

I updated the answer with specific learnings, but after a lot of testing, my biggest general learnings so far are

• Latency compensation can be very inconsistent even with the same data and environment. Listeners can take time to "warm up", as is mentioned in other questions. It is hard to have a standard metric here.
• Document size DOES impact latency compensation. Everything else so far is inconclusive.