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-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-failure without the keys.
(doseq [id [:http-no-on-success :http-no-on-failure]] (rf/reg-event-ctx id (fn [ctx _] ctx)))