Borrowing the Best of Web to Make Native Better, with Christina Lee & Brandon Kase

Transcript

1. Borrowing the best of the web to make native better Brandon Kase & Christina Lee
2. Why are we here? Let me tell you a story! about a button a complicated button
3. Take 1: boss asks for friend button we say, 'OK! We'll do it this week!' we do not finish it in a week woah...this is very complicated! boss is less than thrilled
4. Take 2: boss asks for friend button we say, 'OK! We'll do it this week!' we modify our approach we do not finish it in a week we finish it in a day! boss is thrilled Brandon and Christina still have jobs, hurray!
5. What went wrong Fetch data before view transitions Optimistically update components Send server requests and react to responses
6. Side Effects Touch global state, make network requests Side-effects are bad, but necessary
7. Most Common Pitfalls Mutability Asynchronicity
8. As developers, we are expected to handle optimistic updates, server- side rendering, fetching data before performing route transitions, and so on... This complexity is difficult to handle as we’re mixing two concepts that are very hard for the human mind to reason about: mutation and asynchronicity. I call them Mentos and Coke” Motivation | Redux
10. Luckily, we are not alone
11. Web Allies The web faces all of these challenges and more Unlike native; however, it's iteration rate is fast Not "one" UI framework
12. So what did the web come up with?
13. Ways to manage side-effects View State
14. Ways to manage side-effects Separation of concerns Mutability and asynchronicity are decoupled
16. Flux
17. Redux / / T h e c u r r e n t a p p l i c a t i o n s t a t e ( l i s t o f t o d o s a n d c h o s e n f i l t e r ) l e t p r e v i o u s S t a t e = { v i s i b l e T o d o F i l t e r : ' S H O W _ A L L ' , t o d o s : [ { t e x t : ' R e a d t h e d o c s . ' , c o m p l e t e : f a l s e } ] } / / T h e a c t i o n b e i n g p e r f o r m e d ( a d d i n g a t o d o ) l e t a c t i o n = { t y p e : ' A D D _ T O D O ' , t e x t : ' U n d e r s t a n d t h e f l o w . ' } / / Y o u r r e d u c e r r e t u r n s t h e n e x t a p p l i c a t i o n s t a t e l e t n e x t S t a t e = t o d o A p p ( p r e v i o u s S t a t e , a c t i o n ) -- Dan Abaramov's Data Flow example in Redux
18. Cycle.js
19. Cycle.js inputs = read effects you care about outputs = write effects you want performed all application logic is pure!
20. Cycle.js
21. from cycle.js.org
22. Common Traits Unidirectional and circular data flows Separation of concerns
23. How do we benefit on Android?
24. Logic is made easy Implicit data flow of your app becomes explicit. Immutable views of a mutable world Debugging is made easy All edge cases caught at compile-time. Single source of truth. Time Travel
25. How can you adopt this View: React native Anvil State: Direct port of Redux/Cycle/etc.
26. We focused on State Don't have to fight Android's UI framework Easy to introduce
28. Native (kotlin) Single-Atom-State (like redux) Pure Functional Reactive (like cycle) Composable (like cycle)
29. Aside: RxJava
30. Aside: RxJava Reactive programming is programming with asynchronous data streams Andre Staltz Global event emitter << Event buses << Data stream
31. Aside: RxJava When we say streams, we mean push-based event streams, not pull-based infinite list streams
32. Aside: RxJava What can this look like in practice? Streams of button taps Streams of snapshots of changing data Streams from network responses
33. Aside: RxJava RxJava Reactive programming with streams Tools to combine and transform those streams
34. Aside: RxJava from RxMarbles
35. Aside: RxJava from RxMarbles
36. Aside: RxJava O b s e r v a b l e . j u s t ( 1 , 2 , 3 )
37. Example
38. Example 0:09 0:14
39. Not just a counter
41. 1. View-Model State d a t a c l a s s / * V i e w - M o d e l * / S t a t e ( v a l n u m L i k e s : I n t , v a l n u m C o m m e n t s : I n t , v a l s h o w N e w H i g h l i g h t : B o o l e a n , v a l i m g U r l : S t r i n g ? , v a l s h o w U n d o : B o o l e a n )
43. 2. View Intentions / / M o d e i s e i t h e r t a p p e d o r u n t a p p e d d a t a c l a s s V i e w I n t e n t i o n s ( v a l p h o t o s : O b s e r v a b l e < P h o t o > , v a l m o d e s : O b s e r v a b l e < M o d e . S u m > , v a l g l o b a l R e a d T s : O b s e r v a b l e < L o n g > )
45. 3. Model State / / M o d e i s e i t h e r t a p p e d o r u n t a p p e d d a t a c l a s s / * M o d e l * / S t a t e ( v a l p h o t o : P h o t o ? , v a l i s N e w : B o o l e a n , v a l m o d e : M o d e . S u m , ) : R a m S t a t e < . . . > v a l i n i t i a l S t a t e = S t a t e ( p h o t o = n u l l , i s N e w = f a l s e , m o d e = M o d e . u n t a p p e d )
46. 4. View Intentions => Model State Changes State changes? We want functional code. We want immutability. Think of a state change as a function f u n c c h a n g e ( c u r r e n t S t a t e : S t a t e ) - > S t a t e / * n e x t S t a t e * /
47. 4. View Intentions => Model State Changes v a l m o d e l : ( V i e w I n t e n t i o n s ) - > O b s e r v a b l e < ( S t a t e ) - > S t a t e > = { i n t e n t i o n s - > v a l m o d e C h a n g e s : O b s e r v a b l e < ( S t a t e ) - > S t a t e > = i n t e n t i o n s . m o d e s . m a p { / * . . . * / } v a l p h o t o C h a n g e s : O b s e r v a b l e < ( S t a t e ) - > S t a t e > = i n t e n t i o n s . p h o t o s . m a p { / * . . . * / } v a l t s C h a n g e s : O b s e r v a b l e < ( S t a t e ) - > S t a t e > = i n t e n t i o n s . g l o b a l R e a d T s . m a p { / * . . . * / } O b s e r v a b l e . m e r g e ( m o d e C h a n g e s , p h o t o C h a n g e s , t s C h a n g e s ) }
48. 4. View Intentions => Model State Changes v a l m o d e C h a n g e s : O b s e r v a b l e < ( S t a t e ) - > S t a t e > = i n t e n t i o n s . m o d e s . m a p { m o d e - > { s t a t e : S t a t e - > S t a t e ( s t a t e . p h o t o , s t a t e . i s N e w , m o d e ) } }
50. 5. Model State => View-Model State v a l v i e w M o d e l : ( O b s e r v a b l e < M o d e l . S t a t e > ) - > O b s e r v a b l e < V i e w M o d e l . S t a t e > = { s t a t e S t r e a m - > s t a t e S t r e a m . m a p { s t a t e - > v a l u n d o a b l e = s t a t e . m o d e = = M o d e . t a p p e d v a l l i k e s = s t a t e . p h o t o ? . l i k e _ d e t a i l s ? : e m p t y L i s t ( ) v a l c o m m e n t s = s t a t e . p h o t o ? . c o m m e n t s ? : e m p t y L i s t ( ) V i e w M o d e l . S t a t e ( n u m L i k e s = l i k e s . s u m B y { i t . m u l t i p l i e r } , n u m C o m m e n t s = c o m m e n t s . c o u n t , s h o w N e w H i g h l i g h t = s t a t e . i s N e w , i m g U r l = / * . . . * / , s h o w U n d o = / * . . . * / ) } }
52. 6. View-Model => Mutate the View c l a s s P h o t o C o m p o n e n t ( v i e w I n t e n t i o n s : V i e w I n t e n t i o n s , v i e w : P h o t o C e l l V i e w ) : S t a r t S t o p C o m p o n e n t b y C o m p o n e n t ( d r i v e r = / * . . . * / , m o d e l = / * . . . * / )
53. 6. View-Model => Mutate the View d r i v e r = V i e w D r i v e r < V i e w I n t e n t i o n s , V i e w M o d e l . S t a t e > ( i n t e n t i o n = v i e w I n t e n t i o n s , o n V i e w S t a t e = { o l d , s t a t e - > i f ( o l d ? . i m g U r l ! = s t a t e . i m g U r l ) { v i e w . s e t I m g ( s t a t e . i m g U r l ) } / * . . . * / } ) ,
54. 6. View-Model => Mutate the View m o d e l = V i e w D r i v e r . m a k e M o d e l ( i n i t i a l S t a t e = M o d e l . i n i t i a l S t a t e , c r e a t e S t a t e = M o d e l . c r e a t e S t a t e , m o d e l = M o d e l . m o d e l , v i e w M o d e l = V i e w M o d e l . v i e w M o d e l )
55. Stick it in a recycler-view, hook up the side-effects into view intentions and you're done
57. ViewIntentions The inputs to your component The photo, the mode, the tap timestamp Model Transform the inputs into state changes Change mode, change isNew, change photo ViewModel Transform model state to view-model state Extract photo url, like counts, etc Component Apply mutations to your view based on your view-model Use the View-Model to change the underlying Android view
58. Under the hood Enforce viewintentions/model/view-model structure RxJava does heavy-lifting and a magic scan
59. Under the hood
60. Implementation of Redux in one-line m o d e l S t r e a m . s c a n ( i n i t i a l S t a t e , { c u r r e n t S t a t e , t r a n s f o r m - > t r a n s f o r m ( c u r r e n t S t a t e ) } )
61. Bonus Cycle.js-like side-effect drivers Configurable model state persistance within state Auto-start and stop components onPause/onResume
62. Just like cycle read effects are inputs write effects are outputs Effects are decoupled from business logic
63. What does it look like in production?
64. Results: The Good It wouldn't compile
65. Results: The Good When it did compile, it worked!
66. Results: The Good Incredibly modular and composable LEGO-like plug-and-play
67. Results: The Good Easy to test (by hand + by unit test) & debug REALLY EASY Mocking inputs is trivial UI component is defined ONLY by it's state
68. Results: The Good Easy to maintain Spec change? (possibly) add an input stream add another m a p in the model
69. Results: The Bad Ramp up necessary
70. Results: The Bad Animations are hard chase or interpolate underlying state? probably additive animations (google it)
71. Results: The Bad? Boiler plate (screenshot of files) Always the 4 pieces c y k l i c repo has counter example in one file
72. Results: The Surprising It's actually not slow No noticeable perf hit
73. Results: The Conclusion
74. Results: The Conclusion We have more powerful tools now (i.e. Kotlin + Functional programming) Let's use them Question everything
75. Cyklic Github: bkase/cyklic
76. Thanks Brandon Kase Christina Lee bkase@highlig.ht christina@highlig.ht @bkase_ @runchristinarun bkase.com Github: bkase/cyklic