This talk may contain strong language, harsh truths, and serious passion.
Bidirectional data flow can affect application state in many places and be difficult to track.
Specifying HOW the state of a program should be altered.
- Readability ++
- Refactorability ++
- Easier to track "state" change of the UI
A declarative programming style concerned with data “streams” and propagation of change.
- When we care about execution context
- When we need unidirectional data flow (preferably always)
Cause then you're just imperatively programming with BehaviorSubjects, you gain no benefits with additional complexity.
Play with Stackblitz demo here
- Creating unidirectional data flow.
- Controlling when pieces of our application state change, and getting notified of those changes.
Imperative branch - `main` | Reactive branch - `reactive`
Let's get Reactive
Start with what you want to display in the UI. List the different things that would cause that things state to change.
API response?Interaction events?
Streams are very abstract and can be hard to visualize until you've created a solid mental model. Add the Type of the value you want your stream to ultimately display in the UI, and let the errors help you learn how operators work.
Just throw all your logic in that first map function once you have all your streams, return what you need to display. As you get more comfortable, break pieces apart.
There's a ton of operators(in RxJS < 7, anyway). Get comfortable with a few at first.
Operator Decision Tree:
Start pulling your streams into separate consts, and bringing them into Combinational operators separately. You'll be able to see patterns more easily and create more composability as you get more comfortable.
Architectural decisions and pattern adoptions MUST be discussed and approved by everyone committing code to the project!
- Nested subscriptions
- Imperative logic in subscription functions
- Not unsubscribing
- Imperative logic in tap operations*
*Sometimes this can't be avoided -
like launching modals/toasts, or dealing with not-truly-reactive-reactive-forms
Practice, practice, practice.
Slides available at:
Want to grow your career? I'm growing my team! email@example.com