FLUX for iOS

Transcript

1. FLUX for iOS Sergey Zenchenko - Co-Founder at Techery
2. We have huge project
3. Feature Team Feature Team Feature Team Feature Team Feature Team Team structure Multiple parallel work streams
4. 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
5. What’s state? • Domain models: User, Post, Comment, etc • App logic/env state: IsNetworkAvailable, isSomeFeatureEnabled • Operations state: isLoading, isLoaded, isLoadedWithError, etc
6. What wrong with classic iOS way? • it’s not scalable • it’s hard to test
7. Classic way
8. Classic way problems • State is spread across the app • Very hard to reach consistency • State is mutable
9. Core Data way • Better than classic way • Provides consistency at database layer • Notifies UI about changes across the app
10. 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
11. 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?
12. What else?
13. 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
14. 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
15. FLUX View/Presentation layer Service Layer Stores OnChangeEvents Domain Events Actions Dispatcher Domain Events
16. View/Presentation layer • Listen for store’s state changes • Send actions to service layer
17. Service layer • No global state • Contains business logic, networking, etc • Receives actions from view • Produces sequence of events for stores
18. 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
19. 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
20. State • Plain objects • Database • Files • Primitive types • Etc
21. Related patterns
23. Related Patterns • Command Query Responsibility Segregation • Event Sourcing • Event Collaboration
24. CQRS • http://martinfowler.com/bliki/CQRS.html • Strict separation between state mutations and reading
25. CQRS
26. Event Sourcing • http://martinfowler.com/eaaDev/EventSourcing.html • Capture all changes to app state as a sequence of events onLike onLike onComment onImagePosted onLogout
27. Features • Simplify debugging • Time machine
28. 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.
29. 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
30. iOS Implementation
31. 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
32. Immutable models • It’s not required by FLUX, but good to have • Why Immutable?
33. Shared mutable state is the root of all evil.
35. DSL
36. Sample of event handling
37. 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
38. Declarative UI • http://componentkit.org • Very similar to ReactJS • Fits best FLUX model because it can rebuild whole UI tree after each store change
39. Problems • Verbose • Need time to adopt • Sometimes it’s hard to decide that to put into state
40. We are hiring! jobs@techery.io