Clojurians Log v2

I'm a bit more ornery in that I believe that just events are too low-level for app building

re-frame's event system is nice from a perspective of purity, but IMO an event system should be something we strive to build higher-level abstractions on top of

unfortunately, re-frame's API, docs and general guidance encourage developers to use re-frame events as the language they use to implement their app, which makes common things like accessing a piece of data asynchronously tedious and error prone

promises are wonderful abstractions for a huge amount of use cases; they are composable (events: must build your own composition), they are completable and failable (events: must build your own completion and failure mechanisms), and have an identity (events: must build your own way of identifying between different occurrences)

unfortunately they lack cancellation, which events can get you... if you build it and all of the other things 😄

Absolutely agree.

Anything jump out as examples we can learn from?

I've seem a few FSM libraries built [with support]for re-frame. Or just libraries that remove the need for some boilerplate. This one just yesterday: https://lucywang000.github.io/clj-statecharts/docs/integration/re-frame/ Others: - https://github.com/ingesolvoll/re-chain - https://github.com/Guaranteed-Rate/re-flow There was another one but I didn't save it - I remember not liking it because it heavily relied on side-effects in event handlers. Should've still saved it though. But I haven't used any of them yet.

statecharts is an area I think we're still trying to find the right approach with, with regards to what level the APIs should act on. Definitely warrants more exploring though. Some more libs with statecharts+re-frame: • https://github.com/MaximGB/re-state • https://github.com/jiangts/re-state And finally, re-frame EP about general state machines, seems @mikethompson is leaning towards behavior trees instead of statecharts though, at least from what I gathered from a podcast he was in, talking about re-frame: https://github.com/day8/re-frame/blob/master/docs/EPs/005-StateMachines.md

also, good general introduction to statecharts and how they can be beneficial: https://statecharts.github.io/

Thanks for the links. Also, not sure if it's the same lib I was talking about but MaximGB/re-state definitely does dirty things.

But maybe it's practicality vs purity in this case, not sure.

yeah, guess it's the same trade-off that re-frame is doing with the registers (or is it registrar?) where there is just one global one for practicalities sake. There is a doc in the re-frame repo somewhere talking about this but not finding it atm

I have a very stupid problem with re-frame-http-fx, for some reason it does not seem to honor my :format key and instead always sends the request with *Content-Type:* application/x-www-form-urlencoded;charset=UTF-8, which means that muuntaja fails to decode the request body. When I send the same payload over curl manually setting the headers, it works and decodes. Am I doing something wrong or have I misunderstood? If I read the the clj-ajax docs it claims that the default content-type should be edn, but removing the :format key does nothing. (reg-event-fx ::submit-session (fn [_ [_ session]] {:http-xhrio {:method :post :uri "<http://localhost:3131/api/submit/session>" :timeout 8000 :body (util/-&gt;transit+json session) :format (ajax/transit-request-format) :response-format (ajax/transit-response-format {:keywords? true}) :on-failure [:http/failure]}}))

I have a complex ui element (like on the level of a small application), distributed as its own library. let's say the purpose of it is to describe properties of a house. in one application I want to use this complex ui element and show multiple data for multiple houses. Is it the best way to pass along the id for the house in every function call (rf dispatch/subscribe) or is there some other, more clever pattern for this? I'd almost like to initiate the view with the id of the house (if this was o-o). Perhaps the best plan is to store the id in a url and get it from the for each sub/dispatch call? unless I'm missing something even simpler