State & Reactivity
Who owns a value, how a runtime learns it changed, what equality makes the change visible, and what re-runs afterward. Interviewers start here because most update bugs trace to one of those links.
on this pageshowhide
explore
- State Ownership & Lifting5 questions
- Change Propagation Models6 questions
- Derived Values & Memoization5 questions
- Immutable Updates & Equality6 questions
- Stores & Subscriptions6 questions
- Effects & External Sync5 questions
questions
page 2 of 2As a lead, how do you decide whether synchronization with an external system lives in a component's effects or in a long-lived scope outside the tree?
basics
~20 sMatch the sync to the lifetime of what needs it. A component-owned effect is the default: the runtime disposes it at teardown. A scope outside the tree buys sharing and longevity but must supply its own disposal path.
How would you decide between one application-wide store and many small independent stores, in a long-lived application?
basics
~20 sDecide by invariants, not by size: values that must change together belong behind one applier, independent concerns belong in separate stores. Then weigh notification granularity, per-request instancing, ownership and migration cost, and measure before moving.
Comparing two frameworks' change-propagation models as a lead, what would you ask before committing a long-lived app?
basics
~20 sAsk what makes a change visible, what unit re-executes, what the cost scales with, what discipline every developer must keep, what happens at the boundaries to non-framework code, and how you would debug a propagation that did not happen.
showing 31–33 of 33