Patterns and practices to scale UI architectures
Thinking in react
- Start with a mock
- Break the UI into a component hierarchy
- Build a static version
- Identify the minimal (but complete) representation of the UI state
- Identify where your state should live
- 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