Om Next: motivation & design

This is a short talk I gave at the berlin Clojure meetup. I explore the motivation behind Om Next's design, what its main features are and what problems it is designed to solve.

Transcript

1. Om Next Motivation & design Berlin Clojure User Group @anmonteiro90
3. REST: expectations • define logical “resources” • identified by URIs • clients request them
4. Luke Wroblewski
5. REST: reality
6. – Roy T. Fielding, PhD “The trade-off, though, is that a uniform interface degrades efficiency, since information is transferred in a standardized form rather than one which is specific to an application's needs.”
10. 1. clients can request the exact total response they need 2. clients can communicate novelty atomically • without sacrificing relational queries on the server
12. Quiescent om.core
16. om.next
17. Om Next opinions • Single source of truth • Minimize flushing to DOM • Abstract asynchrony • No (visible) event model
19. [:person/name]
20. (defui Person static om/IQuery (query [this] [:person/name]) Object (render [this] ...))
21. Parser • f (query) = data [:person/name] {:person/name “António”}
22. Parser • reads & mutations • Runs on the client and server • Hydrate queries • no reshaping! • Edge of the system
24. {:people [{:person/name “Alice” :person/age 25} {:person/name “Bob” :person/age 34}] :favorites [{:person/name “Bob” :person/age 34}]}
25. {:people [[:person/by-name “Alice”] {:person/name “Bob” :person/age 34}] :favorites [{:person/name “Bob” :person/age 34}] :person/by-name {“Alice” {:person/name “Alice” :person/age 25}}
26. {:people [[:person/by-name “Alice”] [:person/by-name “Bob”]] :favorites [[:person/by-name “Bob”]] :person/by-name {“Alice” {:person/name “Alice” :person/age 25} “Bob” {:person/name “Bob” :person/age 34}}}
27. [(person/add! {:person/name “António” :person/address {:address/street “Hochschulstraße” :address/zip “01069”}})]
28. [(delete/friend! {:me 1 :friend 2}) :friends/list] Re-read this key
29. Creating information • Create temporary information on client • Remote mutation hits server • Server replies with mappings • tempids → real ids
30. Demo
31. Server • Clojure preferred / less boilerplate • Other languages -> implement parser logic • easier for languages with Transit • Datomic supported by default • other DBs work as well
32. Project status • very close to beta • documentation • github.com/omcljs/om/wiki • awkay.github.io/om-tutorial/ • anmonteiro.com
33. Takeaways • we can radically simplify UI programming • regardless of library / framework • strive for simple systems • with these 2 properties
34. github.com/anmonteiro/talks
35. Questions?