This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-09-21
Channels
- # alda (1)
- # bangalore-clj (1)
- # beginners (7)
- # boot (88)
- # carry (2)
- # cider (8)
- # cljs-dev (60)
- # cljsjs (2)
- # cljsrn (45)
- # clojure (255)
- # clojure-belgium (5)
- # clojure-boston (1)
- # clojure-dusseldorf (3)
- # clojure-greece (49)
- # clojure-italy (10)
- # clojure-russia (30)
- # clojure-spec (78)
- # clojure-uk (11)
- # clojurebridge (1)
- # clojurescript (80)
- # cursive (14)
- # datomic (33)
- # defnpodcast (4)
- # devcards (2)
- # dirac (15)
- # editors (23)
- # emacs (5)
- # events (11)
- # funcool (1)
- # hoplon (1)
- # juxt (1)
- # luminus (2)
- # mount (7)
- # off-topic (15)
- # om (152)
- # om-next (2)
- # onyx (17)
- # parinfer (1)
- # proton (38)
- # re-frame (35)
- # reagent (110)
- # rum (3)
- # spacemacs (3)
- # specter (51)
- # test-check (2)
- # testing (5)
- # untangled (234)
I've read the updated re-frame docs some time ago but it kind of went over my head 🙂 As far as I understand the new effects stuff solves the problem of event replayability which was addressed in Carry from the get-go by splitting event handling into control/reconcile phases. So comparing the two solutions I like Carry's straightforward "functions-only" approach more than re-frame's new "declarative side-effects" - it's much easier to grasp and, dare I say, pragmatic. There are also interceptors added in re-frame instead of a middleware pattern. But again, I haven't bought how they are much better than "raw" higher-order functions. I surely miss over pros/cons and I haven't used re-frame in practice. I would like to hear other opinions on this matter.
re-frame has always felt a bit over-engineered to me to be honest. It's certainly a well-made library, but the approach that was taken has created quite a few challenges down the road, and in the end the thing we want to achieve is not THAT complicated. So you don't need a complicated solution to a simple'ish problem.