Patterns and practices to scale UI architectures

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?

Repository

Made with Slides.com