Why Provider Exists

As Flutter apps grow, basic tools like setState() and InheritedWidget start to show limitations.

Problems with setState()

• Works only for local widget state
• Hard to share data across distant widgets
• Leads to prop drilling and tight coupling

Problems with InheritedWidget

• Requires boilerplate code
• Difficult for beginners
• Not ideal for frequent updates or complex logic

Why Provider

• Built on top of InheritedWidget but simpler to use
• Makes shared state easy to expose and listen to
• Helps keep state scalable, testable, and maintainable

The Counter class extends ChangeNotifier, encapsulating the state and logic for incrementing a value. By wrapping your app with a ChangeNotifierProvider, you make the Counter instance available to any widget in the subtree. Widgets can access and react to changes in the state by using context.watch<Counter>(), which rebuilds only the widgets that depend on Counter when the state changes. This approach avoids the manual wiring required with InheritedWidget and the excessive rebuilding that may occur with setState().