reactive web applications with clojurescript and om

Transcript

1. REACTIVE APPLICATIONS WITH OM PIERRE-YVES RITSCHARD @PYR WEBMARDI

2. @PYR CTO at exoscale, swiss cloud hosting Open source developer:

   pithos, cyanite, riemann, collectd, cloudstack Cassandra MVP

3. AIM OF THIS TALK An introduction to clojure & clojurescript

   Show-casing a different method of building SPAs

4. OUTLINE What is Om ? Clojure(script) whirlwind tour Better views

   with React An Om walkthrough

5. OM

6. WHAT IT SAYS ON THE BOX A ClojureScript interface to

   Facebook's React. https://github.com/omcljs/om

7. OM SPECIFICS Small facade (< 2kLoC) for React No two-way

   binding! Data-based approach to UI Promotes immutability Interacts well with concurrency routines

8. OM IN THE LARGE Circle CI Prismatic Percursor Goya

9. OM AT EXOSCALE Warp Internal tools Our portal is still

   Angular.JS

10. BETTER VIEWS WITH REACT

11. WHAT IT SAYS ON THE BOX A JavaScript library for

    building user interfaces https://facebook.github.io/react

12. JUST THE UI React takes care of the view and

    does not care about the rest of the application structure. As a library it integrates well with other projects, such as Backbone.

13. VIRTUAL DOM Multiple buffering approach for the DOM. Changes are

    produced on a virtual DOM, differences are produced to the actual DOM in a single step.

14. DATA FLOW Departure from two-way binding. Easier to reason about.

    Say goodbye to d i g e s t a l r e a d y i n p r o g r e s s .

15. A COMPONENT BASED APPROACH Each component is responsible for a

    subset of the DOM and may implement functions which correspond to elements of the component's lifecycle: render (or renderState) willMount didMount willUnmount didUnmount

16. THE PROBLEM WITH REACT r e n d e r

    : f u n c t i o n ( ) { r e t u r n ( < d i v > < h 3 > T O D O < / h 3 > < T o d o L i s t i t e m s = { t h i s . s t a t e . i t e m s } / > < f o r m o n S u b m i t = { t h i s . h a n d l e S u b m i t } > < i n p u t o n C h a n g e = { t h i s . o n C h a n g e } v a l u e = { t h i s . s t a t e . t e x t } / > < b u t t o n > { ' A d d # ' + ( t h i s . s t a t e . i t e m s . l e n g t h + 1 ) } < / b u t t o n > < / f o r m > < / d i v > ) ; }

17. CLOJURE(SCRIPT): A WHIRLWIND TOUR

18. WHAT IT SAYS ON THE BOX Clojure is a dynamic

    programming language that targets the Java Virtual Machine (and the CLR, and JavaScript). http://clojure.org

19. CLOJURE SPECIFICS Dynamically typed LISP Homo-iconic Macros Functional programming language

    Immutable data structures & STM Runtime polymorphism Host independant

20. CLOJURE LIBRARIES & TOOLING Typing Pattern-matching Concurrency routines Building and

    running

21. DYNAMICALLY TYPED LISP ( + 1 2 ) ; ;

    = > 3 ( g e t { : f o o " b a r " } : f o o ) ; ; = > " b a r " ( c o u n t [ : a : b : c : d ] ) ; ; = > 4 ( l e t [ n 4 ] ( * n n ) ) ; ; = > 1 6

22. DYNAMICALLY TYPED LISP: VARIABLES ( d e f m y

    - v a r " h e l l o " ) ; ; = > # ' m y - v a r ( d e f n f a c t o [ n ] ( r e d u c e * ( m a p i n c ( r a n g e n ) ) ) ) ; ; = > # ' f a c t o

