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
      )))

(defn my-component [a-prop]
    [:div nil @(subscribe [:an-event a-prop])])

how does your subscribe fn look like?

@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
      )))

@jaredly: ^^

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

good call

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

ok

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

cool

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

https://github.com/Day8/re-com

(Depending on your browser targets, you may not be able to use it, but it is likely to supply some inspiration)

yeah, looks cool

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)

wow that is super slick!

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