This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # beginners (102)
- # boot (23)
- # cljs-dev (1)
- # clojure (52)
- # clojure-canada (7)
- # clojure-korea (2)
- # clojure-poland (1)
- # clojure-russia (35)
- # clojure-spec (39)
- # clojure-uk (5)
- # clojurescript (64)
- # cursive (11)
- # events (1)
- # hoplon (168)
- # lein-figwheel (2)
- # luminus (14)
- # off-topic (47)
- # om (3)
- # om-next (1)
- # onyx (31)
- # quil (4)
- # re-frame (21)
- # spacemacs (1)
- # sql (1)
- # untangled (3)
- # yada (4)
@triss take a look at Carry, it's similar in philosophy to re-frame and supports Clojure: https://github.com/metametadata/carry Here's the simple Clojure example using the lib: https://github.com/metametadata/pickings
many thanks @metametadata I’ll take a look
@triss you're welcome, join #carry if you have any questions
where is reg-event-db, subsribe documented ? Is there a re-frame API reference somewhere, or is it just read doc strings of source /
edit: https://github.com/Day8/re-frame/tree/master/docs is what I wanted
https://github.com/Day8/re-frame/blob/master/docs/EffectfulHandlers.md <-- this entire page is basically "we wish we had haskell's type system to enforce purity"
@mikethompson: True, but all three examples (1) calling dispatch (2) making a GET request, and (3) reading from Local Storage would be things in Haskell which has type IO a -- all three errors are things that Haskell's type system would have caught // but I agree, there is no explicit mention of Type systems, and not all type systems would catch this -- certainly not Ocaml's, for example
To get the full picture, you should then read about coeffects.
That's section 3 or 4 -- I'm still on section 2 -- Interceptors (which are pretty clever themselves).
@mikethompson : the interceptor page just mentioned coeffects/effects. Are the following statements correct. Assume we have an event where: for input: we need "foo" from LOCAL STORAGE, and "bar" from GET-REQUEST after we're done: we need to make a POST request on "dogecoin" Then, in situation, the "foo" and "bar" would be encoded as COEFFECTS, and the "dogecoin" would be encoded as an "EFFECT" Basically Coeffect = impure things we need to do TO GET INPUT Effects = impure things we need to do to PUSH OUTPUT
Correct me if I'm wrong. Adding "undo" to reframe is as simple as "let's add an interceptor"
Yep, about that. and see https://github.com/Day8/re-frame-undo
does re-frame use "request animation frame"? the goal is minimize # of reflows by pushing all the DOM updates into a single "update cycle"
Is reagent running topolotical sort behind the scenes? When I do (def x (r/atom 0)) (def y1 (ra/reaction (+ @x 1))) (def y2 (ra/reaction (+ @x 2))) (def z (ra/reaction (println "z was fired") (+ @y1 @y2))) then when I update x, "z was fired" only appears once -- which makes me wonder -- if reagent doing clever top sort behind the scenes to minimize # of updates ?
@hwk To your 2nd question: Reagent does not do a topo sort of reactions. But ... it does run all reactions before rendering views (remember that running a render function is effectively running a reaction) AND it will render parent views before child views.
So there is "some ordering" (for efficiency) rather than strict ordering. For your example, if both
y were to change value, there is no guarantee that the
z computation would only happen once. It might happen twwce AND the first time might involve a stale version of
y. (At least, this used to be how things worked. Dan did some work in this area for the last release, so it might have changed subtly)
To your first question: re-frame is built on top of Reagent. So you should be asking the question "does Reagent use js/requestAnimationFrame". And the answer is yes
@mikethompson : thanks for your detailed responses! I understand all of it except one point: in the above example, when @x changes, both @y1 and @y2 changes -- so why does @z only fire once if there is no topological sort going on?
Oh, sorry, I didn't read that code closely enough. What i should have said ... For your example, if both
y2 were to change value, there is no guarantee that the
z computation would only happen once. It might happen twice AND the first time might involve a stale version of
y2. (At least, this used to be how things worked. Dan did some work in this area for the last release, so it might have changed subtly)
@mikethompson : This makes sense and answers all of my questions. Thanks explaining everything!