23. DYNAMICALLY TYPED LISP: LOOPS AND CONDITIONALS ( i f c

    o n d i t i o n ? t r u e - f o r m f a l s e - f o r m ) ( w h e n c o n d i t i o n ? t r u e - f o r m 1 t r u e - f o r m 2 ) ( d o s e q [ i ( r a n g e 1 0 ) ] ( p r i n t l n i ) ) 0

24. HOMO ICONIC ; ; k e y w o r

    d s : f i r s t - n a m e ; ; m a p s { : u s e r " p y r " : f i r s t - n a m e " P i e r r e - Y v e s " : l a s t - n a m e " R i t s c h a r d " } ; ; v e c t o r s [ 0 1 2 : f o o 3 4 : b a r ] ; ; s e t s # { : e g g p l a n t : z u c c h i n i : p o t a t o : c a r o t } ; ; f u n c t i o n s # ( + % 1 ) ; ; r e g e x # " ^ m y n a m e i s ( . * ) $ "

25. MACROS ( d e f m a c r o

    u n l e s s [ e x p & b o d y ] ( i f - n o t ~ e x p ( d o ~ @ b o d y ) ) ) ( u n l e s s s o m e - c o n d i t i o n d o - t h i s d o - t h a t )

26. MACROS ( d e f n f a c t

    o [ n ] ( - > > ( r a n g e 1 0 ) ( m a p i n c ) ( r e d u c e * ) ) )

27. DESTRUCTURING ( d e f u s e r {

    : u s e r " p y r " : f i r s t - n a m e " P i e r r e - Y v e s " : l a s t - n a m e " R i t s c h a r d " } ) ( l e t [ { : k e y s [ f i r s t - n a m e l a s t - n a m e ] } u s e r ] ( p r i n t l n " H e l l o " f i r s t - n a m e l a s t - n a m e ) )

28. FUNCTIONAL PROGRAMMING It is better to have 100 functions operate

    on one data structure than 10 functions on 10 data structures. —Alan Perlis ( - > { : u s e r " p y r " : h i s t o r y [ ] : s t a t s { : s e s s i o n - c o u n t 0 : l o g g e d - i n f a l s e } } ( a s s o c - i n [ : s t a t s : l o g g e d - i n ] t r u e ) ( u p d a t e - i n [ : s t a t s : s e s s i o n - c o u n t ] i n c ) ( u p d a t e - i n [ : h i s t o r y ] c o n j { : a c t i o n : l o g - i n : u s e r : p y r } ) )

29. FUNCTIONAL PROGRAMMING (CONT.) much better than underscore.js ; ; c

    o m p o s i t i o n ( c o m p n a m e k e y ) ( m a p ( c o m p n a m e k e y ) { : a c t i o n : l o g - i n : u s e r " p y r " } ) ; ; = > [ " a c t i o n " " u s e r " ] ; ; p a r t i a l a p p l i c a t i o n / c u r r y i n g ( d e f m y - i n c ( p a r t i a l + 1 ) ) ; ; c l o s u r e s ( d e f n i n c r e m e n t - b y [ n ] ( f n [ x ] ( + n x ) ) ) ( m a p ( i n c r e m e n t - b y 3 ) ( r a n g e 3 ) ) ; ; = > [ 3 4 5 ]

30. IMMUTABLE DATASTRUCTURES ( d e f u s e r

    - d a t a { : u s e r " p y r " : s t a t s { : s e s s i o n - c o u n t 0 } } ) ( d e f n r e c o r d - s e s s i o n [ u d ] ( u p d a t e - i n u d [ : s t a t s : s e s s i o n - c o u n t ] i n c ) ) ( r e c o r d - s e s s i o n u s e r - d a t a ) ; ; = > { : u s e r " p y r " : s t a t s { : s e s s i o n - c o u n t 1 } } u s e r - d a t a ; ; = > { : u s e r " p y r " : s t a t s { : s e s s i o n - c o u n t 0 } }

