restate / v1.0.0
Preguntas frecuentes
Respuestas a preguntas habituales sobre renders, guardado, scopes y errores en restate.
No hay preguntas que coincidan
Prueba con otra palabra o muestra todas las preguntas.
Básico¿Necesito un Provider?
No. Un store es un valor a nivel de módulo; cualquier componente que lo importe puede usarlo. Usa useRestateScope cuando el estado deba pertenecer a una instancia de componente.
Básico¿Por qué mi componente se renderiza en cada cambio?
Llamar al hook sin selector suscribe al valor completo. Pasa un selector que devuelva solo lo que muestra el componente.
BásicoMi selector devuelve un objeto y se renderiza cada vez.
Un objeto nuevo nunca es igual por Object.is al anterior. Pasa shallow como segundo argumento o selecciona los campos por separado.
BásicoCambié un objeto pero no se actualizó nada.
set recibió el mismo objeto, así que restate no vio ningún cambio. Devuelve un objeto o array nuevo desde set.
Guardado¿Dónde espero los datos guardados?
Una vez, en la entrada del cliente: haz await restateManager.ready antes de renderizar la app. Después, los componentes leen directamente los valores guardados. Los stores de un useRestateScope esperan a su propio scope.manager.ready.
Guardado¿Cuándo se escriben los datos en el almacenamiento?
Solo cuando llamas a save() o, con autoSave activado, después de los cambios. Editar cambia la memoria; status().dirty te indica que hay cambios sin guardar.
Guardado¿Uso autoSave o save()?
Usa autoSave para ajustes y borradores que siempre deben persistir. Usa save() cuando decide el usuario, como con un botón Guardar o al enviar un formulario. Puedes llamar a save() aunque autoSave esté activado, por ejemplo en pagehide.
ErroresrestateManager.ready se ha rechazado. ¿Y ahora?
Se rechaza con BULK_OPERATION_FAILED cuando un registro no se pudo leer, migrar o validar. error.failures indica cada store y su error. Arregla o borra el registro, llama al initialize() de ese store y vuelve a acceder a ready.
ErroresVeo QUEUE_FULL o STORAGE_TIMEOUT.
El almacenamiento es más lento que el trabajo que encolas. Evita llamar a save() en un bucle cerrado —un guardado en espera ya toma el valor más reciente— o usa autoSave con una espera. Ajusta maxPendingOperations y operationTimeoutMs si hace falta.
ErroresUna petición tardía escribe en un store tras el desmontaje.
set() y reset() en un store destruido se ignoran, como una actualización de estado de React tras el desmontaje. Suscribirse lanza STORE_DESTROYED y los comandos de almacenamiento se rechazan.
ScopesMi store con scope ignora las props nuevas.
La factoría se ejecuta una vez, como un inicializador de useState. Renderiza el componente con una key por documento para que cada documento nuevo tenga un scope nuevo.
Scopes¿Cómo evito discrepancias de hidratación?
Pasa los mismos datos del servidor como props en el servidor y en el cliente, y crea el store a partir de ellos en useRestateScope. El valor inicial se convierte en el snapshot del servidor.
Scopes¿Por qué mi store con scope no está en restateManager.ready?
Los stores guardados con scope empiezan a cargarse cuando el componente dueño se confirma en el cliente. Espera a scope.manager.ready en un límite de carga dentro de ese componente.
GuardadoMMKV_UNAVAILABLE en React Native.
Instala react-native-mmkv y sus dependencias nativas y vuelve a compilar la app. En Expo, usa una development build. Los stores en memoria funcionan sin MMKV.