This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (6)
- # beginners (147)
- # boot (9)
- # braveandtrue (5)
- # cider (11)
- # cljsjs (1)
- # cljsrn (4)
- # clojure (82)
- # clojure-greece (9)
- # clojure-poland (9)
- # clojure-russia (288)
- # clojure-taiwan (2)
- # clojure-uk (73)
- # clojurescript (123)
- # consulting (3)
- # cursive (26)
- # datascript (4)
- # datomic (32)
- # dirac (56)
- # emacs (11)
- # flambo (2)
- # hoplon (425)
- # jobs-rus (1)
- # lein-figwheel (3)
- # leiningen (16)
- # luminus (42)
- # mount (7)
- # om (1)
- # om-next (2)
- # onyx (8)
- # other-languages (146)
- # quil (3)
- # re-frame (17)
- # reagent (6)
- # spacemacs (2)
- # uncomplicate (8)
- # untangled (71)
- # vim (2)
- # yada (49)
Using the lein re-frame-template with Secretary (`+routes`) for the first time. Trying to figure out what this whole client-side routing thing is all about. First question: I'd like to avoid having the "#" in my URL, so I commented out the
; (secretary/set-config! :prefix "#"). But what should I change the link to
"#/about" to to use my non-# URL? If I click on a URL to just
/about/, I get a error, not found. And my attempts to trigger a navigation event through
(secretary/dispatch! "about") don't do anything. Am I on the right track or have I gone helplessly astray somewhere already?
@deas: use middleware which checks the schema of the
You pretty quickly find out when an event handler is wrong in some way.
@mikethompson: have you or anyone else ever run into a case where schema checks were a bottleneck or performance burden? I know they're really good for me, like, kale-grade good for me, but…
schema checks are runtime checks, so you take a performance hit. I normally only enable them in tests.
@fasiha: schema checks kill my app performance, so i only use them in development
does reframe handle lazy sequences without issue, or am I doing something wrong, or should I always realize a lazy when dealing with reactions?
(let [thing (reaction (:thing @db) [filters (reaction (@db :filters)] (reaction (filter-with-filters @filters @thing)))
(filter …)(which is lazy).
if I have a view subscribing to that reaction, is it going to trigger on change if the result is lazy?
@lwhorton: the way I understand it (as @hugobessaa was explaining to me the other day), if
filters will rerun their reactions. Then,
filter-with-filters gets rerun. Any view that depends on this subscription will get rerun. So one way I'd look at the question is, it doesn't matter so much that the
filters lazy list changed, but that
db changed first.
From another perspective, supposing your ratom was a lazy seq, how would reagent know that it changed? It'd have to do
(= old-lazy-seq current-lazy-seq) at some level, which performs a deep compare, which iterates over all elements of the lazy seq. (At least, that's what I derive from observing that comparing infinite lists appears to infinite loop:
(= (repeat 1) (repeat 1)) ; doesn't end.)
So based on both those perspective, I'd tentatively say the answer to your question is, yes, the view will rerun if its subscribed lazy seq changes.