0%
State Management

State Management

Deciding where data lives, and who should be notified when it changes

15-20 min

State Management

The topic has a bad reputation, fueled by the number of competing solutions and the debates they spark. Let's clear that up right away: the real problem isn't choosing between three libraries, it's answering one simple question for each piece of data in your application. Who needs it?

A checkbox only matters to the row that contains it: setState is enough, and anything else would be gratuitous complication. The shopping cart, on the other hand, is read by the product list, by the badge in the top bar, by the checkout screen, and by the payment screen — four places that share no close common ancestor. Passing the cart down from constructor to constructor through six levels of widgets works, but it produces code where the slightest change touches ten files. This phenomenon has a name, prop drilling, and it is what motivates Provider's existence, not setState.

This lesson follows exactly that progression: setState and what it does well, the wall it runs into, InheritedWidget, which is the framework's mechanism for getting past it, and then Provider, which wraps it in a form that's practical for everyday use. By the end, you'll have a decision criterion, not just a preference.

Comments

Comments are powered by GitHub Discussions

Sign in with GitHub to join the discussion

Link copied!