This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-07-16
Channels
- # aleph (2)
- # announcements (1)
- # beginners (162)
- # calva (16)
- # cider (37)
- # cljdoc (9)
- # cljs-dev (2)
- # cljsrn (3)
- # clojure (86)
- # clojure-dev (17)
- # clojure-europe (3)
- # clojure-houston (1)
- # clojure-italy (6)
- # clojure-nl (3)
- # clojure-spec (10)
- # clojure-uk (20)
- # clojuredesign-podcast (15)
- # clojurescript (7)
- # data-science (14)
- # datascript (1)
- # datomic (5)
- # emacs (8)
- # figwheel-main (8)
- # fulcro (25)
- # graalvm (1)
- # jobs (10)
- # jobs-discuss (4)
- # keechma (14)
- # leiningen (2)
- # off-topic (31)
- # onyx (1)
- # other-languages (4)
- # pathom (4)
- # pedestal (1)
- # re-frame (20)
- # remote-jobs (4)
- # shadow-cljs (25)
- # sql (6)
- # tools-deps (15)
- # vim (18)
- # xtdb (9)
I have a question, those behavior trees can send events, and the controller has an API to execute these. they're passed the controller itself, the app-db-atom and the event arg
The question is, should they, in your opinion, receive the app-db-atom or just the app-db, leaving them to other devices if they want to update it
or maybe let them return a naked app-db ... I opted for the app-db-atom thinking that's the most versatile
Also i disagree with the direction of your <cmd arrows ! you're viewing this from the perspective of the guy that made the controller, rather than the user, and it's the opposite direction compared to core.Async !
I use app-db-atom for lower level interfaces, because it makes it easier to build abstractions on top of it, and app-db for apis that have deref and timing guarantees. As for the arrows on cmd and sub, they are from the perspective of a component (incoming or outgoing). I think they were inspired by some re-frame wiki page with the ideas for helper apis, so I picked it up from there :)
The lib looks really interesting, can't wait to do a deep dive
There is no timing garanties in this case, those events are there to start websockets or do any number of other side effecting stuff, so i guess i'll keep it as is
there is an overlap with pipelines, my stuff is more verbose, bigger machinery, probably a bit slower, but is more versatile and totally testable
This looks very powerful, and I'll have to dig in more, but I did have cases where something like this would be a perfect fit