does the http-fx library encourage you to handle the http logic as an event? if so, why? we were considering hiding that we were making a http call, by which i mean making our request handler a effect handler. is there a reason to not go this route? i ask because it seems akward to call dispatch inside a effect handler e.g reg-fx ::request (dispatch :http-xhiro) i think im having a issue with having my dispatch name be xhiro rather then something like http/request from a readability perspective and also as a way to decouple things a bit

hello everyone, just studying re-frame (wonderful piece of work, very educational). I’m wondering if a re-frame app could take advantage by using a pub/sub stream instead of an event queue

what do re-framers think about this?

Reframe under the hood, is making an HTTP OPTIONS call to /my/endpoint. But I don’t see documentation for this? Is there a way to control or turn this off?

2xhrio.js:620 OPTIONS  404 (Not Found)
  goog.net.XhrIo.send @ xhrio.js:620
  goog.net.XhrIo.ajax$protocols$AjaxImpl$_js_ajax_request$arity$3 @ xhrio.cljs:23
  ajax$protocols$_js_ajax_request @ protocols.cljc:6
  ajax$core$raw_ajax_request @ core.cljc:500
  ajax$core$ajax_request @ core.cljc:503
  day8$re_frame$http_fx$http_effect @ http_fx.cljs:87
  (anonymous) @ fx.cljc:39
  (anonymous) @ core.cljs:4466
  cljs.core.map.cljs$core$IFn$_invoke$arity$2 @ core.cljs:4466
  cljs.core.LazySeq.sval @ core.cljs:3223
  cljs.core.LazySeq.cljs$core$ISeqable$_seq$arity$1 @ core.cljs:3277
  cljs$core$seq @ core.cljs:1107
  cljs.core.Cons.cljs$core$INext$_next$arity$1 @ core.cljs:3065
  cljs$core$next @ core.cljs:1152
  cljs.core.LazySeq.cljs$core$INext$_next$arity$1 @ core.cljs:3260
  cljs$core$next @ core.cljs:1152
  cljs.core.dorun.cljs$core$IFn$_invoke$arity$1 @ core.cljs:9033
  cljs.core.doall.cljs$core$IFn$_invoke$arity$1 @ core.cljs:9046
  cljs$core$doall @ core.cljs:9038
  re_frame$fx$do_fx_after @ fx.cljc:40
  re_frame$interceptor$invoke_interceptor_fn @ interceptor.cljc:68
  re_frame$interceptor$invoke_interceptors @ interceptor.cljc:106
  re_frame$interceptor$execute @ interceptor.cljc:199
  re_frame$events$handle @ events.cljc:59
  re_frame.router.EventQueue.re_frame$router$IEventQueue$_process_1st_event_in_queue$arity$1 @ router.cljc:169
  re_frame$router$_process_1st_event_in_queue @ router.cljc:82
  re_frame.router.EventQueue.re_frame$router$IEventQueue$_run_queue$arity$1 @ router.cljc:188
  re_frame$router$_run_queue @ router.cljc:84
  (anonymous) @ router.cljc:140
  re_frame.router.EventQueue.re_frame$router$IEventQueue$_fsm_trigger$arity$3 @ router.cljc:159
  re_frame$router$_fsm_trigger @ router.cljc:78
  (anonymous) @ router.cljc:177
  channel.port1.onmessage @ nexttick.js:211

@twashing i don't think you have much control over an OPTIONS request. your browser is doing that to see what it's allowed to ask for. it's not re-frame specific.

Hmm, then that stacktrace is deceptive. Because that’s what’s making the OPTIONS call.

are you using the re-frame-http-fx?

(updated the code block to reflect)

lemme check..

what happens when you visit https://foobar/my/endpoint in your browser?

Hmm, both GET and OPTIONS returns a 404.

sounds like it's a problem with the server and not your app. are you hosting locally? with a proper certificate, hence the https?

Yeah, very strange. Ok, let me dig a bit deeper. Maybe server config changed or something.