Empresas
Empleos
  • Sobre nosotros
  • Soluciones
    • Publicación de vacantes
      Publica tu vacante y recibe candidatos calificados en 48h.
    • Evaluación de candidatos
      500+ pruebas técnicas y psicológicas, más anti-fraude.
    • Headhunting
      Búsqueda ejecutiva a la medida de principio a fin.
    • Nómina + EOR
      Dispersión de nómina y EOR en más de 15 países de LATAM.
  • Precios
  • Empleos

0

599
Vistas
Caching/persisting data in React Native

During my development career in React, I have seen that we can use multiple kinds of cache/persistance in a RN App.

  1. The first one, which is directly provided by react native, is AsyncStorage. This allow us to store data in the user device's persistence.

  2. 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.

  3. 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 caches? For example, take a look at my "usersCache.js", where I store the users 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 (inside components, or anywhere in the frontend) is product of a bad organization or an anti-pattern?

Any tips or advices?

about 4 years ago · Juan Pablo Isaza
Responde la pregunta
Encuentra empleos remotos

¡Descubre la nueva forma de encontrar empleo!

Top de empleos
Top categorías de empleo
Empresas
Publicar vacante Precios Comercial
Legal
Términos y condiciones Política de privacidad
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Recomiéndame algunas ofertas
Necesito ayuda