¿Cuál es la diferencia entre didChangeDependencies e initState?

10

Soy nuevo en flutter y cuando quiero llamar a mi contexto en InitState, arroja un error: que es sobre, BuildContext.inheritFromWidgetOfExactType pero luego uso didChangeDependencies y funciona correctamente.

ahora tengo 2 preguntas:

1: ¿por qué no podemos llamar a nuestro contexto en initState pero no hay ningún problema para didChangeDependencies? (porque, como leí en el documento oficial This method is also called immediately after [initState], se llamará a ambos antes del método de compilación).

2: ¿por qué tenemos acceso al contexto fuera del método de compilación (porque allí tenemos build(BuildContext context)y podemos usar nuestro contexto, pero en didChangeDependencies no tenemos nada parecido didChangeDependencies(BuildContext context), por lo que podemos llamar al contexto para usarlo)?

flutter dart

— mohammad
fuente

10

El contexto de un estado está disponible para nosotros desde el momento en que el Estado carga sus dependencias.

En el momento en que se llama a build, el contexto está disponible para nosotros y se pasa como argumento.

Ahora avanzando, se llama a initstate antes de que el estado cargue sus dependencias y, por esa razón, no hay contexto disponible y se obtiene un error si usa contexto en initstate. Sin embargo, didChangeDependencies se llama solo unos momentos después de que el estado carga sus dependencias y el contexto está disponible en este momento, por lo que aquí puede usar el contexto.

Sin embargo, ambos se llaman antes de llamar a build. La única diferencia es que uno se llama antes de que el estado cargue sus dependencias y otro se llama unos momentos después de que el estado carga sus dependencias.

— Sanjay Singh
fuente

Pregunta rápida @SanjaySingh initState se llama solo una vez, ¿qué pasa con didChangeDependencies? ¡Porque me he encontrado en un ciclo continuo cuando lo uso! ¡Gracias de antemano por su respuesta!

— abrsh

@abrsh Hey mira, initstate se llama solo una vez cuando primero inicializamos los datos. no podemos llamar a initstate una y otra vez para actualizar los datos porque no hay contexto, por lo que no sabe qué datos actualizar (es decir, inicializar nuevamente). Entonces, para eliminar este problema, hemos cambiado las dependencias que tienen el contexto y sabemos qué datos actualizar. Entonces, SÍ, podemos llamar a didchangedependencies una y otra vez para actualizar / inicializar nuestros datos

— Sanjay Singh

1

De acuerdo con la initStatedocumentación

No se puede usar BuildContext.inheritFromWidgetOfExactTypedesde este método. Sin embargo, didChangeDependenciesse llamará inmediatamente después de este método, y BuildContext.inheritFromWidgetOfExactTypepuede usarse allí.

Así que hay que utilizar BuildContext.inheritFromWidgetOfExactTypeen didChangeDependencies.

Cada widget tiene el suyo context. Es por eso que tiene acceso al contexto fuera del método de compilación.

En cuanto a build(BuildContext context), el buildmétodo acepta contextdesde el widget principal. Significa que este parámetro BuildContext contextno es el contexto del widget actual sino el contexto de su padre.

— Marat
fuente

Gracias, entiendo la segunda respuesta, pero no la primera, conozco este comportamiento, pero ¿cuál es la razón?

— mohammad

didChangeDependencies se llamará inmediatamente después de initState, pero ¿por qué no podemos usar BuildContext.inheritFromWidgetOfExactType en initState? (Estoy entusiasmado por la razón, no por el comportamiento)

— mohammad

-2

La respuesta esta aqui

No se debe llamar a este método desde los constructores de widgets ni desde los métodos State.initState, porque esos métodos no se llamarían nuevamente si el valor heredado cambiara. Para garantizar que el widget se actualice correctamente cuando cambie el valor heredado, solo llame a esto (directa o indirectamente) desde métodos de compilación, devoluciones de llamada de diseño y pintura, o desde State.didChangeDependencies.

— Marat
fuente