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

Domic — Reactive Virtual DOM. Why we built it, how it works.

Domic — Reactive Virtual DOM. Why we built it, how it works.

In-depth technical talk explaining why Domic — Reactive Virtual DOM exists and how it works.

You'll learn how Domic:

- Uses diffing, debouncing, double buffering and other techniques to render changes efficiently
- Keeps state consistent with mutable Android DOM
- Uses advanced RxJava under the hood: sharing, custom operators, scheduling, subscription management
- Minimizes allocations and interactions with main thread
- Renders UI state in memory for unit/integration testing on JVM
- Integrates with existing design patterns: MVVM, MVI/Redux, MVP

Artem Zinnatullin

August 27, 2018
Tweet

More Decks by Artem Zinnatullin

Other Decks in Programming

Transcript

  1. View Slide

  2. motivation

    View Slide

  3. MVC
    0:

    View Slide

  4. MVC
    →MVP
    0:

    View Slide

  5. MVC
    →MVP→MVP2
    0:

    View Slide

  6. MVC
    →MVP→MVP2
    →MVVM
    0:

    View Slide

  7. MVC
    →MVP→MVP2
    →MVVM →MVVM2
    0:

    View Slide

  8. MVC
    →MVP→MVP2
    →MVVM →MVVM2
    →Redux
    goto 0
    0:

    View Slide

  9. MVC
    →MVP→MVP2
    →MVVM →MVVM2
    →Redux
    goto 0
    0:

    View Slide

  10. focus:
    MVVM2 & Redux

    View Slide

  11. “Domic — DOMe like”

    View Slide

  12. structure

    View Slide

  13. 3 main modules

    View Slide

  14. 3 main modules

    View Slide

  15. 3 main modules
    domic/api

    View Slide

  16. 3 main modules
    domic/api
    domic/android

    View Slide

  17. 3 main modules
    domic/api
    domic/android
    domic/test

    View Slide

  18. the api module

    View Slide

  19. the api module
    - Mirrors Android Widgets & Views but reactively
    - Contains only interfaces (okok and 1 inline function)
    - Type-safe

    View Slide

  20. the api module: Observe
    val textView: TextView = …
    textView.observe.textChanges: Observable
    textView.observe.clicks: Observable
    textView.observe.etc: Observable

    View Slide

  21. the api module: Observe
    val textView: TextView = …
    textView.observe.textChanges: Observable
    textView.observe.clicks: Observable
    textView.observe.etc: Observable
    Interface provided by Domic

    View Slide

  22. the api module: Change
    val textView: TextView = …
    textView.change.text(Observable)
    textView.change.enabled(Observable)
    textView.change.etc(Observable)

    View Slide

  23. the api module: Change
    val textView: TextView = …
    textView.change.text(Observable)
    textView.change.enabled(Observable)
    textView.change.etc(Observable)
    Interface provided by Domic

    View Slide

  24. the api module: type-safety
    View.Observe is read-only reference
    View.Change is write-only reference
    View is read-write reference

    View Slide

  25. Useful side-effects of reactive api
    - Threading becomes an implementation detail
    - Both subscribeOn and observeOn
    - Protects main thread from unnecessary work

    View Slide

  26. Useful side-effects of reactive api
    - Threading becomes an implementation detail
    - No easy way for consumer to do blocking work

    View Slide

  27. Useful side-effects of reactive api
    - Threading becomes an implementation detail
    - No easy way for consumer to do blocking work
    - Implementation can be complicated while being
    non-blocking

    View Slide

  28. the View interface

    View Slide

  29. the api module: View interface
    package com.lyft.domic.api
    interface View {
    val observe: Observe
    val change: Change
    interface Observe {
    val clicks: Observable
    val focus: Observable
    val longClicks: Observable
    }
    interface Change {
    fun alpha(alphaValues: Observable): Disposable
    fun enabled(enabledValues: Observable): Disposable
    fun visibility(visibilityValues: Observable): Disp
    }
    }

    View Slide

  30. the api module: Observe
    package com.lyft.domic.api
    interface View {
    val observe: Observe
    val change: Change
    interface Observe {
    val clicks: Observable
    val focus: Observable
    val longClicks: Observable
    }
    interface Change {
    fun alpha(alphaValues: Observable): Disposable
    fun enabled(enabledValues: Observable): Disposable
    fun visibility(visibilityValues: Observable): Disp
    }
    }

    View Slide

  31. the api module: Observe
    package com.lyft.domic.api
    interface View {
    val observe: Observe
    val change: Change
    interface Observe {
    val clicks: Observable
    val focus: Observable
    val longClicks: Observable
    }
    interface Change {
    fun alpha(alphaValues: Observable): Disposable
    fun enabled(enabledValues: Observable): Disposable
    fun visibility(visibilityValues: Observable): Disp
    }
    }

    View Slide

  32. API: Observe, real world example
    signInButton
    .observe
    .clicks
    .withLatestFrom(credentials) { _, creds -> creds }
    .flatMap { creds -> service.signIn(creds) }

    View Slide

  33. the api module: View interface
    package com.lyft.domic.api
    interface View {
    val observe: Observe
    val change: Change
    interface Observe {
    val clicks: Observable
    val focus: Observable
    val longClicks: Observable
    }
    interface Change {
    fun alpha(alphaValues: Observable): Disposable
    fun enabled(enabledValues: Observable): Disposable
    fun visibility(visibilityValues: Observable): Disp
    }
    }

    View Slide

  34. the api module: Change
    package com.lyft.domic.api
    interface View {
    val observe: Observe
    val change: Change
    interface Observe {
    val clicks: Observable
    val focus: Observable
    val longClicks: Observable
    }
    interface Change {
    fun alpha(alphaValues: Observable): Disposable
    fun enabled(enabledValues: Observable): Disposable
    fun visibility(visibilityValues: Observable): Disp
    }
    }

    View Slide

  35. the api module: Change
    package com.lyft.domic.api
    interface View {
    val observe: Observe
    val change: Change
    interface Observe {
    val clicks: Observable
    val focus: Observable
    val longClicks: Observable
    }
    interface Change {
    fun alpha(alphaValues: Observable): Disposable
    fun enabled(enabledValues: Observable): Disposable
    fun visibility(visibilityValues: Observable): Disp
    }
    }

    View Slide

  36. API: Change, real world example
    disposable += signInRequest
    .map { false }
    .subscribe(view.signInButton.change::enabled)

    View Slide

  37. 100% reactive API?

    View Slide

  38. 100% reactive api?
    - Observables as inputs

    View Slide

  39. 100% reactive api?
    - Observables as inputs
    - Observables as outputs

    View Slide

  40. 100% reactive api?
    - Observables as inputs
    - Observables as outputs
    - Proper cancellation
    - Property change can be cancelled within Frame
    window

    View Slide

  41. 100% reactive api?
    - Observables as inputs
    - Observables as outputs
    - Proper cancellation
    - No back-pressure tho, because UI generally can’t
    be back-pressured

    View Slide

  42. 3 main modules
    domic/api

    View Slide

  43. 3 main modules
    domic/api
    domic/android

    View Slide

  44. the android module

    View Slide

  45. the android module
    - Implements API module

    View Slide

  46. the android module
    - Implements API module
    - Binds to real Android DOM (Widgets, Views)

    View Slide

  47. the android module
    - Implements API module
    - Binds to real Android DOM (Widgets, Views)
    - Allows to reuse:
    - Layouts
    - Styles
    - Views/ViewGroups
    - Layout Preview
    - Support library
    - Any build system

    View Slide

  48. the android module
    - Implements API module
    - Binds to real Android DOM (Widgets, Views)
    - Takes care of threading
    - subscribeOn(mainThread())

    View Slide

  49. the android module
    - Implements API module
    - Binds to real Android DOM (Widgets, Views)
    - Takes care of threading
    - subscribeOn(mainThread())
    - observeOn() custom rendering

    View Slide

  50. the android module
    - Implements API module
    - Binds to real Android DOM (Widgets, Views)
    - Takes care of threading
    - subscribeOn(mainThread())
    - observeOn() custom rendering
    - Diffs each property’s new state against previous

    View Slide

  51. the android module
    - Implements API module
    - Binds to real Android DOM (Widgets, Views)
    - Takes care of threading
    - subscribeOn(mainThread())
    - observeOn() custom rendering
    - Diffs each property’s new state against previous
    - Naming convention: “Android” prefix, then the API
    interface name
    - val text: TextView = AndroidTextView(…)

    View Slide

  52. the android module
    val component: VirtualType = BindingType(…)

    View Slide

  53. the android module
    val textView: TextView = AndroidTextView(…)

    View Slide

  54. the android module
    val textView: TextView = AndroidTextView(…)
    Interface provided by Domic

    View Slide

  55. the android module
    val textView: TextView = AndroidTextView(…)
    Implementation provided by Domic

    View Slide

  56. Binding to real Android DOM: RxBinding
    “What can be easier than using RxBinding?
    , right?
    Famous last words

    View Slide

  57. Binding to real Android DOM: RxBinding
    “What can be easier than using RxBinding?
    “Why would you even need a library on top of it?”
    , right?
    Famous last words

    View Slide

  58. Binding to real Android DOM: RxBinding
    - Observables are not shared!

    View Slide

  59. Binding to real Android DOM: RxBinding
    - Observables are not shared!
    - Some properties only allow one listener at a time!
    - ie RxView.clicks()

    View Slide

  60. Binding to real Android DOM: RxBinding
    - Observables are not shared!
    - Some properties only allow one listener at a time!
    - ie RxView.clicks()
    - Subscription time threading is not enforced

    View Slide

  61. Binding to real Android DOM: RxBinding
    - Observables are not shared!
    - Some properties only allow one listener at a time!
    - ie RxView.clicks()
    - Subscription time threading is not enforced
    - And it’s fine! RxBinding is a low-level, foundation layer

    View Slide

  62. Threading
    - subscribeOn(mainThread()) is okay

    View Slide

  63. Threading
    - subscribeOn(mainThread()) is okay
    - Async Handler? Maybe

    View Slide

  64. Threading
    - subscribeOn(mainThread()) is okay
    - Async Handler? Maybe
    - observeOn(mainThread()) is easy

    View Slide

  65. Threading
    - subscribeOn(mainThread()) is okay
    - Async Handler? Maybe
    - observeOn(mainThread()) is easy
    - But that’s too easy
    - If you often render partially same state, you might
    want something better

    View Slide

  66. rendering

    View Slide

  67. How a property change gets rendered
    1. Domic subscribes to Observable
    This is how you get stable 60 fps!

    View Slide

  68. How a property change gets rendered
    1. Domic subscribes to Observable
    2. Value goes through sharedDistinctUntilChanged()
    This is how you get stable 60 fps! Reviewed by David Karnok

    View Slide

  69. How a property change gets rendered
    1. Domic subscribes to Observable
    2. Value goes through sharedDistinctUntilChanged()
    1. It is a custom RxJava Operator
    2. Uses AtomicReferenceArray as shared state
    container
    3. Designed to handle multiple change streams
    bound to the same property at the same time
    This is how you get stable 60 fps! Reviewed by David Karnok

    View Slide

  70. How a property change gets rendered
    1. Domic subscribes to Observable
    2. Value goes through sharedDistinctUntilChanged()
    3. Value maps to a Change object
    This is how you get stable 60 fps!

    View Slide

  71. How a property change gets rendered
    1. Domic subscribes to Observable
    2. Value goes through sharedDistinctUntilChanged()
    3. Value maps to a Change object
    A. Optional optimizations, like PrecomputedText
    This is how you get stable 60 fps!

    View Slide

  72. How a property change gets rendered
    1. Domic subscribes to Observable
    2. Value goes through sharedDistinctUntilChanged()
    3. Value maps to a Change object
    4. Renderer observes the Change
    This is how you get stable 60 fps!

    View Slide

  73. How a property change gets rendered
    1. Domic subscribes to Observable
    2. Value goes through sharedDistinctUntilChanged()
    3. Value maps to a Change object
    4. Renderer observes the Change
    5. Renderer adds or replaces the Change in Buffer
    This is how you get stable 60 fps!

    View Slide

  74. How a property change gets rendered
    1. Domic subscribes to Observable
    2. Value goes through sharedDistinctUntilChanged()
    3. Value maps to a Change object
    4. Renderer observes the Change
    5. Renderer adds or replaces the Change in Buffer
    • Allows Domic “debounce” equal changes within frame interval!
    Basically a BackpressureStrategy.LATEST
    This is how you get stable 60 fps!

    View Slide

  75. How a property change gets rendered
    1. Domic subscribes to Observable
    2. Value goes through sharedDistinctUntilChanged()
    3. Value maps to a Change object
    4. Renderer observes Change
    5. Renderer adds or replaces the Change in Buffer
    • Allows Domic “debounce” equal changes within frame interval!
    Basically a BackpressureStrategy.LATEST
    • Allows Domic to minimize jumps to the Main Thread. Basically
    a BackpressureStrategy.BUFFER
    This is how you get stable 60 fps!

    View Slide

  76. How a property change gets rendered
    1. Domic subscribes to Observable
    2. Value goes through sharedDistinctUntilChanged()
    3. Value maps to a Change object
    4. Renderer observes the Change
    5. Renderer adds or replaces the Change in Buffer
    6. Choreographer calls the Renderer
    This is how you get stable 60 fps!

    View Slide

  77. How a property change gets rendered
    1. Domic subscribes to Observable
    2. Value goes through sharedDistinctUntilChanged()
    3. Value maps to a Change object
    4. Renderer observes the Change
    5. Renderer adds or replaces the Change in Buffer
    6. Choreographer calls the Renderer
    7. Renderer swaps the Buffer and renders current
    one
    This is how you get stable 60 fps!

    View Slide

  78. View Slide

  79. Domic performance: baseline, no help
    from diffing

    View Slide

  80. the test module

    View Slide

  81. the test module
    - Implements API module in memory

    View Slide

  82. the test module
    - Implements API module in memory
    - Diffs the changes

    View Slide

  83. the test module
    - Implements API module in memory
    - Adds Simulate interface to each Widget

    View Slide

  84. the test module
    - Implements API module in memory
    - Adds Simulate interface to each Widget
    - Adds Check interface to each Widget

    View Slide

  85. the test module
    - Implements API module in memory
    - Adds Simulate interface to each Widget
    - Adds Check interface to each Widget
    - Designed to work on JVM

    View Slide

  86. the test module
    - Implements API module in memory
    - Adds Simulate interface to each Widget
    - Adds Check interface to each Widget
    - Designed to work on JVM
    - Allows to test ViewModels, Presenters, etc

    View Slide

  87. the test module
    - Implements API module in memory
    - Adds Simulate interface to each Widget
    - Adds Check interface to each Widget
    - Designed to work on JVM
    - Allows to test ViewModels, Presenters, etc
    - Extreme: ~whole app can be rendered in memory

    View Slide

  88. the test module
    @Test
    fun `sign in button enabled if valid credentials entered`() {
    view.emailEditText.simulate.text("[email protected]")
    view.passwordEditText.simulate.text("password")
    assertThat(view.signInButton.check.enabled).isTrue()
    }

    View Slide

  89. the test module
    @Test
    fun `sign in button enabled if valid credentials entered`() {
    view.emailEditText.simulate.text("[email protected]")
    view.passwordEditText.simulate.text("password")
    assertThat(view.signInButton.check.enabled).isTrue()
    }

    View Slide

  90. the test module
    @Test
    fun `sign in button enabled if valid credentials entered`() {
    view.emailEditText.simulate.text("[email protected]")
    view.passwordEditText.simulate.text("password")
    assertThat(view.signInButton.check.enabled).isTrue()
    }

    View Slide

  91. the test module
    @Test
    fun `sign in button enabled if valid credentials entered`() {
    view.emailEditText.simulate.text("[email protected]")
    view.passwordEditText.simulate.text("password")
    assertThat(view.signInButton.check.enabled).isTrue()
    }

    View Slide

  92. the test module
    @Test
    fun `sign in button enabled if valid credentials entered`() {
    view.emailEditText.simulate.text("[email protected]")
    view.passwordEditText.simulate.text("password")
    assertThat(view.signInButton.check.enabled).isTrue()
    }

    View Slide

  93. + MVVM2
    + Redux/MVI
    + MVP2
    Domic

    View Slide

  94. + MVVM2
    Domic

    View Slide

  95. Domic + MVVM2: View
    interface SignInView {
    val emailEditText: EditText
    val passwordEditText: EditText
    val signInButton: Button
    val resultTextView: TextView
    }

    View Slide

  96. Domic + MVVM2: AndroidView
    class AndroidSignInView(root: ViewGroup, renderer: Renderer) : SignInView {
    override val emailEditText = AndroidEditText(root.findViewById(R.id.email_edit_text), renderer)
    override val passwordEditText = AndroidEditText(root.findViewById(R.id.password_edit_text), renderer)
    override val signInButton = AndroidButton(root.findViewById(R.id.sign_in_button), renderer)
    override val resultTextView = AndroidTextView(root.findViewById(R.id.sign_result_text_view), renderer)
    }

    View Slide

  97. Domic + MVVM2: Thoughts
    https://github.com/lyft/domic/tree/master/samples/mvvm
    - Often times emits same property values due to
    its reactive nature

    View Slide

  98. Domic + MVVM2: Thoughts
    https://github.com/lyft/domic/tree/master/samples/mvvm
    - Often times emits same property values due to
    its reactive nature
    - Spawns lots of individual rx streams which need
    to do proper threading

    View Slide

  99. Domic + MVVM2: Thoughts
    https://github.com/lyft/domic/tree/master/samples/mvvm
    - Often times emits same property values due to
    its reactive nature
    - Spawns lots of individual rx streams which need
    to do proper threading
    - Uses same rx streams from View multiple
    times, they need to be shared

    View Slide

  100. Domic + MVVM2: Thoughts
    https://github.com/lyft/domic/tree/master/samples/mvvm
    - Often times emits same property values due to
    its reactive nature
    - Spawns lots of individual rx streams which need
    to do proper threading
    - Uses same rx streams from View multiple
    times, they need to be shared
    - Reactive View layer becomes hard to swap with
    test implementation

    View Slide

  101. Domic + MVVM2: Thoughts
    https://github.com/lyft/domic/tree/master/samples/mvvm
    - Often times emits same property values due to
    its reactive nature
    - Spawns lots of individual rx streams which need
    to do proper threading
    - Uses same rx streams from View multiple
    times, they need to be shared
    - Reactive View layer becomes hard to swap with
    test implementation
    - Domic fits MVVM2 really well and compliments
    it in many ways

    View Slide

  102. Domic + MVVM2: Sample
    See:
    lyft/domic/samples/mvvm
    https://github.com/lyft/domic/tree/master/samples/mvvm

    View Slide

  103. + Redux
    Domic

    View Slide

  104. Domic + Redux: Thoughts
    - Most of the time emits state that is mostly
    equal to previous one
    https://github.com/lyft/domic/tree/master/samples/redux

    View Slide

  105. Domic + Redux: Thoughts
    - Most of the time emits state that is mostly
    equal to previous one
    - Spawns less rx streams compared to MVVM
    https://github.com/lyft/domic/tree/master/samples/redux

    View Slide

  106. Domic + Redux: Thoughts
    - Most of the time emits state that is mostly
    equal to previous one
    - Spawns less rx streams compared to MVVM
    - Input rx streams are merged into a single
    stream, RxBinding actually works well here
    https://github.com/lyft/domic/tree/master/samples/redux

    View Slide

  107. Domic + Redux: Thoughts
    - Most of the time emits state that is mostly
    equal to previous one
    - Spawns less rx streams compared to MVVM
    - Input rx streams are merged into a single
    stream, RxBinding actually works well here
    - Output rx stream is merged into a single one,
    threading is easy but still needs
    https://github.com/lyft/domic/tree/master/samples/redux

    View Slide

  108. Domic + Redux: Thoughts
    - Most of the time emits state that is mostly
    equal to previous one
    - Spawns less rx streams compared to MVVM
    - Input rx streams are merged into a single
    stream, RxBinding actually works well here
    - Output rx stream is merged into a single one,
    threading is easy but still needs
    - View layer is basically a render(State) function
    and an actions: Observable property
    https://github.com/lyft/domic/tree/master/samples/redux

    View Slide

  109. Domic + Redux: Thoughts
    - Most of the time emits state that is mostly
    equal to previous one
    - Spawns less rx streams compared to MVVM
    - Input rx streams are merged into a single
    stream, RxBinding actually works well here
    - Output rx stream is merged into a single one,
    threading is easy but still needs
    - View layer is basically a render(State) function
    and an actions: Observable property
    - Domic’s API as of now feels a bit off for Redux,
    but
    https://github.com/lyft/domic/tree/master/samples/redux

    View Slide

  110. Domic + Redux: Sample
    See:
    lyft/domic/samples/redux
    https://github.com/lyft/domic/tree/master/samples/redux Reviewed by Hannes Dorfmann

    View Slide

  111. the test module
    See: domic/samples/mvvm/src/test
    domic/samples/mvp/src/test
    https://github.com/lyft/domic/tree/master/samples
    domic/samples/redux/rxredux/src/test

    View Slide

  112. DSL/Declarative API?

    View Slide

  113. DSL/declarative API?
    - Web developers love React, especially with Redux

    View Slide

  114. DSL/declarative API?
    - Web developers love React, especially with Redux
    - Lots of trade-offs and corner cases

    View Slide

  115. DSL/declarative API?
    - Web developers love React, especially with Redux
    - Lots of trade-offs & corner cases
    - Layout files?

    View Slide

  116. DSL/declarative API?
    - Web developers love React, especially with Redux
    - Lots of corner-cases & trade-offs
    - Layout files?
    - Styling?

    View Slide

  117. DSL/declarative API?
    - Web developers love React, especially with Redux
    - Lots of corner-cases & trade-offs
    - Layout files?
    - Styling?
    - Reactive?

    View Slide

  118. DSL/declarative API?
    - Web developers love React, especially with Redux
    - Lots of corner-cases & trade-offs
    - Layout files?
    - Styling?
    - Reactive?
    - Maybe!**
    **Is not a public offer, other restrictions apply

    View Slide

  119. Domic … or?

    View Slide

  120. Domic or fb/Litho
    https://fblitho.com/

    View Slide

  121. Domic or fb/Litho
    - Controls the DOM
    - Declarative
    - Own Component system
    - Components can’t really use Android Layouts/Widgets
    - Component system is designed to be used with
    annotation processing
    - Uses crazy-awesome fb/Yoga for efficient rendering
    - Scalable for complicated screens like RecyclerView
    - Calculates diffs
    - Reactive?
    https://fblitho.com/

    View Slide

  122. Domic or fb/Litho
    airbnb/Epoxy
    https://github.com/airbnb/epoxy

    View Slide

  123. Domic or airbnb/Epoxy
    - Controls the DOM
    - Declarative
    - Own Component system
    - Components can use Android Layouts/Widgets/Views
    - Component system is designed to be used with
    annotation processing
    - Scalable like RecylerView and actually uses RV
    - Calculates diffs
    - Reactive?
    https://github.com/airbnb/epoxy

    View Slide

  124. Domic or fb/Litho
    airbnb/Epoxy
    fb/ReactNative
    https://facebook.github.io/react-native/

    View Slide

  125. Domic or fb/ReactNative
    - Controls the DOM
    - Declarative
    - Own Component system
    - Components can use Android Layouts/Widgets/Views
    - JavaScript
    - Calculates diffs
    - Reactive?
    https://facebook.github.io/react-native/

    View Slide

  126. Domic or fb/Litho
    airbnb/Epoxy
    fb/ReactNative
    passy/Konduit
    https://github.com/passsy/Konduit

    View Slide

  127. Domic or passy/Konduit
    - Controls the DOM
    - Declarative
    - Own Widget system
    - Widgets can use Android Layouts/Widgets/Views
    - Calculates diffs
    - Reactive?
    https://github.com/passsy/Konduit

    View Slide

  128. Domic … or?

    View Slide

  129. Should Domic …?
    - Control the DOM or only Bind to it?

    View Slide

  130. Should Domic …?
    - Control the DOM or only Bind to it?
    - Provide declarative/DSL-based API?

    View Slide

  131. Should Domic …?
    - Control the DOM or only Bind to it?
    - Provide declarative/DSL-based API?
    - Stay 100% reactive?

    View Slide

  132. Should Domic …?
    - Control the DOM or only Bind to it?
    - Provide declarative/DSL-based API?
    - Stay 100% reactive?
    - Wait, did I mention reactive animations?

    View Slide

  133. Should Domic …?
    - Control the DOM or only Bind to it?
    - Provide declarative/DSL-based API?
    - Be actually reactive?
    - Wait, did I mention reactive animations?
    Maybe yes!** Maybe no**
    **Is not a public offer, other restrictions apply

    View Slide

  134. Recap

    View Slide

  135. Recap
    Domic mirrors real DOM,
    but reactively

    View Slide

  136. Recap
    Domic applies diff of
    changes

    View Slide

  137. Recap
    Domic takes care of
    threading

    View Slide

  138. Recap
    Domic takes care of
    efficient rendering

    View Slide

  139. Recap
    Domic provides unified,
    reusable, type-safe API

    View Slide

  140. Recap
    Domic provides in-memory
    implementation for unit-testing

    View Slide

  141. Recap
    Why did I think that programming
    was a good idea?

    View Slide

  142. Public Availability

    View Slide

  143. https://github.com/lyft/domic
    Artem Zinnatullin, @artem_zin

    View Slide