Persistent data structures, good for UI

@danieroux
Persistent data structures, good for UI
… You & I (sorry)

@danieroux
Modelling Chess
e2-e4
e2-e4
e2-e4

d7-d6
e2-e4

d7-d6
e2-e4

d7-d6

d2-d4
e2-e4

d7-d6

d2-d4
LIE
The conceptual model
does not match reality
Reality
e2-e4
d7-d6
d2-d4
… but what if we keep a
move list
1. e2-e4
2. d7-d6
3. d2-d4
Get back here

1. e2-e4
2. d7-d6
3. d2-d4
Move list is not
reversible …
Keep all the states
Full History
Partial History
react.js
Developer
Machine

react.js
Developer
(person)

Machine

react.js
Developer
(person)

Machine

react.js
Developer
(person)

Machine

Virtual DOM

DOM

react.js
Developer
(person)

Continuously

Machine

Virtual DOM

DOM

react.js
Developer
(person)

Continuously

Machine

Virtual DOM

DOM

Draws new
react.js
Developer
(person)

Continuously

Machine

Virtual DOM

DOM

requestAnimationFrame

Draws new
react.js
Developer
(person)

Continuously

Machine

Virtual DOM

DOM

requestAnimationFrame

Draws new
react.js
Developer
(person)

DOM

Virtual DOM

Draws new

MAGIC

Continuously

Machine

requestAnimationFrame

react.js
Magic = Tree Diffing
And persistent/immutable data structures make that cheaper
Separating concerns
State

Rendering
World

State

Rendering
Logic

World

State

Rendering
Logic

World

State

TIME

Rendering
Logic

World
Updates

State

TIME

Rendering
Logic

World
Uses

Updates

State

TIME

Rendering
Logic

World
Uses

Updates

State

TIME

Value

Rendering
Logic

World
Uses

Updates

State

TIME
Snapshots

Value

Rendering
Logic

World
Uses

Updates

State

TIME
Snapshots

Value

Renders

Rendering
Example code:
!

https://github.com/danieroux/rubyfuza2014
http://facebook.github.io/react
https://github.com/swannodette/om
https://github.com/danieroux/rubyfuza2014

?
Thank you t...
Persistent data structures - good for UI (presented at Rubyfuza 2014)
Persistent data structures - good for UI (presented at Rubyfuza 2014)
Persistent data structures - good for UI (presented at Rubyfuza 2014)
Persistent data structures - good for UI (presented at Rubyfuza 2014)
Persistent data structures - good for UI (presented at Rubyfuza 2014)
Persistent data structures - good for UI (presented at Rubyfuza 2014)
Persistent data structures - good for UI (presented at Rubyfuza 2014)
Persistent data structures - good for UI (presented at Rubyfuza 2014)
Persistent data structures - good for UI (presented at Rubyfuza 2014)
Persistent data structures - good for UI (presented at Rubyfuza 2014)
Persistent data structures - good for UI (presented at Rubyfuza 2014)
Persistent data structures - good for UI (presented at Rubyfuza 2014)
Upcoming SlideShare
Loading in …5
×

Persistent data structures - good for UI (presented at Rubyfuza 2014)

5,268 views

Published on

Persistent data structures are being imported from the FP world.

What makes persistent data structures particularly interesting is that they cannot be modified in the traditional sense. These structures can model a timeline of changes quite naturally since every "change" creates a new "copy".

"Functional Reactive Programming" is another old/new idea. FRP has a time centric viewpoint.

Having persistent data structures on the Javascript/UI side of the world unlocks a lot of the magic that FRP has to offer.

In this talk Danie will explain why persistent data structures are good and specifically why they are good for (the) UI.

Published in: Technology

Persistent data structures - good for UI (presented at Rubyfuza 2014)

  1. 1. Persistent data structures, good for UI @danieroux
  2. 2. Persistent data structures, good for UI … You & I (sorry) @danieroux
  3. 3. Modelling Chess
  4. 4. e2-e4
  5. 5. e2-e4
  6. 6. e2-e4 d7-d6
  7. 7. e2-e4 d7-d6
  8. 8. e2-e4 d7-d6 d2-d4
  9. 9. e2-e4 d7-d6 d2-d4
  10. 10. LIE
  11. 11. The conceptual model does not match reality
  12. 12. Reality
  13. 13. e2-e4
  14. 14. d7-d6
  15. 15. d2-d4
  16. 16. … but what if we keep a move list
  17. 17. 1. e2-e4 2. d7-d6 3. d2-d4
  18. 18. Get back here 1. e2-e4 2. d7-d6 3. d2-d4
  19. 19. Move list is not reversible …
  20. 20. Keep all the states
  21. 21. Full History
  22. 22. Partial History
  23. 23. react.js
  24. 24. Developer Machine react.js
  25. 25. Developer (person) Machine react.js
  26. 26. Developer (person) Machine react.js
  27. 27. Developer (person) Machine Virtual DOM DOM react.js
  28. 28. Developer (person) Continuously Machine Virtual DOM DOM react.js
  29. 29. Developer (person) Continuously Machine Virtual DOM DOM Draws new react.js
  30. 30. Developer (person) Continuously Machine Virtual DOM DOM requestAnimationFrame Draws new react.js
  31. 31. Developer (person) Continuously Machine Virtual DOM DOM requestAnimationFrame Draws new react.js
  32. 32. Developer (person) DOM Virtual DOM Draws new MAGIC Continuously Machine requestAnimationFrame react.js
  33. 33. Magic = Tree Diffing And persistent/immutable data structures make that cheaper
  34. 34. Separating concerns
  35. 35. State Rendering
  36. 36. World State Rendering
  37. 37. Logic World State Rendering
  38. 38. Logic World State TIME Rendering
  39. 39. Logic World Updates State TIME Rendering
  40. 40. Logic World Uses Updates State TIME Rendering
  41. 41. Logic World Uses Updates State TIME Value Rendering
  42. 42. Logic World Uses Updates State TIME Snapshots Value Rendering
  43. 43. Logic World Uses Updates State TIME Snapshots Value Renders Rendering
  44. 44. Example code: ! https://github.com/danieroux/rubyfuza2014
  45. 45. http://facebook.github.io/react https://github.com/swannodette/om https://github.com/danieroux/rubyfuza2014 ? Thank you to: http://designindevelopment.com/css/css3-chess-board @danieroux … let’s have coffee

×