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
   

   View Slide

2. View Slide

3. REST: expectations
   • define logical “resources”
   • identified by URIs
   • clients request them
   

   View Slide

4. Luke Wroblewski
   

   View Slide

5. REST: reality
   

   View Slide

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.”
   

   View Slide

7. View Slide

8. View Slide

9. View Slide

10. 1. clients can request the exact
    total response they need
    2. clients can communicate
    novelty atomically
    • without sacrificing relational
    queries on the server
    

    View Slide

11. View Slide

12. Quiescent
    om.core
    

    View Slide

13. View Slide

14. View Slide

15. View Slide

16. om.next
    

    View Slide

17. Om Next opinions
    • Single source of truth
    • Minimize flushing to DOM
    • Abstract asynchrony
    • No (visible) event model
    

    View Slide

18. View Slide

19. [:person/name]
    

    View Slide

20. (defui Person
    static om/IQuery
    (query [this]
    [:person/name])
    Object
    (render [this]
    ...))
    

    View Slide

21. Parser
    •
    f (query) = data
    [:person/name]
    {:person/name “António”}
    

    View Slide

22. Parser
    • reads & mutations
    • Runs on the client and server
    • Hydrate queries
    • no reshaping!
    • Edge of the system
    

    View Slide

23. View Slide

24. {:people [{:person/name “Alice”
    :person/age 25}
    {:person/name “Bob”
    :person/age 34}]
    :favorites [{:person/name “Bob”
    :person/age 34}]}
    

    View Slide

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}}
    

    View Slide

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}}}
    

    View Slide

27. [(person/add!
    {:person/name “António”
    :person/address
    {:address/street
    “Hochschulstraße”
    :address/zip
    “01069”}})]
    

    View Slide

28. [(delete/friend! {:me 1
    :friend 2})
    :friends/list]
    Re-read this key
    

    View Slide

29. Creating information
    • Create temporary information
    on client
    • Remote mutation hits server
    • Server replies with mappings
    • tempids → real ids
    

    View Slide

30. Demo
    

    View Slide

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
    

    View Slide

32. Project status
    • very close to beta
    • documentation
    • github.com/omcljs/om/wiki
    • awkay.github.io/om-tutorial/
    • anmonteiro.com
    

    View Slide

33. Takeaways
    • we can radically simplify UI
    programming
    • regardless of library / framework
    • strive for simple systems
    • with these 2 properties
    

    View Slide

34. github.com/anmonteiro/talks
    

    View Slide

35. Questions?
    

    View Slide