@mikethompson your writing on the effectful handlers came to my mind while reading about https://github.com/yoshuawuyts/choo

kind of still wishing that the app-db would be easily parametrizable

i.e. no globals

in practice it hasn't been a problem outside of devcards / testing concerns

@javazquez @mccraigmccraig I just discovered that I need debouncing too in the project I'm working on. How are you doing it?

@macroz: It would be easily enough to eliminate globals and turn re-frame from a framework into a library. Yah!!! But I've just never had the need. I';m aware that it is an issue with devcards, but I've never used them, so I admit to being a bit lazy in this regard. Other things have seemed more interesting (I'm very excited about v0.8.0).

yeah I totally understand

only recently got interested in the devcards style development style

I find it so productive creating new components in a separate page where I can just install the component in every state imaginable and see that it looks correct

only can't make it interact because of the global limitation

don't want to go to iframes yet 🙂

I use similar style in React app, call it the component guide (vs. style guide vs. devcards)

I will get there. But it will be v0.9.0

thanks for all the hard work anyway 🙂

found your article about the effects and choo interesting because I have a bunch of websocket stuff

Well all the cool kids are into BOTH effects and coeffects these days.

So naturally, I'll be adjusting my doc very shortly to talk about both 🙂

@nilrecurring: @mccraigmccraig I am looking at this example as a starting point https://gist.github.com/scttnlsn/9744501

@javazquez: on a previous project (which used core.async) i used this implementation (with macros & cljs) https://www.refheap.com/9185570a58a7cdcb31a7851a7 https://www.refheap.com/0ba212261580d881fa5ccf100

the crux of it is in the cljs (second) paste - if an operation is already in progress it effectively drops it, and only ever returns a result from the last invocation of the operation - prior invocations return the nil of a closed channel

I don't quite understand how this line of code works.. https://github.com/Day8/re-frame/blob/master/examples/todomvc/src/todomvc/views.cljs#L83 :on-save #(dispatch [:add-todo %])}]] how is an argument being passed for "%"?

I think the # in front of dispatch is equivalent to

(fn [e] (dispatch [:add-todo e]))

@javazquez, @dfcarpenter: correct. #(..) is for anonymous function literal. more here: http://clojure.org/reference/reader#_dispatch

@rohit: @dfcarpenter understood... but how is the parameter passed? The handler gets a "text" passed.. https://github.com/Day8/re-frame/blob/master/examples/todomvc/src/todomvc/handlers.cljs#L75

@javazquez: that responsibility is in todo-input.

https://github.com/Day8/re-frame/blob/master/examples/todomvc/src/todomvc/views.cljs#L11

@javazquez: It’s because that is the name you are giving the value of the input. When you enter text into the input field and press enter it’s sending a text value. This text value is dispatched to the handler and you are naming the argument “text” merely for convenience to remind you what it is.

thanks, that makes sense... this seems to contradict my previous question of using an atom https://clojurians.slack.com/archives/re-frame/p1467582951001031

I am ok with the approach.. just want to make sure I am doing it in the way the frame work meant me to 🙂

All re-frame is providing you with is a central data store and the transport mechanisms to get data into it.