FLUX for iOS
Sergey Zenchenko - Co-Founder at Techery
Slide 2
Slide 2 text
We have huge project
Slide 3
Slide 3 text
Feature
Team
Feature
Team
Feature
Team
Feature
Team
Feature
Team
Team structure
Multiple parallel work streams
Slide 4
Slide 4 text
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
What wrong with classic iOS
way?
• it’s not scalable
• it’s hard to test
Slide 7
Slide 7 text
Classic way
Slide 8
Slide 8 text
Classic way problems
• State is spread across the app
• Very hard to reach consistency
• State is mutable
Slide 9
Slide 9 text
Core Data way
• Better than classic way
• Provides consistency at database layer
• Notifies UI about changes across the app
Slide 10
Slide 10 text
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
Slide 11
Slide 11 text
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?
Slide 12
Slide 12 text
What else?
Slide 13
Slide 13 text
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
Slide 14
Slide 14 text
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
View/Presentation layer
• Listen for store’s state changes
• Send actions to service layer
Slide 17
Slide 17 text
Service layer
• No global state
• Contains business logic, networking, etc
• Receives actions from view
• Produces sequence of events for stores
Slide 18
Slide 18 text
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
Slide 19
Slide 19 text
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
CQRS
• http://martinfowler.com/bliki/CQRS.html
• Strict separation between state mutations and reading
Slide 25
Slide 25 text
CQRS
Slide 26
Slide 26 text
Event Sourcing
• http://martinfowler.com/eaaDev/EventSourcing.html
• Capture all changes to app state as a sequence of
events
onLike onLike onComment onImagePosted onLogout
Slide 27
Slide 27 text
Features
• Simplify debugging
• Time machine
Slide 28
Slide 28 text
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.
Slide 29
Slide 29 text
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
Slide 30
Slide 30 text
iOS Implementation
Slide 31
Slide 31 text
FLUX for iOS
• https://github.com/techery/FLUX
• https://github.com/techery/flux-todo-app
• pre-alpha version
• we will push a lot of new feature during next month
Slide 32
Slide 32 text
Immutable models
• It’s not required by FLUX, but good to have
• Why Immutable?
Slide 33
Slide 33 text
Shared mutable state is the root of all evil.
Slide 34
Slide 34 text
No content
Slide 35
Slide 35 text
DSL
Slide 36
Slide 36 text
Sample of event handling
Slide 37
Slide 37 text
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
Slide 38
Slide 38 text
Declarative UI
• http://componentkit.org
• Very similar to ReactJS
• Fits best FLUX model because it can rebuild whole UI
tree after each store change
Slide 39
Slide 39 text
Problems
• Verbose
• Need time to adopt
• Sometimes it’s hard to decide that to put into state