This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-07-19
Channels
- # aleph (11)
- # aws (1)
- # beginners (14)
- # bitcoin (1)
- # boot (41)
- # cider (6)
- # cljs-dev (1)
- # cljsrn (13)
- # clojure (138)
- # clojure-italy (10)
- # clojure-nl (1)
- # clojure-poland (2)
- # clojure-russia (62)
- # clojure-sg (2)
- # clojure-spec (31)
- # clojure-uk (51)
- # clojurescript (109)
- # core-matrix (1)
- # core-typed (1)
- # cursive (63)
- # datomic (10)
- # emacs (9)
- # euroclojure (1)
- # hoplon (112)
- # immutant (16)
- # jobs (2)
- # lumo (5)
- # off-topic (14)
- # om (54)
- # onyx (17)
- # parinfer (23)
- # pedestal (2)
- # re-frame (41)
- # ring-swagger (23)
- # spacemacs (9)
- # specter (10)
- # uncomplicate (5)
- # vim (1)
@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)?
That sounds strange, it works for me. My guess is that re-frame isn't the culprit here.
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?
Argh, so no, not what should happen -- and I was observing that because of some processing of the input that was blocking new values from being dispatched.
@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
@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 .... }]
One of the annoying things about the current map
approach is that we have dispatch
and dispatch-n
. This problem (1 or N of effects) tends to play out for many effects.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
that said, I think the map is easier to test, and I would have made :dispatch
a vector of vectors
@mattly @talgiat You can now rely on nil
events getting ignored
https://github.com/Day8/re-frame/commit/6efdae438f393f8121a2d6dfbf76db00e6dafbf5
@pandeiro can you use on-blur
, rather than on-change
?
@mikethompson Yeah, that is probably a good idea
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