Fork me on GitHub

@restenb @jacobhaag17 This is how you can pass a param to your nested subscription:

 (fn [_ your-param]]
   [(rf/subscribe [:the-sub-you-want-to-pass your-param])])
 (fn [[val-returned-by-above-subscription]]
   ;; You can do what you want in here with your returned value

Jacob Haag01:02:51

👏 I'll give a go


I was wondering if the majority of you guys stick with reg-sub or choose to go with reg-sub-raw and in what instances 🙂


The re-frame documentation does a good job at explaining when you would need reg-sub-raw


@lucio I stick with reg-sub. Haven't used reg-sub-raw in any of my apps so far


I'm not familiar with luminus, but my first instinct on seeing that code is that you shouldn't be sending the request from inside a subscription


you should use a reg-event-fx for the async part


and re-frame has had a built-in http client since last year, see


this example POST request should be all you need really


wow thanks I'll see http-fx stuff


yeah that version (using :http-xhrio key) was posted in re-frame doc as well, but reg-event-db was preceding that version in re-frame doc, that's why I used reg-event-db


anyway I'll look re-frame-http-fx


reg-event-db should be used for events that only need to update the app-db. events that need to cause effects like HTTP requests should use reg-event-fx

👍 5

the design behind re-frame is basically that everything that is imperative and causes effects gets pushed out to the event system, the GUI and the subscriptions should never initiate database calls for example


That being said there's a difference in opinion on whether every event needs to be tied in. Personally, I don't believe everything should go in there as a lot of local state only affects the one component so it is unnecessary to tie it in to the whole application. That does mean that then if you are using a tool such as 10x that it won't show up in there though.


For example, as i'm using Material-UI, I have a drawer set up. In that component it has a single state ratom that tracks whether or not the drawer is open or closed. Only that component needs to be aware of that so pulling that out to app-db is completely unnecessary and just adds extra code.


the view is simply rendered as a function of what's in the app-db at any given time, and the app-db is only modified through the event system


this is a common enough issue for people coming from redux backgrounds for example that it has it's own doc


ok this is the doc I referenced. I used version 1 in there.


yeah, "Version 1" in there is included only to point out why it's bad 🙂


yeah that's right


you should read the docs about effects and fx-handlers as well


I'll try version 2 as you said, and if I got problem I'll ask again 👍


ok very thank you I should read that too


since I got http status code 403, so I thought clientside request was successful, and there might be serverside code error, anyway I'll try version2 first!


im looking for a clean, data-driven (not event driven) way to coordinate longer running effectful flows. say, for example — do A with server, wait for response, on success do B, on failure do C… then chain something like that together 2-3 times. maybe something about racing in there too. there’s async-flow, but it seems fairly anemic for use cases outside of it’s intended flow. i remember Mike Thompson mentioned a while back that he’s been hammocking about state machines and how they relate to reframe. any progress on this? any libraries out there that help handle these flows?


It sounds like you are making the common misconception of what an event is in re-frame. It sounds like you are limiting events to only user-driven events. If you need to chain more events just dispatch them in the respective :on-success or :on-failure.


the problem is that chaining together events doesn’t really hold up to complex flows.


sure i can make a chain of 10 event handlers, but then my complex control logic is scattered everywhere and it becomes hard to trace


You said 2-3 and now you're saying 10 so which is it?


i could always divert to core.async, but sometimes that feels kind of icky too, particularly when you’re talking about lots of race conditions, if this then that, debuggability, etc.


@lwhorton not exactly data-driven, but i've used alet with funcool/promesa to achieve flows like that with promises (no events) - then dispatched an event when the result promise is fulfilled

👍 5

the approach falls down when you want to mix it with re-frame events though


Hi guys how do you deal with components that share functionality? i have custom typeahead component which could be used in few different places. I have 2 approaches in my mind i am really curious how you do it approach 1. pass a flag as argument to component and do bunch of if/else to decide which event is going to be dispatched on click etc... 2. pass dispatches as arguments and just plug args to component or even just event/sub ids


2nd seems more clean and re-frameish

✔️ 5

@lepistane 2 is a good approach. Works well for subscriptions also (send them as parameters to components when needed)


thank you for answering this quickly ! much appreciated !


hello everyone. just wondering - will there ever be isomorphic re-frame/reagent implementation?

Braden Shepherdson22:02:23

what do you mean by "isomorphic"?