En «React de verdad» aprendiste useState y a mantener un dato en pantalla. Ahora la distinción que ordena todo lo demás: no todo el estado es igual.
Hay datos que son tuyos y viven en el navegador: si un menú está abierto, lo que llevas escrito, qué pestaña miras. Es el estado del cliente. Aparece al instante, lo cambias tú y desaparece al recargar.
Y hay datos que son una copia de algo que vive en un servidor: la lista de pedidos, tu perfil, los mensajes. Es el estado del servidor. No es tuyo, es prestado. Se queda viejo, otra persona puede cambiarlo mientras miras, y llega con retraso, así que tiene que contar también con la espera y con el fallo.
Tratar los dos igual —meter la copia del servidor en un useState y creer que ya está— es el error que pudre una app según crece: datos que no se refrescan, pantallas que mienten, botones que hacen doble.
Un caso de todos los días: cargas la lista de pedidos en un useState al abrir la pantalla. Un compañero marca uno como enviado desde su ordenador. El tuyo lo sigue enseñando pendiente hasta que recargas a mano. Nadie te avisa: la copia se quedó congelada en el instante en que la pediste.
Bien
El estado del servidor lo lleva algo que sabe volver a pedirlo: se refresca al volver a la pestaña o cada cierto tiempo.
Mal
El estado del servidor metido a mano en useState: se pide una vez y se queda ahí, viejo, hasta que alguien recarga.
Guárdalos como dos cajas distintas en la cabeza. El cliente es rápido y frágil. El servidor es lento y compartido.
Cuándo da igual: si un dato no cambia nunca —la lista de provincias, un texto fijo— tenlo donde quieras; no envejece porque no se mueve. La distinción solo pesa cuando el dato se comparte y cambia sin que tú lo toques.
Hoy: abre tu app y reparte cada dato en una de las dos cajas. Los que caigan en «servidor» son los que en la próxima lección aprenderás a pedir bien, con su espera y su fallo. En las que siguen: formularios que llevas tú, contexto sin abusar, enseñar el resultado antes de que llegue y que la pantalla no se congele.