CODEWITHSUNDEEP
reactjsreact-nativegoogle-cloud-firestorefirebase-authenticationexpo
AB123
AB123

Reputation: 1

When to use react native Context vs. Async Storage

Tech stack: firebase firestore & auth, react native, expo

Question that I can’t seem to answer by googling:

After you authenticate a user with firebase auth you get a user Id and it’s written to a react native context (AuthContext) with a useState hook by calling setUser from a line like this: const [user, setUser] = useState()

When you add fields to a user object like name, email etc do you store that info in the user auth context too? Or in async storage (or some other local storage)? (in addition to writing it to the database)

TLDR: When do you use RN context vs. asyncstorage to store user info?

I tried lots of reading docs and other peoples code on the internet

Upvotes: 0

Views: 363

Answers (1)

adsy
adsy

Reputation: 11567

Typically you would probably use context for this, with a pointer to the ID in async storage loaded into that context on mount. The problem with loading all of the details from a central global storage like AsyncStorage in each component that needs it is that you now have several copies of it lying around in memory. That might not be a big deal, but if you were to need to, say, change the user name (imagine if the user has an edit profile screen), you don't have one canonical copy to change in one location and know 100% it will be reflected everywhere.

Practically speaking it probably wouldn't make much difference because any screen using the "username" for example would be remounted and load it again from the storage when they hit it. But it's bad practice. Let's imagine you now have the username displayed in the navbar for whatever reason, which is rarely (if ever) unmounted. Now the user changes their user name -- that thing is going to be displaying the old one still and you can't make a call in one place to change it and not worry about all the places it's used.

Note it's ok to use AsyncStorage if you want to persist a users session. But you'd probably persist only the user id or auth token there, and the context would make a call to the server using that ID to fetch the other details. Those details would be kept in memory only in the context. The reason for this is if they change their secondary details on another device, and open the app again, the changes will be reflected.

tldr; Store an ID/auth token of the user only in storage, and have a context provider that fetches the rest of the data from server using that and provides it into that context.

Upvotes: 2

Related Questions