We’ve all been there. Staring at VSCode. Paralyzed by one agonizing question. How do I structure my NgRx Store?! Should I add a new property for “totalLength”? Should I really store the width of this re-sized div? Is a “leftPanel” object really a good idea?

As your application gets bigger, your store can turn unwieldy. What was once a simple array of todos is now a junk drawer of values. Adding just one property can break hundreds of tests. Dispatching new actions can cause needlessly trigger Change Detection, degrading performance, and creating some serious jank. New team members creating new Feature Modules can cause collisions with the store structure. This frustration is enough to make you `rm -rf` and go home. Fear not. There’s an easy solution: selectors.

Selectors are the best-kept secret in NgRx. They allow you compute state from your store, which acts like a view model. This removes computed properties from the store and into their rightful place: a simple function. Selectors are easily tested, memoized for performance, and compose-able for re-usability. Selectors are easy to create and work well with teams. We’ve used them in high traffic production apps like the Firebase Console.

Grab a seat. By the end of this talk you’ll shake any Store structure fears you once had and move forward boldly with selectors.