31. STM ( d e f u s e r -

    d a t a ( a t o m { : u s e r " p y r " : s t a t s { : s e s s i o n - c o u n t 0 } } ) ) ( d e f n r e c o r d - s e s s i o n [ u d ] ( u p d a t e - i n u d [ : s t a t s : s e s s i o n - c o u n t ] i n c ) ) ( s w a p ! u s e r - d a t a r e c o r d - s e s s i o n ) ; ; = > { : u s e r " p y r " ; ; : s t a t s { : s e s s i o n - c o u n t 1 } } @ u s e r - d a t a ; ; = > { : u s e r " p y r " ; ; : s t a t s { : s e s s i o n - c o u n t 1 } }

32. RUNTIME POLYMORPHISM: MULTIMETHODS ( d e f m u l

    t i h a n d l e - e v e n t : a c t i o n ) ( d e f m e t h o d h a n d l e - e v e n t : l o g - i n [ { : k e y s [ u s e r ] } ] ( p r i n t l n " u s e r " u s e r " h a s l o g g e d i n " ) ) ( d e f m e t h o d h a n d l e - e v e n t : l o g - o u t [ { : k e y s [ u s e r ] } ] ( p r i n t l n " u s e r " u s e r " h a s l o g g e d i n " ) ) ( h a n d l e - e v e n t { : a c t i o n : l o g - i n : u s e r " p y r " } ) ( h a n d l e - e v e n t { : a c t i o n : l o g - o u t : u s e r " p y r " } )

33. RUNTIME POLYMORPHISM: PROTOCOLS ( d e f p r o

    t o c o l K V D a t a b a s e ( s e t k e y ! [ t h i s k v ] ) ( g e t k e y [ t h i s k ] ) ) ( d e f n a t o m - d a t a b a s e [ ] ( l e t [ d b ( a t o m { } ) ] ( r e i f y K V D a t a b a s e ( s e t k e y ! [ t h i s k v ] ( s w a p ! d b a s s o c k v ) ) ( g e t k e y [ t h i s k ] ( g e t @ d b k ) ) ) ) )

34. NAMESPACES ( n s w e b a p p

    . f r o n t e n d ( : r e q u i r e [ o m . d o m : a s d o m ] [ s a b l o n o . c o r e : r e f e r - m a c r o s [ h t m l ] ] ) )

35. HOST INDEPENDANT JVM, CLR, Javascript (relies on Google Closure). Interop

    is a first class citizen: ( . l o g j s / w i n d o w . c o n s o l e " h e l l o " )

36. SIMPLE EXAMPLE: AN HTTP + JSON REQUEST: ( n s

    f o o b a r ( : r e q u i r e [ a j a x . c o r e : r e f e r [ G E T ] ] ) ) ( d e f n h a n d l e - r e s p o n s e [ d a t a ] . . . ) ; ; A u t o m a t i c a l l y i n f e r s f o r m a t f r o m C o n t e n t - T y p e ( G E T " / m y - e n d p o i n t " { : h a n d l e r h a n d l e - r e s p o n s e } ) ; ; H i n t a t f o r m a t ( P U T " / m y - e n d p o i n t " { : p a r a m s { : f o o " b a r " } : f o r m a t : j s o n } )

