lilactown 2020-10-16T06:58:28.126300Z

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

lilactown 2020-10-16T06:59:29.126500Z

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

lilactown 2020-10-16T07:01:56.126700Z

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

lilactown 2020-10-16T07:06:12.127Z

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)

lilactown 2020-10-16T07:06:38.127200Z

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

p-himik 2020-10-16T07:09:19.127400Z

Absolutely agree.

Oliver George 2020-10-16T07:15:14.128500Z

Anything jump out as examples we can learn from?

p-himik 2020-10-16T07:22:55.128700Z

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: Others: - - 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.

victorb 2020-10-16T10:48:58.129500Z

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: • 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:

victorb 2020-10-16T10:49:41.129700Z

also, good general introduction to statecharts and how they can be beneficial:

p-himik 2020-10-16T11:13:08.130Z

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.

p-himik 2020-10-16T11:13:28.130200Z

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

victorb 2020-10-16T11:23:05.130400Z

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

motform 2020-10-16T14:45:39.133400Z

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

motform 2020-10-17T13:52:23.142600Z

oh crap, of course, I thought :params where for query params only. thank you!

kaosko 2020-10-16T22:22:27.139600Z

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

kaosko 2020-10-17T08:01:05.141100Z

Thanks @p-himik, I'm glad that the documentation certainly has gotten better - it's been a while since I last visited the page. It's interesting to note I had arrived at the exact same best practice concepts without reviewing the documentation. first, that I have to pass the id along and that I can at least package the args into entity specific fns. Perhaps I was looking for yet another level but this at least confirms I'm on the right path