During my development career in React, I have seen that we can use multiple kinds of cache/persistance in a RN App.
-
The first one, which is directly provided by react native, is AsyncStorage. This allow us to store data in the user device's persistence.
-
Also we can develop our own in-memory cache, which can improve the performance of our app by avoiding making unnecessary requests to our server.
-
And the last one, which for me is not a cache, is React Context. This tool is cool for having our app routes synchronized. For example, the typical UsersProvider, a context where we can store users data. I have seen some coders using this tool as a "cache" too.
My question here is about clean code. In a React architecture that combines these 3 "tools", how can we correctly delegate the use of all of them to each section of our app?
For example, in a project that have the following folders
components/
auth/
AuthForm.js
contexts/
users/
UsersContext.js
screens/
Profile/
EditProfile.js
services/
api/
firebase/
content/
getContentFeed.js
cache/
contentCache.js
users/
getUserData.js
cache/
usersCache.js
Without looking at the third tool, contexts, which are exclusively consumable/accessible from hooks/components, where should each "memoizer" (AsyncStorage and in-memory caches) be used without violating any pattern or "clean code" rule?
Is AsyncStorage designed to be used everywhere? I mean, inside components, hooks, contexts, classes, utils, helpers, apis, ... with complete freedom?
What about in-memory cache? For example, take a look at my "usersCache.js" where I store the user data that I get from the server. As you can see, I have defined my own api to make requests to the backend... So, if in my "getUserData.js" I am storing/getting/updating data from my cache, to avoid making unnecessary requests, do you think that using this kind of cache outside the api (in a components, or anywhere in the frontend) is product bad organization or an anti-pattern?
Any tips or advices?
Aucun commentaire:
Enregistrer un commentaire