Fork me on GitHub
#re-frame
<
2016-07-28
>
superstructor04:07:50

any ideas on the timeframe for 0.8.0 release ?

danielcompton04:07:26

trying to get it out as soon as possible

superstructor04:07:06

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 ?

mikethompson05:07:00

@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.

mikethompson05:07:15

Wait for a couple of days, and I'll give an update

superstructor05:07:19

@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.

superstructor05:07:33

So I’ll go push the big red upgrade button…

mikethompson05:07:09

@superstructor: you can use the :dispatch-n effect

superstructor05:07:06

@mikethompson: thanks didn’t notice that, nice!

mikethompson05:07:28

I was going to drop a link in here, but github seems to be having a bad moment

superstructor05:07:48

yep found it, its line 80 of fx.cljc

mikethompson05:07:24

@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 contextyou 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.

nilrecurring08:07:05

@mikethompson: why the interceptor version would be better?

mikethompson08:07:44

The current process is to work that out 🙂

mikethompson08:07:09

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.

mikethompson08:07:41

It is kinda "middleware as data"

mikethompson08:07:26

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 🙂

escherize08:07:05

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?

mikethompson09:07:18

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.

superstructor11:07:03

@mikethompson: thanks for explaining the potential changes :thumbsup: Look forward to understanding more about interceptors when/if that is ready.

martinklepsch13:07:51

I'm looking forward to @mikethompson's Readme section on interceptors 😄

mikethompson14:07:56

===================== CHANNEL QUESTION ===================== How many people write their own middleware ??

shaun-mahood14:07:34

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?

jmayaalv15:07:17

so far no need to write any middleware of my own

mccraigmccraig15:07:24

@mikethompson: i wrote some schema-checking middleware when i started my project and have barely touched it since

richiardiandrea15:07:32

Schema middleware here only as well

martinklepsch15:07:22

I have custom logging middleware

nilrecurring15:07:51

@mikethompson: I only ever used middleware for the local storage, to cache stuff. Readapted from the todomvc example

kanwei18:07:21

no middleware.

jakemcc20:07:15

I haven’t written re-frame middleware.

superstructor21:07:17

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?).