From 178f36286f3b389400e840339a08b5f369f50194 Mon Sep 17 00:00:00 2001
From: Ansh___Bhardwaj
 <93034097+01000001x01001110x01010011x01001000@users.noreply.github.com>
Date: Sat, 5 Jul 2025 17:26:34 +0530
Subject: [PATCH] Update en-US.mdx

docs: enhance didChangeDependencies() & didUpdateWidget() explanations

- Simplify definitions for beginners with concrete examples
- Clarify where to place custom code (before/after `super` call) when overriding
---
 .../en-US.mdx                                 | 90 +++++++++++++++++--
 1 file changed, 85 insertions(+), 5 deletions(-)

diff --git a/questions/what-are-statefulwidget-lifecycle-methods-explain-briefly/en-US.mdx b/questions/what-are-statefulwidget-lifecycle-methods-explain-briefly/en-US.mdx
index 65a29c9..4963345 100644
--- a/questions/what-are-statefulwidget-lifecycle-methods-explain-briefly/en-US.mdx
+++ b/questions/what-are-statefulwidget-lifecycle-methods-explain-briefly/en-US.mdx
@@ -1,19 +1,99 @@
----
-title: What are `StatefulWidget` Lifecycle methods. Explain briefly.
----
 
 - **createState() method:** Whenever a StatefulWidget is created, the framework calls this method to create fresh State objects. This method must be overridden.
 
 - **initState() method:** This method is the first method that is called while creating a StatefulWidget class. Here we allocate our resources, which means we can initialize our variable, data, and properties.
 
-- **didChangeDependencies() method:** This method is called just after initState() method when a dependency of this State object changes. For example, if the previous build was referencing an InheritedWidget that changes, this method notifies the object to change. Generally, subclasses don't override didChangeDependencies() method because the framework calls build() methods after dependency change. But to do some expensive work, let's say some network calls, the method is preferred over doing everything on build() method itself.
+- **didChangeDependencies() method:** Called immediately after `initState()` and again whenever an `InheritedWidget` that this `State` depends on changes (e.g., `MediaQuery`, `Theme`, or a localized resource). Ideal for context-dependent initialization or expensive work that shouldn’t run on every build.  
+  ```dart
+  @override
+  void didChangeDependencies() {
+    super.didChangeDependencies();  // **Annotation:** must call super
+    final locale = Localizations.localeOf(context);
+    // Fetch or update data based on current locale
+  }
 
 - **build() method:** Every time the widget is rebuilt, the build() method is used. This can happen after calling initState(), didChangeDependencies(), or didUpdateWidget(), or after changing the state with a call to setState().
 
-- **didUpdateWidget() method:** This method is called whenever the widget configuration changes. This method exists for triggering side-effects when one of the parameters in the StatefulWidget changes. A typical example is implicitly animated widgets.
+- **didUpdateWidget() method:** Called whenever the parent widget rebuilds and supplies a new instance of this widget with updated properties. Override it to compare oldWidget vs. widget and trigger side-effects when specific parameters change, without recreating the whole State.
+  ```dart
+  @override
+  void didUpdateWidget(covariant MyWidget oldWidget) {
+    super.didUpdateWidget(oldWidget);  // **Annotation:** must call super
+    if (oldWidget.userId != widget.userId) {
+      fetchUserData(widget.userId);
+    }
+  }
 
 - **setState() method:** This method notifies the framework that the internal state of this object has changed. The provided callback must be synchronous which might impact the user interface in the subtree. The framework schedules a build() for this current State object.
 
 - **deactivate() method:** The framework calls this method when the State is removed from the tree, temporarily or permanently.
 
 - **dispose() method:** This method is called when the State is removed from the tree, permanently. After the dispose() method is called, the State object is considered unmounted. Subclasses should override this method to release any resources retained by this object.
+
+# NOTE - 
+- When overriding Flutter lifecycle methods, it’s crucial to know **where** to place your own code relative to the `super.methodName()` call. 
+## The rule of thumb is:
+
+- **Initialization methods**: `super` **first**, then your code  
+- **Teardown methods**: your code **first**, then `super`
+
+## Initialization Methods
+
+These methods prepare both Flutter’s internals and your own state. Always let Flutter finish its setup before you start:
+
+### `initState()`
+
+```dart
+@override
+void initState() {
+  super.initState();      // 1. Flutter’s setup
+  // 2. Your initialization (controllers, listeners, etc.)
+}
+````
+
+### `didChangeDependencies()`
+
+```dart
+@override
+void didChangeDependencies() {
+  super.didChangeDependencies();  // 1. Update inherited dependencies
+  // 2. Context-dependent initialization (e.g. fetch localized data)
+}
+```
+
+### `didUpdateWidget()`
+
+```dart
+@Override
+void didUpdateWidget(covariant MyWidget oldWidget) {
+  super.didUpdateWidget(oldWidget);  // 1. Flutter swaps widget instance
+  // 2. Compare oldWidget vs. widget, trigger side-effects
+  if (oldWidget.userId != widget.userId) {
+    fetchUserData(widget.userId);
+  }
+}
+```
+
+---
+
+## Teardown Methods
+
+When cleaning up, reverse the order: undo your additions before letting Flutter unmount:
+
+```dart
+@override
+void dispose() {
+  // 1. Clean up your resources (controllers.dispose(), remove listeners…)
+  myController.dispose();
+  super.dispose();      // 2. Flutter finalizes unmounting
+}
+```
+
+```dart
+@override
+void deactivate() {
+  // 1. Undo temporary hooks or animations
+  subscription.cancel();
+  super.deactivate();    // 2. Flutter removes this State from tree
+}
+```