37. CLOJURESCRIPT ESSENTIAL LIBS: CORE.ASYNC ( n s t a b

    l e f l i p . c o r e ( : r e q u i r e - m a c r o s [ c l j s . c o r e . a s y n c . m a c r o s : r e f e r [ g o ] ] ) ( : r e q u i r e [ c l j s . c o r e . a s y n c : r e f e r [ t i m e o u t < ! ] ] ) ) ( g o ( l o o p [ [ c u r & n e x t ] ( c y c l e [ " ┬ ─ ┬ ノ( º _ º ノ) " " ( ╯ ° □ ° ）╯ ︵ ┻ ━ ┻ " " ( ╯ ° □ ° ）╯ ┬ ─ ┬ " " ( ╯ ° □ ° ）╯ ┻ ━ ┻ " " ( ╯ ° □ ° ）╯ ┬ ─ ┬ " " ( ╯ ° □ ° ）╯ ┻ ━ ┻ " ] ) ] ( . r e p l a c e S t a t e j s / w i n d o w . h i s t o r y # j s { } " " ( s t r " / # " c u r ) ) ( < ! ( t i m e o u t 1 0 0 0 ) ) ( r e c u r n e x t ) ) )

38. CLOJURESCRIPT ESSENTIAL LIBS: CORE.MATCH ( d o s e q

    [ n ( r a n g e 1 1 0 1 ) ] ( p r i n t l n ( m a t c h [ ( m o d n 3 ) ( m o d n 5 ) ] [ 0 0 ] " F i z z B u z z " [ 0 _ ] " F i z z " [ _ 0 ] " B u z z " : e l s e n ) ) )

39. CLOJURESCRIPT ESSENTIAL LIBS: OPTIONAL TYPING Compile time: core.typed Runtime: schema

40. BUILDING CLOJURESCRIPT Not bound to a specific build tool People

    usually choose (upside: no grunt or gulp debate) leiningen

41. BUILDING CLOJURESCRIPT ( d e f p r o j

    e c t m y - p r o j e c t " 0 . 1 . 0 " : d e p e n d e n c i e s [ [ o r g . c l o j u r e / c l o j u r e " 1 . 6 . 0 " ] [ o r g . c l o j u r e / c l o j u r e s c r i p t " 0 . 0 - 3 1 2 6 " ] [ o r g . o m c l j s / o m " 0 . 8 . 8 " ] : p l u g i n s [ [ l e i n - c l j s b u i l d " 1 . 0 . 5 " ] ] : c l j s b u i l d { : b u i l d s [ { : i d " d e v " : s o u r c e - p a t h s [ " s r c " ] : c o m p i l e r { : m a i n " j o b s . f r o n t e n d " : o u t p u t - t o " r e s o u r c e s / p u b l i c / j s / a p p . j s " : o u t p u t - d i r " r e s o u r c e s / p u b l i c / j s " : o p t i m i z a t i o n s : n o n e : s o u r c e - m a p t r u e } } ] } )

42. COMPILING AND RUNNING l e i n c l j

    s b u i l d o n c e l e i n c l j s b u i l d a u t o

43. OM WALKTHROUGH

44. BINDING CLOJURESCRIPT AND REACT All application state is stored in

    an atom. Changes in an atom result in UI updates Binds to react through protocols

45. BINDING CLOJURESCRIPT AND REACT: PROTOCOLS A component reifies: IRenderState or

    IRender ( f n [ a p p o w n e r ] ( r e i f y I R e n d e r ( r e n d e r [ t h i s ] ( d o m / h 1 " h e l l o " ) ) ) )

46. OM APPLICATION BASICS Applications are trees of components bound to

    a part of the application state which generate nodes in the virtual dom.

47. OM APPLICATION BASICS ( d e f a p p

    - s t a t e ( a t o m { : j o b s [ { : t i t l e " d e v e l o p e r " : c o m p a n y " r a i l s s h o p " } { : t i t l e " s y s a d m i n " : c o m p a n y " p h p s h o p " } ] } ) ) ( d e f c o m p o n e n t j o b - l i n e [ p o s i t i o n o w n e r ] ( r e n d e r [ t h i s ] ( l e t [ t i t l e ( : t i t l e a p p ) c o m p a n y ( : c o m p a n y p o s i t i o n ) ] ( h t m l [ : l i ( s t r t i t l e " a t " c o m p a n y ) ] ) ) ) ) ( d e f c o m p o n e n t j o b - l i s t [ a p p o w n e r ] ( r e n d e r [ t h i s ] ( l e t [ j o b s ( : j o b s a p p ) ] ( h t m l [ : u l ( o m / b u i l d - a l l j o b - l i n e j o b s ) ] ) ) ) ) ( o m / r o o t j o b - l i s t a p p - s t a t e )

48. OM APPLICATION BASICS

49. ROUTING There is no routing component in om. It's easy

    to build one leveraging the application state Example approach: https://github.com/pyr/om- jobs/blob/master/src/jobs/router.cljs ; ; P a i r s o f r o u t e t o c o m p o n e n t ( d e f r o u t e s [ " / " v i e w s / j o b s " / j o b / : i d " v i e w s / j o b " / p o s t " v i e w s / j o b - p o s t ] ) ( l e t [ r o u t e r ( r o u t e r / i n i t r o u t e s a p p - s t a t e ) t a r g e t { : t a r g e t ( . g e t E l e m e n t B y I d j s / d o c u m e n t " a p p " ) } ] ( o m / r o o t r o u t e r a p p - s t a t e t a r g e t ) )

50. USER INPUT Two approaches: Local component state Circling back to

    the global app-state

51. USER INPUT: LOCAL COMPONENT STATE ( d e f c

    o m p o n e n t j o b - p o s t [ a p p o w n e r ] ( r e n d e r - s t a t e [ t h i s s t a t e ] ( l e t [ t i t l e ( : t i t l e s t a t e ) c o m p a n y ( : c o m p a n y s t a t e ) c r e a t e ! ( : c r e a t e ! a p p ) - > s t a t e ( f n [ k ] ( f n [ e v e n t ] ( o m / s e t - s t a t e ! o w n e r [ k ] ( - > e v e n t . - t a r g e t . - v a l u e ) ) ) ) ] ( h t m l [ : f o r m [ : l a b e l " t i t l e " ] [ : i n p u t { : t y p e " t e x t " : v a l u e t i t l e : o n - c h a n g e ( - > s t a t e : t i t l e ) } ] [ : l a b e l " c o m p a n y " ] [ : i n p u t { : t y p e " t e x t " : v a l u e c o m p a n y : o n - c h a n g e ( - > s t a t e : c o m p a n y ) } ] [ : i n p u t { : t y p e " s u b m i t " : o n - c l i c k ( f n [ _ ] ( c r e a t e ! s t a t e ) ) } ] ] ) ) ) )

52. USER INPUT: GLOBAL STATE ( d e f m o

    d e l - c h a n ( c h a n ) ) ( g o ( l o o p [ a c t i o n ( < ! m o d e l - c h a n ) ] ( l e t [ t y p e ( : t y p e a c t i o n ) i d ( : i d a c t i o n ) ] ( c o n d p = t y p e : d e l e t e ( s w a p ! a p p - s t a t e d i s s o c i d ) : c r e a t e ( s w a p ! a p p - s t a t e a s s o c i d a c t i o n ) ) ) ) ) ( d e f c o m p o n e n t j o b - l i n e [ a p p o w n e r ] ( r e n d e r [ t h i s ] [ : l i [ : d i v [ : p ( : t i t l e a p p ) " a t " ( : c o m p a n y a p p ) ] [ : b u t t o n { : o n - c l i c k ( f n [ _ ] ( > ! m o d e l - c h a n { : t y p e : d e l e t e : i d ( : i d a p p ) } ) ) } ] ] ] ) )

53. OM USE-CASES

54. COMPARED TO ANGULAR More up-front work Better reasoning around components

    Not a fit for small CRUD apps

55. BEST FITS Complex app logic Websockets / SSE (event-stream) Multiple

    presentation of a single source of data

56. WHAT WE DID NOT SAY Infinite undo Component mixins Targets

    Node.JS Targets JavascriptCore HTML templates Source maps REPLs

57. GOING FURTHER Om: Angular to Om: A simple job board:

    https://github.com/omcljs/om http://spootnik.org/entries/2014/10/26_from-angularjs-to- om-a-walk-through.html https://github.com/pyr/om-jobs

58. QUESTIONS ?