Gestión de estado
Decidir dónde vive un dato y a quién hay que avisar cuando cambia
Gestión de estado
El tema tiene mala fama, alimentada por la cantidad de soluciones que compiten entre sí y por los debates que suscitan. Conviene disipar esa fama desde el principio: el problema real no es elegir entre tres bibliotecas, sino responder a una pregunta sencilla para cada dato de tu aplicación. ¿Quién lo necesita?
Una casilla de verificación solo le interesa a la fila que la contiene: setState basta, y cualquier otra cosa sería una complicación gratuita. El carrito de la compra, en cambio, lo leen la lista de productos, el badge de la barra superior, la pantalla de pedido y la pantalla de pago: cuatro lugares que no comparten ningún ancestro común cercano. Pasar el carrito de constructor en constructor a través de seis niveles de widgets funciona, pero produce un código en el que el menor cambio afecta a diez archivos. Este fenómeno tiene nombre, el prop drilling (paso de propiedades a través de muchos niveles), y es él, no setState, el que justifica la existencia de Provider.
Esta lección sigue exactamente esa progresión: setState y lo que hace bien, el muro con el que choca, InheritedWidget, que es el mecanismo del framework para superarlo, y por último Provider, que lo envuelve de una forma utilizable en el día a día. Al terminar, tendrás un criterio de decisión, no una preferencia.
Comentarios
Los comentarios funcionan con GitHub Discussions
Inicia sesión con GitHub para participar en la discusión