This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-03-26
Channels
- # admin-announcements (1)
- # beginners (1)
- # boot (252)
- # braveandtrue (1)
- # cider (17)
- # clojure (58)
- # clojure-chicago (3)
- # clojure-russia (125)
- # clojure-uk (2)
- # clojurescript (38)
- # hoplon (3)
- # lein-figwheel (11)
- # leiningen (1)
- # mount (2)
- # off-topic (3)
- # om (9)
- # onyx (39)
- # parinfer (24)
- # proton (7)
- # protorepl (7)
- # quil (4)
- # re-frame (16)
- # reagent (5)
- # ring-swagger (18)
- # yada (1)
Returning back to smooth scrolling and the Google Closure library. In case someone else does the same mistake as me, when I concluded I had got it working I hadn’t tested in Firefox. To scroll the document using something like what @martinklepsch suggested:
(defn scroll! [el start end time]
(.play (goog.fx.dom.Scroll. el (clj->js start) (clj->js end) time)))
, know that different browsers need a different element. E.g. (.-body js/document)
won’t cut it Firefox, but works fine in Chrome and Safari. Seems like the makers of the library knows about this difference, because they provide a function for getting the document scroll element. So (goog.dom/getDocumentScroll)
seems to be what you want.do people prefer using reframe or core.async with reagent, and why?
@adamkowalski: re-frame is awesome. It keeps all your program state in the one place (called app-db
in re-frame, though most code generally never have to access it directly). You use subscriptions to grab data from the app-db
(and subscriptions are written so that their value is cached until the underlying data is changed), and you use handlers to trigger changes to app-db
. You structure your program so that it does not access app-db
except via subscriptions and handlers. It’s a very clean design.
that sounds nice, it seems really similar to the transactor model inside of om next.
the idea of a reaction seems really interesting though