Upgrade to Pro — share decks privately, control downloads, hide ads and more …

FLUX for iOS

FLUX for iOS

Sergey Zenchenko

November 15, 2015
Tweet

More Decks by Sergey Zenchenko

Other Decks in Programming

Transcript

  1. Feature Team Feature Team Feature Team Feature Team Feature Team

    Team structure Multiple parallel work streams
  2. Requirements for architecture • Low coupling • Module isolation •

    No shared mutable state at all • Unified way for state reading and mutations • Consistency of application state • It should be testable
  3. What’s state? • Domain models: User, Post, Comment, etc •

    App logic/env state: IsNetworkAvailable, isSomeFeatureEnabled • Operations state: isLoading, isLoaded, isLoadedWithError, etc
  4. Classic way problems • State is spread across the app

    • Very hard to reach consistency • State is mutable
  5. Core Data way • Better than classic way • Provides

    consistency at database layer • Notifies UI about changes across the app
  6. Core Data problems #1 • Hard to scale data scheme

    for big team. One big file with data scheme. • Performance issues with big data scheme • Full consistency can cause performance issues • There is no observing of nested entities from the box • Can cause performance issues during app startup because of DB creation
  7. Core Data problems #2 • Complicated threading model • NSManagedObjects

    are mutable • Leaking abstraction. You have to think about SQL if you are building something complex • It can only store actual domain models • No place for intermediate state • Migrations • Do we really need database inside mobile app?
  8. FLUX • Created by Facebook for web • Goal is

    to simplify state management inside Facebook messenger on the web • Not a framework, just a pattern • Not new idea, but a combination of existing pattern with some additional components
  9. Main ideas • State is separated from UI • Unidirectional

    data flow • State is split into stores • Each store contains state modification logic based on events • All state mutations are isolated in separate layer
  10. Service layer • No global state • Contains business logic,

    networking, etc • Receives actions from view • Produces sequence of events for stores
  11. Dispatcher • Central hub that manages all data flow •

    Store registers itself in dispatcher • When new event is received it dispatched to stores registered for this type of events
  12. Stores • Keeps the state • Handles incoming events from

    service layer • Updates the state • Notifies View about state changes • Store is the only place in your whole app that has privilege to mutate the state
  13. Event Sourcing • http://martinfowler.com/eaaDev/EventSourcing.html • Capture all changes to app

    state as a sequence of events onLike onLike onComment onImagePosted onLogout
  14. Event Collaboration • http://martinfowler.com/eaaDev/ EventCollaboration.html • Multiple components work together

    by communicating with each other by sending events when their internal state changes.
  15. Modules communication with FLUX Stores Service Layer View Stores Service

    Layer View Stores Service Layer View Stores Service Layer View Stores Service Layer View Dispatcher
  16. DSL

  17. Integration with UI • View can listen to store changes

    using KVO or any other type of notifications • When state is changed View should sync it’s UI components tree with state • Todo app sample https://github.com/techery/flux- todo-app
  18. Declarative UI • http://componentkit.org • Very similar to ReactJS •

    Fits best FLUX model because it can rebuild whole UI tree after each store change
  19. Problems • Verbose • Need time to adopt • Sometimes

    it’s hard to decide that to put into state