A taste of the Field Kit

Anyone can list widgets. What separates a reference worth paying for from a free gist is that it tells you when and why, not just syntax — and it names the thing that breaks when you choose wrong. Here is one row from the state-management sheet, then one interview question, both exactly as they appear in the kit.

From the cheat-sheets: when have you outgrown setState?

Two questions decide this, and nothing else does: who else needs this data, and how long must it outlive the widget that made it. Answer those and the tool falls out. App size, team fashion, and the number of screens are not inputs. You've outgrown setState the moment any one of these is true:

• A widget that isn't a descendant needs the value — and the only route you can see is a GlobalKey into another State.
• The data must survive navigation (an emptied cart on pop is a bug, not a feature).
• You're passing a parameter through two or more widgets that never use it.
• You're hand-rolling bool isLoading + String? error + T? data — four representable states for three legal ones.

⚠️ Pitfall: Under compare-based change detection (Riverpod, BLoC), mutating an object in place and re-publishing the same instance produces zero rebuilds — the data changed and the UI didn't. And == dedupe only works on values that implement it: Set/List/Map use identity, so {'m1'} == {'m1'} is false. That one fact is why bloc states are records or use value equality.

From the interview bank: a senior async question

Q. “async runs my code on a background thread so the UI won't freeze — right?”  🔴 Senior

No — and this is the answer that separates people who've shipped from people who've read the docs. async/await is not multithreading. Your code runs on the same isolate, the same single thread as the UI. await doesn't move work anywhere; it just lets the event loop run other things while a Future you're waiting on completes. A heavy synchronous computation inside an async function janks the UI exactly as hard as it would without it — because it's the same thread doing the work. To actually get off the UI thread you need another isolate: Isolate.run or compute.

🎯 What they're really testing: whether you understand Dart's concurrency model, or just its syntax. The naive answer is confident and wrong, which is exactly why interviewers ask it — and why saying “async yields to the event loop, it doesn't spawn a thread” lands so well.

That's the shape of the whole kit: eleven sheets like the first, 112 questions like the second, six mobile system-design walkthroughs, and a night-before recall sheet — every Dart snippet run through the analyzer, and no version pins anywhere, so it doesn't go stale the week after you buy it.