Clojurians Log v2

I've also found the domain/ui split useful.

Esp for domain data have been looking into datascript, datahike and the like for flat storage and datalog querying of data. So far its obvious that posh/re-posh should be avoided as the query analyzer is significantly slower than the queries themselves (e.g. see https://github.com/athensresearch/athens/pull/665). Otherwise havn't made many conclusions so far. I'm considering if async cofx/interceptor chains should be supported for datahike-like use-cases but I'm not sure thats even a sane idea yet.

I like the signal graph and would like to keep its properties (i.e. recomputation only when necessary). Having fns that grab data from deep within the app-db run a bit counter to this

have tried posh, but found it a bit too much effort

quick question. re-frame's HTTP client expects :on-success and :on-failure to be defined as events. is there a way to no-op these in the case I want to do nothing with the response?

that is, a way that doesn't involve just making a :no-op event handler, which of course is trivial enough

Just don't specify the keys.

perhaps, but you get a console error then that annoys me re-frame: no :event handler registered for: :http-no-on-success

Ah, huh, yeah. Well, either your own :no-op with explicit keys or your own :http-no-on-success and :http-no-on-failure without the keys.

(doseq [id [:http-no-on-success :http-no-on-failure]]
  (rf/reg-event-ctx id (fn [ctx _] ctx)))