Fork me on GitHub

Do you use trim-v by default in event handlers?

David Pham05:05:02

Nope. Adding a line vs adding an underscore was the trade off. Moreover I like to have access to the event by default in my handler.


I have my own versions of reg-event-* functions that I use in my projects that add trim-v by default, along with some other interceptors.


@p-himik I've been browsing old re-frame issues, cleaning up. I'd be interested to know where you stand now on this issue


Thanks for asking. I'll gather my thoughts later today and get back to you.


Of course, I'm subscribed to the issue. :)


I left a comment on the gist.


Regarding where I stand - sigh, yeah, I still "suffer" because of passing around maps of parameters and using multimethods. I'm think about it from time to time and read some relevant articles ( and are pretty good IMO). But so far the best idea that I have in mind is to pass everywhere a single ctx that would contain "higher-order dispatch and subscribe". From the POV of sub-components, they're just regular functions, the ones everybody's used to. From the POV of outer components, they're functions that alter the default behavior of subscribe or dispatch. It may be injecting some sub-paths somehow, it may be changing some parameters (depending on what the sub-components ask for), resolving to the default behavior, or even being a no-op. Alas, I haven't had the time to test it on a "real world application". I feel like for me to try it out properly I would need a sabbatical.


Does anyone have good examples of the kinds of issues that overusing ‘dispatch-sync’ would cause?


Is there a name for the double-colon ::model/dispatch pattern? I’m trying to learn a codebase that dispatches events this way. It seems model is the name of an aliased requirement, but I can’t seem to be able to recreate this on my own. Also, new to re-frame.


I see an error no :event handler registered for: in the console. It does appear to be pointing to my proper NS


Ah nice… so i dispatch ::model/fetch and then in the model ::fetch picks it up! Thanks!


What's the right place to implement (effectful) event retries or other "Middleware" that causes side effects? E.g. an event that calls a http endpoint, if it results in a 401, fetch the token from another endpoint, then dispatch again? Seems like it could quickly lead to event spaghetti.


Can interceptors be async? :thinking_face:


I think I’ve seen people using to do similar things

thanks2 4

^ +1 Used async-flow-fx successfully for a small state machine, very similar to what you've described. For large things it might get unwieldy, though

Peter Tylka21:05:12

Hello, I am just starting with re-frame and I have a question. On :load-data event I would like to load data into db from Parse server. I call Parse cloud function which returns promise, so it is not AJAX call and I cannot use re-frame-http-fx. Is there any other way or I just have to dispatch another events on promise resolve/reject? Thanks


@ptylka Your :load-data event should dispatch an effect (let’s call it :parse-effect). In the :parse-effect handler you would call Parse, and when the promise resolves, you would dispatch another event like :load-data-into-db-from-parse-response which takes the response, parses it, and loads it into the app-db.