Fork me on GitHub

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 !


too late now to do anything about it though =)


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


hah well i was only nitpicking with those arrows =)


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


let me know if you find bugs ! now back to regular app dev =)