This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-09-27
Channels
- # beginners (54)
- # bitcoin (2)
- # boot (1)
- # calva (10)
- # cider (30)
- # cljs-dev (25)
- # cljsrn (17)
- # clojure (27)
- # clojure-dev (16)
- # clojure-estonia (3)
- # clojure-hk (1)
- # clojure-italy (8)
- # clojure-losangeles (1)
- # clojure-nl (17)
- # clojure-russia (1)
- # clojure-spec (15)
- # clojure-uk (45)
- # clojurebridge (1)
- # clojurescript (95)
- # clojurescript-ios (1)
- # core-async (5)
- # cursive (10)
- # datomic (8)
- # emacs (2)
- # figwheel-main (31)
- # fulcro (99)
- # hyperfiddle (3)
- # immutant (1)
- # jobs (13)
- # jobs-discuss (82)
- # keechma (6)
- # leiningen (3)
- # lumo (1)
- # nrepl (1)
- # off-topic (37)
- # onyx (1)
- # pedestal (6)
- # re-frame (7)
- # reitit (2)
- # remote-jobs (1)
- # ring-swagger (3)
- # rum (6)
- # shadow-cljs (14)
- # specter (4)
- # tools-deps (27)
- # yada (12)
@urbanslug hmm, I don't really understand the question.
Hi. I have 2 events which are each causing 1 separate change in the re-frame db. I would like to find a way to avoid the view from rendering between those 2 db changes so that each time the view is re-rendered it never sees inconsistencies. What would be the best way to do that?
@vincent.cantin if you know there will always be two events could you queue the changes from the 1st event and process them in the 2nd event with the changes from the 2nd event?
That’s what I am currently doing, but I wanted to know if there were other solutions.
Does dispatch-sync
cause subscription reaction immediately or it will happen asynchronously on the next rendering cycle?
I have single handler for it that updates any field on any form (https://github.com/imatic/re-frame-form/blob/e4f2ca430dc83e3e9d78402c4dddee3a8ddb9480/examples/re-frame-form/src/example/core.cljs#L63)