This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-07-28
Channels
- # admin-announcements (4)
- # beginners (11)
- # boot (148)
- # cider (74)
- # cljs-dev (31)
- # cljsrn (30)
- # clojure (55)
- # clojure-berlin (15)
- # clojure-greece (1)
- # clojure-japan (18)
- # clojure-poland (35)
- # clojure-russia (72)
- # clojure-spec (35)
- # clojure-uk (34)
- # clojurescript (134)
- # cursive (26)
- # datomic (42)
- # dirac (7)
- # editors-rus (1)
- # emacs (17)
- # hoplon (29)
- # jobs-rus (3)
- # juxt (1)
- # luminus (11)
- # off-topic (9)
- # om (66)
- # onyx (49)
- # pedestal (1)
- # perun (19)
- # proton (13)
- # protorepl (5)
- # re-frame (31)
- # reagent (13)
- # ring (2)
- # spacemacs (1)
- # specter (40)
- # spirituality-ethics (2)
- # test-check (41)
- # untangled (7)
- # yada (17)
any ideas on the timeframe for 0.8.0 release ?
trying to get it out as soon as possible
do you think its reasonable to upgrade a dev only (not production for some more months) project to 0.8.0-alpha4
in the anticipation that the final release is going to be pretty much the same with fx handlers etc ?
@superstructor: there's still one more potentially disruptive thing I might want to do for v0.8.0 ... I'm just dwelling on it now. If I decide against doing it, then 0.8.0 is almost ready for an immediate RC. BUT ... I'm thinking the disruptive change (to middleware) is a 70% of happening, and that might put an RC off for a week. All a bit handwaving, I know. But that's as much as I know.
Wait for a couple of days, and I'll give an update
@mikethompson: thanks, much appreciated. Sounds good and I think I’m happy to accept a disruptive change to middleware. I just want fx handlers! 😉 Also we often (dispatch …)
more than once inside of event handlers so want to work out how that will work when you can only return 1 dispatch from a handler.
So I’ll go push the big red upgrade button…
@superstructor: you can use the :dispatch-n
effect
@mikethompson: thanks didn’t notice that, nice!
I was going to drop a link in here, but github seems to be having a bad moment
yep found it, its line 80 of fx.cljc
@superstructor: so a more specific heads up: the final change I'm considering is a change from using "middleware" to using "interceptors". Interceptors are an alternative way of doing middleware. There will be implications for event handlers producing effects. At the moment (alpha5), you would write:
(def-event-fx
:my-id
(fn [{:keys [db] :as world} event]
{:db (assoc db :flag true)
:dispatch [:do :other]}))
The interceptor version might be
(def-event-fx
:my-id
(fn [context ] ;; event comes through as (:event context)
(-> context ;; must return the supplied conext, modified
(assoc-in [:db :flag] true)
(assoc :dispatch [:do :other])))
In effect, if we go with interceptors, then the context
you are given must be returned (assumedly modified). And event is no longer the 2nd parameter but is supplied within context.
Whereas, the current alpha5 version means you can return an entirely new map.
Apart from that point, virtually the same.@mikethompson: why the interceptor version would be better?
The current process is to work that out 🙂
It is more that i have recently come to understand the interceptor pattern. It is obviously used in Pedestal, but I've just never seen it explained. It has always seemed a bit mysterious and off putting. But the other night at cljsyd, we had a speaker who made it really clear in about 10 mins flat. It is quite simple and very flexible.
It is kinda "middleware as data"
Given Effectful Handlers are implemented via middleware, it seemed a good moment to pause and dwell on how we currently do middleware. (I believe any changes could be made backwards compatible). Still a reasonable chance that after this dwelling, there'll be no change 🙂
I think a better example would be useful - those two examples do the same thing. Another question: How is modifying a context more data driven than returning declarative data?
Indeed, the two examples do the same thing, but in a different way. I wasn't trying to explain anything other than what potential change might happen to handlers if there was a move to interceptors. No attempt to justify interceptors.
@mikethompson: thanks for explaining the potential changes :thumbsup: Look forward to understanding more about interceptors when/if that is ready.
I'm looking forward to @mikethompson's Readme section on interceptors 😄
===================== CHANNEL QUESTION ===================== How many people write their own middleware ??
The only middleware I've ever had to write for re-frame has been for CORS stuff, and that's just been adapting other people's work. So... maybe once?
@mikethompson: i wrote some schema-checking middleware when i started my project and have barely touched it since
Schema middleware here only as well
I have custom logging middleware
@mikethompson: I only ever used middleware for the local storage, to cache stuff. Readapted from the todomvc example
custom logging, log-ex (which is not provided by default, but is on the wiki), parameter validation or sanitisation (although I don’t know if that is a valid use case?).