Comprendiendo el manejo de estado y por que nunca lo harás…
Que tal amigos del universo de Flutter en este post escrito por Matt Carroll (pueden ver el original aquí), se habla acerca del state managment. Antes de iniciar con la traducción solo quiero comentarles de la importancia de comprender este concepto.
Una de las preguntas mas comunes es, ¿Qué arquitecturas existen en Flutter? y para esa pregunta se te puede dar en claro diciendo (por nombrar la mas común y la que casi todos recomienda) BLoC, pero también existe RxVMS, algunos utilizan Redux y también pueden hablar de MVC, les recomiendo visitar el Github de Brian Egan y su repo de arquitecturas en Flutter aquí podrán ver ejemplos de las que se han utilizado y las que pueden aprender.
Ya como ultimo, para iniciar con la traducción hablemos de una segunda pregunta que se hace, ¿Cual es la mejor arquitectura? bueno eso pueden depender de muchas cosas, quizá primero debamos saber el tamaño de nuestra app antes de querer saber cuando arquitectura se ajusta mas a nosotros o bien que tanta información de pasara entre pantallas o en fin.. muchas interrogantes, mi recomendación es trabajen en papel primero conozcan las ventajas de usar una arquitectura u otra y tendrán su respuesta, alguien que no sabe de su proyecto difícilmente les dará una respuesta certera, solo sera una guía según la experiencia que el tenga.
Este post es una perspectiva personal y de ninguna manera representa el punto de vista u opinion del equipo de Flutter, o mas abiertamente Google.
Manejo de Estado es un tema intenso en la comunidad de Flutter.
y así, y así y así…
Por que es este tema tan popular? Por que todos parecen estar confundidos al respecto? Por que hay tanto desarrolladores rogando por soluciones para "manejo de estado"?
Empecemos con los básicos.
¿Qué es estado?
Si le pregunto a 100 developers que definan “estado,” terminare con muchísimas repuestas:
- Los datos (lo que sea que es eso!).
- Todas las variables en todos los StatefulWidgets.
- Todas las variables en la aplicación completa.
- Un almacenamiento, como Redux o Flux.
- El comportamiento de la app, en un tiempo especifico(Esta es mi definición!).
¿Qué es manejo de estado?
Si le pregunto a 100 developers que definan “manejo de estado,” terminare con muchísimas repuestas:
- Algo como Redux o Flux o BLoC (Siempre existen algunos developers quienes piensan que hacer una lista de ejemplos es lo mismo que definir un concepto).
- Como los datos entran y salen de un almacenamiento.
- Como la información fluye a través de un sistema.
- Como la lógica de negocios interactúa con la UI.
- Bases de datos.
- Arquitectura Hexagonal.
- Quien sabe? (esta es mi definición)
Estas confundiendo tantos conceptos!
Debates acerca de “manejo de estado” son un ejercicio demostrando la importancia de las palabras y las definiciones. el poco definido concepto de manejo de estado es una amalgama de numerosos comportamientos independiente.
- Persistencia de datos
- Flujo de información
- Paradigmas de programación
- I/O (especialmente en caché y networking)
- Arquitectura de la aplicación
- Comportamiento de presentación
- Templates de UI
- etc.
No encontraras una solución universal para ninguno de los comportamientos individuales listados arriba.Tampoco encontraras una solución universal para TODOS los comportamientos listados arriba. Y eso es bueno, por que si esta solución existiera, tu trabajo como desarrollador de software seguramente no.
Por lo que puedo decir, "manejo de estado" esun termino que atrapa todo el cual realmente significa "ingeniería de software". Por lo tanto, cuando vemos que los desarrolladores preguntan “¿Cómo manejo el estado?” o “¿Cómo maneja Flutter la gestión del estado? No lo sé, ¿cuántos años tengo para responder a tu pregunta?
Comunicándose más efectivamente y obtener respuestas a sus preguntas
Si te has encontrado preguntando cómo “manejar el estado” y no estás contento con las respuestas, es porque nadie sabe realmente a qué te refieres.
Si quieres saber cómo hacer llamadas de red y guardar los resultados en caché, pregúntaselo.
Si quieres configurar una tienda centralizada al estilo Redux dentro de tu aplicación, entonces pregúntale.
Si quieres entender los fundamentos de cómo hidratar una jerarquía de widgets de Flutter con información, entonces pregúntalo.
Si quieres saber cómo otros han establecido sus reglas de negocio y relaciones, y vincular esos artefactos a la jerarquía de widgets de Flutter, entonces pregúntale.
Si desea comprender las diversas formas en que se pueden integrar las capacidades de hardware como audio, acelerómetros o Bluetooth, pregúntalo.
El paso importante que debe dar es investigar a fondo la raíz de su pregunta. Si no pudieras usar las palabras “manejar” o “declarar”, ¿cómo harías la misma pregunta?
No venda en corto su negocio
Más allá del tema de la concisión, recuerda que la razón por la que estás escribiendo código es para producir algún tipo de producto o servicio. Ese producto existe en algún tipo de categoría:
- Mensajeria
- Finanzas
- Transporte
- Entretenimiento A/V
- Medio Social
- etc.
La razón por la que estas categorías se diferencian es porque cada una de ellas representa una propuesta de valor única, dirigida a una base de clientes única, que proporciona características únicas, satisface expectativas únicas y posiblemente aprovecha una tecnología única.
Es raro que un desarrollador reconozca su negocio cuando hace una pregunta, y es igualmente raro que un desarrollador reconozca su negocio cuando responde a una pregunta. Esto significa que los desarrolladores de medios sociales pueden estar utilizando patrones y arquitecturas que fueron diseñados para la industria del transporte. ¿Es probable que sea una buena idea, en general?
Recuerda que estás construyendo algo para tu empresa, tu producto y tus clientes. Las reglas de negocio y las relaciones dentro de su producto, compañía e industria son mucho más importantes que si usted obliga o no a una tienda Redux a entrar en su aplicación!
Avanzando con Flutter
Señalar los errores y la confusión no es suficiente para ayudarte a evitar esos errores y confusión, así que hablemos de cómo podrías acercarte al pantano de la “manejo de estado” en Flutter.
Aprende los límites de Flutter
Intento siempre señalar en mis presentaciones de Flutter que Flutter no es un framework de trabajo de aplicación, es un kit de herramientas de interfaz de usuario portátil.
Construyes interfaces de usuario en Flutter, no características. Por lo tanto, es crítico que entiendas dónde termina Flutter y dónde comienza tu aplicación.
Flutter consiste, principalmente, en un árbol de widgets. Eso es más o menos todo. Flutter también trae canales de método para tener conversaciones con Java/Kotlin/Obj-C/Swift, pero eso es sólo un efecto secundario de Flutter usando Dart — esos canales de comunicación no son una característica fundamental de Flutter.
Cuando quieras usar Flutter para una pantalla o una aplicación, muestra un árbol de widgets de Flutter. Dentro de Flutter, compones widgets existentes en este árbol, creas widgets personalizados y los compones en este árbol, reconstruyes este árbol cuando quieres que cambien los píxeles, y eso es casi todo lo que Flutter está hecho para hacer. Más allá del árbol de widgets, deberías hacer lo que sea necesario para implementar las características que son exclusivas de tu aplicación.
La única pregunta que surge de esta revelación es cómo un desarrollador puede obtener información en este árbol de widgets, y cómo sacar los eventos del árbol. Afortunadamente, Flutter proporciona algunas herramientas para ayudarte en el límite.
Aprenda las herramientas de Flutter en el límite
Cuando se trata de inyectar información en un árbol de widgets Flutter, los desarrolladores son siempre bienvenidos a enviar valores al widget de nivel superior y luego pasar esos valores al árbol como se desee. Sin embargo, este enfoque es tedioso, fácil de arruinar y tiende a combinar cosas que de otra manera serían independientes.
InheritedWidget es una herramienta que Flutter proporciona para ayudar con este tema de la hidratación del árbol de widgets. InheritedWidgets permite a los widgets situados en la parte inferior del árbol mirar hacia arriba, obtener una referencia a un antepasado, y también reconstruirse cada vez que ese antepasado cambia. Theme.of() y Navigator.of() son ejemplos de InheritedWidgets.
InheritedModel es otro sabor de InheritedWidget, pero InheritedModel permite que otros widgets sólo se reconstruyan cuando un “aspecto” particular de los datos en el InheritedModel cambia. Esto es principalmente una optimización del rendimiento.
StreamBuilder es un widget que puedes colocar en tu árbol de widgets que se reconstruye cada vez que se recibe un objeto en una secuencia.
Cuando llegue el momento de obtener información de su árbol de widgets, normalmente comenzará con un GestureDetector, un button, un textfield o algún otro widget que reconozca la interacción del usuario. Esto representa el evento que debería activar algún comportamiento en su código. Todos estos widgets aceptan funciones de devolución de llamada que pueden hacer lo que quieras.
Dentro de una función de devolución de llamada, puedes elegir invocar un método en un objeto que tengas en tu widget. O puede recuperar estáticamente un singleton e invocar un método en él. O puede tomar una referencia a un objeto usando un InheritedWidget (como se mencionó anteriormente) e invocar un método en él. Cualquiera que sea el camino que elija, los pasos tienden a ser los mismos:
- Registro para entradas de usuario con un callback.
- El callback es llamado.
- Traer una instancia de un objeto Dart regular que es parte del comportamiento de tu aplicación.
- Llamar al métodos en el objeto que quieres ejecutar en respuesta a la entrada del usuario.
With these boundary tools at your disposal, you can now decide for yourself whether you want to implement Redux, BLoC, a data model, a domain model, a hexagonal architecture, or something completely bespoke.
Aprende por qué existen Redux y BLoC
Los desarrolladores son rápidos en saltar sobre los vagones de banda de Redux y BLoC. Realmente se propagan “viralmente”. No hay nada malo con ninguno de estos paradigmas, ni habrá nada malo con el siguiente paradigma en el que todos salten. El problema es el proceso de decisión (o la falta de éste) para usar estos paradigmas.
¿Sabías que Redux no era inicialmente más que una forma de implementar viajes en el tiempo en JavaScript?
Claro, Redux es mas que solo experimental, actualmente, pero la historia y contexto es importante.
¿Qué tal el patrón BLoC?
El equipo de AdWords de Google quería utilizar Flutter para sus aplicaciones móviles. El equipo también quería compartir la lógica de negocio con sus aplicaciones web AngularDart. El equipo de AdWords ideó el concepto de componentes de lógica empresarial (BLoC) para resolver este problema. Presentaron los BLoCs públicamente a principios de 2018
Más tarde en 2018, Matt y Filip del equipo de relaciones con los desarrolladores de Flutter querían proporcionar a los desarrolladores de Flutter algo de inspiración sobre cómo podrían integrar la lógica de negocio con su árbol de widgets de Flutter. Matt y Filip analizaron lo que varios equipos de Google estaban haciendo para resolver este problema y descubrieron las BLoCs. A su vez, presentaron los BLoCs en la I/O 2018 como un ejemplo concreto de cómo los desarrolladores pueden optar por integrar las reglas de negocio con los widgets de Flutter.
Este patrón no surgió de algún laboratorio de investigación de Stanford, ni se hornea en Flutter. El patrón BLoC es sólo uno de muchos enfoques, pero debido a que fue presentado en un gran evento de Google, parece haber sido consagrado como una especie de solución oficial de “manejo de estado” de Flutter que todo el mundo debería aprender y utilizar. Pero ahora lo sabes mejor que nadie!
Así que elige lo que quieras. Redux, BLoC, modelos de datos, modelos de dominio, arquitectura hexagonal, etc. Pero asegúrate de saber por qué lo estás usando, y asegúrate de saber dónde termina Flutter y dónde comienza tu aplicación. El verdadero problema con todas estas preguntas sobre Flutter y la “manejo de estado” es que indican que la mayoría de los desarrolladores no entienden el árbol de widgets de Flutter lo suficientemente bien como para responder por sí mismos. Cuando te sientas realmente cómodo moviendo información dentro y fuera de un árbol de widgets Flutter, esta pregunta se volverá aburrida y mayormente irrelevante. Te preguntarás por qué lo preguntaste.
Bueno amigos del universo de Flutter, ahora ya tiene un poco mas de información acerca de que es el manejo el estado y todo un listado en la cuenta de Brian Egan de algunos de los que existe, de donde nació BLoC pattern y todo lo que puedan tomar de esta lectura.
Les recomiendo enormemente sigan a Matt Carroll o como es conocido en sus cuentas de Twitter y su canal de Youtube aprenderán muchísimo y claro us post aquí en Medium
Nos leemos pronto les dejo mi cuenta de Twitter donde siempre estoy compartiendo información de Flutter y Dart, algunas veces de GoLang.
Y mi repo en Github en el que estaré subiendo pequeños ejemplos, pero funcionales, de muchas de las pequeñas dudas que van saliendo en redes sociales.
No dejen de aletear!
