Thinking in React

Flux architecture pattern

Thinking in react

1. Start with a mock
2. Break the UI into a component hierarchy
3. Build a static version
4. Identify the minimal (but complete) representation of the UI state
5. Identify where your state should live
6. Add inverse data flow

React is just the V* in MVC

There are two types of "model" data in React: props and state.

React is was just the V* in MVC

React is the VC* in MVC

React is a view library.

State is a representation of the UI.

Myself. After all the bullshit.

So we're building SPAs, right? Then where do we...

• Do the routing
• Authenticate
• Fetch from remote APIs
• Validate
• Transform data structures
• ...

Demo time!

• Alice: increments or decrements a counter
• Bob: Given a counter value, draws as many input-buttons as the value says
• Denis: Shows a confirmation message
• Charlie: Wraps all the components

Rules

• Business logic shouldn't be inside a view component
• Neither Alice, Bob or Denis know about each other
• Every component is in a different codebase and developed by a different team

Conclusions

• Your state is not your business logic
• Build contracts between your boundaries to avoid tight coupling
• Don't forget the old practices you've learnt from the Back End world. They're still valid in Front End SPAs
• Your business logic shouldn't map UI specific behaviours
• Defend yourself for possible future changes

Next session

• How to implement a reusable domain library

Questions?