This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-07-11
Channels
- # arachne (5)
- # beginners (28)
- # boot (59)
- # cider (10)
- # cljs-dev (10)
- # cljsrn (10)
- # clojure (58)
- # clojure-brasil (2)
- # clojure-czech (9)
- # clojure-miami (1)
- # clojure-poland (2)
- # clojure-russia (12)
- # clojure-spec (16)
- # clojure-sweden (1)
- # clojure-taiwan (1)
- # clojure-uk (77)
- # clojurebridge (3)
- # clojurescript (108)
- # cursive (5)
- # datomic (25)
- # defnpodcast (2)
- # editors (1)
- # events (1)
- # funcool (24)
- # hoplon (37)
- # instaparse (1)
- # lein-figwheel (7)
- # leiningen (7)
- # luminus (3)
- # off-topic (9)
- # om (90)
- # onyx (88)
- # proton (3)
- # protorepl (9)
- # re-frame (30)
- # reagent (23)
- # rethinkdb (2)
- # untangled (33)
- # vim (1)
- # yada (6)
@naomarik: The Wiki page should be editable. Happy for you to add whatever clarification you see as necessary.
thanks @mikethompson, added my addition 🙂
just wondering -- is it common practice to go around editing github wiki pages without permission?
Don't edit this one: https://github.com/clojure/clojurescript/wiki/Quick-Start
> Dear Reader: Do not edit this page without first consulting an experienced member of the ClojureScript community.
@naod: I always appreciate the typos and oddities getting fixed on Wiki pages I also appreciate small additions, like yours, for sure. Perhaps if someone was going to make significant changes, I'd like a heads up. But generally, for me, the more brains on something the better.
That's kinda the reason for open source
Open source can be a thankless slog, so having others contribute is actually what you want
yup, I'm a newcomer to contributions so don't really know what unspoken etiquette there might be
@naomarik: I’d assume a wiki page is fair game for small fixes unless it explicitly calls out no editing. If people really don’t want others editing stuff they will put it in a docs/
folder on the repo
Looking at https://github.com/Day8/re-frame/wiki/A-Larger-App is useful but doesn't give me a ton of examples.
I’ll be releasing one shortly. Not that big (1.5KLOC including backend), but nontrivial
Also, Why use
(register-sub :foo (fn [db] (reaction (:foo @db)))
instead of
(defn foo [db] (reaction (:foo @db)))
?
[4:34]
then use (foo re-frame.db/app-db)
instead of (subscribe [:foo])
I'm glad these questions are getting asked now with v0.8.0 close: You want to use the new de-duplication feature? You want to want to use the new "pure function" version of subscriptions?
One thing I want to do is
(let [setup (do (dispatch-sync [:init-db])
(dispatch [:name "John"])
(dispatch [:login]))]
(is (= true @(subscribe [:logged-in?]))))
I read a bit of the code in this repo over the weekend and the event abstractions seem pretty nice. Maybe something to look at for re-frame's new effects stuff: https://github.com/uxbox/uxbox/blob/master/src/uxbox/util/rstore.cljs
When using re-frame, suppose one has a form with one or more hidden inputs that should have a default value, for a new user (or on initial render of the form). What would be a good approach for setting the default in the app db in such a case? Thanks for any suggestions...
@limist: I would usually just put in a dispatch
before the hiccup
this means it's sent every time the component re-renders but often this isn't an issue (esp. when inputs are hidden)
Alternatively you can make a Form-2 component that does the dispatch when mounted https://github.com/Day8/re-frame/wiki/Creating-Reagent-Components#form-2--a-function-returning-a-function