@pandeiro @mikethompson I use async-flow-fx to good effect. Nice to separate the higher "control flow" handlers from the http-call-and-put-in-the-database handlers which might be reused

I'm interested in this statement at the end of the readme: A motivated user might also produce a fully general FSM version of this effects handler.

is that a genuine proposition? would it be useful? how would it look

In this talk from ReactConf, the presenter talks about the automatic memoization of re-frame subscriptions and how this can lead to some unpredictability. Can anyone shed some light on what he means? https://youtu.be/-jwQ3sGoiXg?t=651

@ajs I'm not aware of any unpredictability with the signal graph.

ok, wonder what he was talking about. He's a developer for Khan Academy and the presentation is pretty interesting look at different state paradigms for interacting with React.

@ajs he doesn't mention how re-frame is different to Redux in terms of effects, which seems a significant miss also.

When using the debug interceptor, I'm seeing messages like Handling re-frame event: printed twice. Any idea why that might be?

AFICT the functions themselves are invoked only once

Is it a known issue that a :textarea with its :value attribute bound to some derefed subscription value effectively becomes read-only (`:on-change` events never fire, keyboard input is blocked)? If so, what's the best pattern for clearing a textarea, say after a submission (but where the form remains rendered)?

Anyone doing something like this: [bit off topic] - Client requests data - Server process the request, get the result, do a "signature" to result and send both to client - Next client request, the client says "yout last result has this signature", server process, with new result, check if it's equal to the the client sent, just response "ok", else send the new response and the new signature

If anyone is curious about my "duplicate logging" issue, it was an issue with the docs: https://github.com/Day8/re-frame/pull/379

So in the simplest repro I could come up with, having a [:textarea {:value @(subscribe [:some-thing]) :on-change #(dispatch [:other-thing (.-value (.-target %))])}] renders the textarea essentially read-only, because while the change events do fire, the value of the textarea is set back to the subscription value immediately and the new input is never shown. Is this the expected behavior?

@mikethompson after few days with the new re-frame we've converted most of our handlers (with their middlewares) to the reg-event-fx that return a map of effects. We've also created some custom effect (for analytics, api calls and the likes). One issue that came up was conditional side effects, for example conditional dispatching. We've written a custom effect for that called dispatch-n-cond which receives a map of events and booleans, and will dispatch only the events to which the boolean is true (similar idea to https://www.npmjs.com/package/react-classset for conditional css classes). Thus we're replacing code (conditional expressions) with data, but it feels a bit like we're making up effects DSL of sorts. How are you handling conditional side effects in your code?

@talgiat :dispatch-n seems to not mind having nil in the collection you provide it, I'm not sure this is officially supported but I just use when inline in the vector I provide to dispatch-n

actual example from my code

@mattly, wasn't aware of that, but seems to do the trick is well. Our custom effect is :dispatch-n-cond and will be uses like this:

{dispatch-n-cond {[:collections/set-local-storage] true
                               [:collections/add-item (:id data) (:guid add-item) (:type add-item)] (some? add-item)
                               [:modal/close] true}}

Historical note ... if I had my time over again I would have made effects be a paired vector ...

[:dispatch  [:one] 
 :dispatch  [:two] 
 :http      {:url .... }]

The additional benefit is that you get ordering of effects (not that this is a very big deal) But there are cons. Finding and updating the :db effect in an :after fn of an interceptor would have suddenly got a whole lot more complicated (is trivial ATM)

The challenges of being a DSL designer !!

@mikethompson I'm learning a bit of that myself while extracting something from my current work project into a library

there's quite the balance to be struck

that said, I think the map is easier to test, and I would have made :dispatch a vector of vectors

or a set

@mattly @talgiat You can now rely on nil events getting ignored https://github.com/Day8/re-frame/commit/6efdae438f393f8121a2d6dfbf76db00e6dafbf5

oh nice!

I must budget some time to upgrade to 0.9x soon

@pandeiro can you use on-blur, rather than on-change ?

@mikethompson Yeah, that is probably a good idea

I remember re-com does that by default, right?

re-com gives you the option

If you absolutely have to use on-change then I'd use dispatch-sync

Otherwise fast typing by the user can cause problems because there is a tiny async loop in there.

Even with dispatch-sync super fast typing can be a problem

Is there a way to inject the print debugging for all events without manually including the interceptor vector for each reg-event-db/`reg-event-fx`?