This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-12-13
Channels
- # admin-announcements (208)
- # beginners (53)
- # boot (46)
- # cider (10)
- # cljs-dev (26)
- # cljsjs (10)
- # clojure (66)
- # clojure-dev (3)
- # clojure-russia (14)
- # clojurecup (5)
- # clojurescript (302)
- # cursive (22)
- # data-science (1)
- # datomic (10)
- # emacs (1)
- # events (2)
- # hoplon (91)
- # incanter (1)
- # ldnclj (3)
- # leiningen (1)
- # off-topic (2)
- # om (41)
- # re-frame (40)
- # reagent (78)
What’s the best way to handle a subscription that depends on props? For example
(defn my-component [a-prop]
(let [sub (subscribe [:an-event a-prop])]
(fn []
[:div nil @sub] ; for example
)))
The subscription won’t change when props change, because it’s only created on initial creation of the component.
Does it make sense to do
(defn my-component [a-prop]
[:div nil @(subscribe [:an-event a-prop])])
But that would re-subscribe on every render, not sure that would do good things@roberto: something like (register-sub :an-event (fn [db [_ prop]] (reaction (get-in @db [:some :thing prop]))))
Your first code fragment is the right one.
If you are paranoid, you might write it like this:
(defn my-component [a-prop-orig]
(let [sub (subscribe [:an-event a-prop-orig])]
(fn [a-prop-render]
(assert (= a-prop-orig a-prop-render)) ;; <--- paranoid
[:div nil @sub] ; for example
)))
what I want is for the subscription to change when the prop changes. and that’s not what I experienced @mikethompson
Two ways of achieving that ...
1. You trash the component and recreate it. It will subscribe based on the new prop. And you are all good.
2. You can use dynamic subscriptions
Option 1 is achieved by putting a key on the component (which is the a-prop
value)
When that value changes, the key
will be different, leading to the old component being trashed and a new one being put in place
This is a fairly big hammer
Dynamic subscriptions are the second option which is designed for exactly this situation too ....
IF the parameter coming in .. a-prop
in you case, is a ratom ...
... ie a value which can change over time .... then .... you can pass it in the subscribe ...
... as the 3rd parameter
Sorry, no docs on this: https://github.com/Day8/re-frame/pull/108
feels a little weird to have a prop that’s a ratom though… but I guess in re-frame/reagent, the only way to have values changing over time is w/ ratoms
So
(defn my-component [a-prop-ratom]
(let [sub (subscribe [:an-event] [a-prop-ratom])]
(fn []
[:div nil @sub] ; for example
)))
Very normal and useful to have props which are ratoms
Remember with ratoms you are effectively building a signal graph
and the results of subscriptions are effectively ratoms (they behave as if they are ratoms)
well yes, but it seems like it could get confusing to have the signal graph entwined in the render tree. but I’ll get used to it
If you want to see it (passing in ratoms) in action, look at re-com
(Depending on your browser targets, you may not be able to use it, but it is likely to supply some inspiration)
This is my favorite demo: http://re-demo.s3-website-ap-southeast-2.amazonaws.com/#/h-box
(but you'll probably have to be comfortable with CSS flexbox to understand what's going on)
Isomorphic re-frame lives: https://carouselapps.com/2015/12/13/prerenderer-0-2-0-released/
is anyone aware of an example that uses rethinkdb as a backend to a re-frame app? i've read earlier on this channel that people have done it, but i can't find any code examples
@nickastete: we don’t really have any code to share at the moment
although RethinkDB is writing Fusion which is a way to connect directly from a browser to a RethinkDB server ala Firebase
So that will probably be where we end up
that's exciting
thanks for the update