He visto un patrón de la biblioteca react-query que hace lo siguiente:
(OOP)
// it instantiates an object from a class const queryClient = new QueryClient()(Manos)
// Then it passes this object as a prop to the provider <QueryClientProvider client={queryClient}> <Todos /> </QueryClientProvider> y en el componente <Todos /> , esta biblioteca le brinda la opción de usar el cliente o usar un gancho.
// Todos
const client = useQueryClient(); // (Hook) const query = useQuery( key, fn, option ); // (Hook) Lo que no puedo entender es cómo esta biblioteca puede mantener su estado sincronizado entre un objeto de clase javascript normal, es decir, el client y el uso de otros ganchos. Lo que quiero decir con eso es, por ejemplo, que puede usar el gancho useQuery con una key como primer argumento y lo que hace este gancho es que ejecuta la función fn y almacena el resultado en una propiedad de data dentro de la query .
La parte divertida es que luego puede usar estos data llamando al siguiente método desde el client .
const { data } = client.getState(key);Entonces, ¿qué hace realmente detrás de escena para mantener sincronizados tanto un objeto JavaScript clásico como ganchos?
const client = useQueryClient(); // (Hook) const query = useQuery( key, fn, option ); // (Hook) // ----> in sync : query.data === client.getState(key).dataEs porque la fuente de la verdad es ese objeto de consulta-cliente. Contiene los cachés (también las clases) y un montón de métodos para acceder a ellos, etc.
Supongo que podría crear una instancia en algún módulo, y luego importarlo y acceder a él si todo lo que quisiera hacer fuera mantener el estado mutable en algún objeto en alguna parte. Pero parte del encanto es casar la llamada de las funciones en caché y el acceso de ese estado para reaccionar: hacer que se llamen las consultas cuando se monte un componente, y hacer que otros componentes que estén interesados en el mismo resultado esperen el mismo resultado. Haga que los componentes recién montados investiguen si los datos están obsoletos. Recuperar datos en un temporizador, pero solo uno para todos los componentes, y así sucesivamente.
La integración en las funciones del ciclo de vida de reacción a través de ganchos (¡todas las bibliotecas de reacción modernas con respeto propio deben tener algunos ganchos!), Porque pueden deslizarse en el ciclo de vida de sus componentes de una manera simple y declarativa: "usar" algún recurso.
Estos ganchos luego emplean ganchos de ciclo de vida reacciona, y el caché y los métodos en QueryClient. Debido a que QueryClientProvider proporciona el queryClient a través de un contexto de reacción, no tiene que exportar/importar su QueryClient instanciado a través de sus módulos, lo encuentran ellos mismos.
Hay un pequeño truco en el nivel superior del módulo que define el contexto de reacción aquí
Hice un pequeño código y caja que puedes ver aquí
Si desea repasar el patrón del observador, puede hacerlo aquí .
Y compare con este tutorial sobre el estado de la aplicación sin contexto.
Además, no olvide cómo el uso de referencias a objetos como parámetros de función puede tener efectos secundarios .