Comprender el ciclo de vida de los widgets de Flutter para un desarrollo eficaz de aplicaciones

En términos generales, el ciclo de vida representa la etapa desde su creación hasta su destrucción. En el contexto de flutter, es lo mismo. Hoy hablaremos sobre el ciclo de vida del widget (no lo confunda con el ciclo de vida de la aplicación).

Como desarrollador de aleteo, la intención principal de este artículo es cómo debemos utilizar esos métodos de ciclo de vida, así que pasemos a la parte divertida.

crearEstado()

Cuando creamos un widget con estado en Flutter, el createStatemétodo se llama inmediatamente para devolver una instancia de estado de la clase asociada.

Esto es esencial porque, en Flutter, todo es inmutable (incluidos los widgets con estado). Es importante separar la tarea de mutabilidad y delegarla a la clase de estado. De esta forma, Flutter puede hacer que las clases inmutables se vean y funcionen como mutables, y podemos ver todos los cambios en la interfaz de usuario.

Esto también tiene un beneficio de rendimiento, ya que es más fácil para Flutter cambiar una variable de estado y reflejar el cambio de manera optimizada que recrear todo el árbol de widgets debido a pequeños cambios.

class HomePage extends StatefulWidget {
  @override
  _HomePageState createState() => new _HomePageState();
}

Este es el primer método llamado creación de estado posterior. Y se llama una sola vez.
Este método se puede utilizar para:

1. Inicializar variables tardías
2. Suscríbete a la transmisión, etc.

@override
initState() {
  super.initState();
  _controller=TextEditingController();
  myStream.listen((data) {});
}

Entonces, ¿cuál es exactamente su dependencia?
Digamos que usamos MediaQuery.of en un widget, entonces podemos decir que nuestro widget depende de MediaQuery. Entonces, cada vez que MediaQuery actualiza, este método se activa.

Entonces, podemos decir si nuestro widget depende de Inherited Widget(consulta de medios, tema, proveedores, etc.) y cada vez que esos widgets heredados envíen actualizaciones, activará este método.

Después de que este build()método se active, por lo que, como desarrollador, no hay muchos escenarios en los que tengamos que usar una lógica personalizada aquí, pero según la documentación oficial, dice

hacer un trabajo costoso (por ejemplo, búsquedas de red) cuando cambian sus dependencias, y ese trabajo sería demasiado costoso para cada compilación.

Por ejemplo: de su Inherited Widgetpuede recibir algún valor y necesita hacer alguna operación costosa basada en ese valor y mostrarlo en la interfaz de usuario. Es posible que no desee hacer esto en el método de compilación, por lo que didChangeDependenciesserá el lugar perfecto para esto.

HizoActualizarWidget

Pongamos un ejemplo para entender esto. Tienes un Containerque es de color rojo y con un toque de botón lo cambias a azul.

Aquí, tanto las instancias de objetos antiguas como las nuevas son del mismo tipo runtimeType , pero los datos son diferentes, por lo que en este caso se activa este método. También recibe widgets antiguos didUpdateWidget(Widget oldWidget).

@override
void didUpdateWidget(Widget oldWidget) {
  if (oldWidget.color != widget.color) {
  /// Your logic
  }
}

• Un posible escenario podría usarse en animación para la transición entre valores.
• Otro podría ser un caso de uso específico basado en el requisito de su aplicación, según el valor del nuevo widget, realice algunas tareas diferentes, por ejemplo: suscribirse a una nueva transmisión y cancelar la suscripción a una transmisión anterior.

construir()

Este es el método importante en el que, como programadores, debemos devolver el widget que queremos mostrar al usuario.

Además, este método puede activarse varias veces, por lo que no es una buena práctica realizar tareas costosas dentro de este método.

Este método se puede llamar potencialmente en cada cuadro y no debería tener ningún efecto secundario más allá de la creación de un widget.

establecerEstado((){})

setState((){}) es un método que toma un método como parámetro y llama internamente al markNeedsBuild()método para desencadenar una nueva compilación.

/// Implementation of setState() in flutter 
@protected
void setState(VoidCallback fn) {
  final Object? result = fn() as dynamic;
  _element!.markNeedsBuild();
}

• no debemos pasar una función asíncrona a setState ya que internamente no esperará a que se resuelva el futuro, por lo que no veremos el reflejo de la interfaz de usuario deseado.

setState(() {
  /// New State values
  color=Colors.red;
});

Se llama al método dispose() cuando se elimina el objeto de estado. Este es el último método para activarse en el ciclo de vida.

Entonces, como desarrollador, podemos:

1. Darse de baja de las transmisiones
2. Deseche los controladores
3. Detener animaciones, etc.

Dado que el widget sin estado no tiene su propio estado mutable (obvio por el nombre), aquí faltan algunos métodos de ciclo de vida, por ejemplo initState, etc.dispose

Fuentes:
https://www.youtube.com/watch?v=_gIbneld-bw
https://api.flutter.dev/index.html