Reactive programming becoming very popular these days and many people already adopted or started to adopt it in their projects. This is indeed a great tool but in the wrong hands, it quickly can get out of hands. Polluting the codebase with spaghettis of reactive operators where it can be hard to reason about and debug. In this talk, I will share our experience with reactive programming at Babylon Health. And show our approach on how we manage the state in our ViewModels in a unidirectional way. http://uamobile.org/uk/topics/managing-state-reactive-applications

1. IN REACTIVE APPLICATIONS
SERGEY SHULGA
STATEMANAGING

2. STATE

3. MVVM

4. FRP

5. PROBLEMS
▸ A big team without an established pattern of how to use it

6. PROBLEMS
▸ A big team without an established pattern of how to use it
▸ different understanding of RP

7. PROBLEMS
▸ A big team without an established pattern of how to use it
▸ different understanding of RP
▸ different perspectives of how these principles should be
applied

8. PROBLEMS
▸ A big team without an established pattern of how to use it
▸ different understanding of RP
▸ different perspectives of how these principles should be
applied
▸ different level of knowledge/experience

9. ENOUGH

10. DIFFERENT STYLES

11. DIFFERENT STYLES
▸ Kickstarter style. Input/Output protocols

12. DIFFERENT STYLES
▸ Kickstarter style. Input/Output protocols
▸ (Input/Output) are observables

13. DIFFERENT STYLES
▸ Kickstarter style. Input/Output protocols
▸ (Input/Output) are observables
▸ Using Variables/Subjects/Relays

14. EXAMPLE

15. KICKSTARTER STYLE

16. INPUT/OUTPUT STYLE

17. USING VARIABLES/SUBJECTS/RELAYS

18. ISSUES OF THESE APPROACHES:

19. ISSUES OF THESE APPROACHES:
▸ Requires advanced knowledge

20. ISSUES OF THESE APPROACHES:
▸ Requires advanced knowledge
▸ It can get messy pretty fast

21. ISSUES OF THESE APPROACHES:

22. ISSUES OF THESE APPROACHES:
▸ Requires advanced knowledge
▸ It can get messy pretty fast
▸ Hard to debug

23. ISSUES OF THESE APPROACHES:
▸ Requires advanced knowledge
▸ It can get messy pretty fast
▸ Hard to debug
▸ No way to get a snapshot of a current “State”

24. ISSUES OF THESE APPROACHES:
▸ Requires advanced knowledge
▸ It can get messy pretty fast
▸ Hard to debug
▸ No way to get a snapshot of a current “State”
▸ Provides only interface guidelines

25. ISSUES OF THESE APPROACHES:
▸ Requires advanced knowledge
▸ It can get messy pretty fast
▸ Hard to debug
▸ No way to get a snapshot of a current “State”
▸ Provides only interface guidelines
▸ Error prone

26. ERROR
PRONE

27. CATCHING ERRORS

28. SHARING IS CARING

29. CANCELATION

30. GOALS

31. GOALS
▸ Common approach

32. GOALS
▸ Common approach
▸ Reduce/remove common mistakes

33. GOALS
▸ Common approach
▸ Reduce/remove common mistakes
▸ Not require advanced knowledge of FRP

34. IF YOU WANT TO MAKE PEOPLE
DO SOMETHING, YOU NEED TO
MAKE IT EASIER FOR THEM.

35. REACTIVE
FEEDBACK

36. STATE EFFECTS EVENT

38. STATE

39. EVENT

40. + =
EVENTSTATE STATE

41. REDUCER

42. EFFECTS

43. EFFECTS
▸ Timers

44. EFFECTS
▸ Timers
▸ Network requests

45. EFFECTS
▸ Timers
▸ Network requests
▸ DB queries

46. EFFECTS
▸ Timers
▸ Network requests
▸ DB queries
▸ Bluetooth connections

47. EFFECTS
▸ Timers
▸ Network requests
▸ DB queries
▸ Bluetooth connections
▸ User input

48. FEEDBACK

49. FEEDBACK

50. FEEDBACK

51. FEEDBACK

52. SYSTEM STATE
FEEDBACK
EVENT
REDUCER
NEW STATE

53. STATE
FEEDBACK
EVENT
REDUCER
NEW STATE
SYSTEM

54. STATE
FEEDBACK
EVENT
REDUCER
NEW
SYSTEM

55. SYSTEM

56. ADVANTAGES

57. ADVANTAGES
▸ Clear separation of concerns

58. ADVANTAGES
▸ Clear separation of concerns
▸ Easy to debug

59. ADVANTAGES
▸ Clear separation of concerns
▸ Easy to debug
▸ Easier to review

60. ADVANTAGES
▸ Clear separation of concerns
▸ Easy to debug
▸ Easier to review
▸ Easier to test

61. Q&A
@SERGDORT

62. LINKS
▸ https://github.com/sergdort/ReactiveFeedbackExamples
▸ https://github.com/Babylonpartners/ReactiveFeedback
▸ https://github.com/NoTests/RxFeedback.swift
@SERGDORT