Is there a problem with the way I've been handling dynamic subscriptions?

(defn activity-editor
  []
  (let [id       (subscribe [:open :activity])
        activity (reaction @(subscribe [:activity @id]))]
  ...

I think you'd be better off doing this:

(defn activity-editor
  []
  (let [id       (subscribe [:open :activity])
        dyn-sub (reaction (subscribe [:activity @id]))
        activity (reaction @@dyn-sub)]
  ...

Otherwise, every time the subscription yields a new value, you'll trigger a re-computation which will re-create the subscription itself. Having said that, I find that this stuff messes with my head. I'd like there to be an easier way to use/think-about this stuff. Have it hidden. Robust. That's what https://github.com/Day8/re-frame/pull/108/files is about.

>trigger a re-computation which will re-create the subscription itself Ah I see, that makes sense. I'll have a go at using the new PR as well, cheers

When working with re-frame + figwheel I get warnings like: “re-frame: overwriting subscription-handler for: …”. Is this normal and can it be safely ignored?

Yes, it is normal and can be ignored. When figwheel reloads a namespace (after a recompile), the handlers in that namespace will be reregistered (overwritting their previous registration, when the file was loaded for the 1st time). re-frame sees that it already has a handler registered for the id and warns you (just in case you ever mistakenly registered two handlers with the same id) ... but in the figwheel case we're all good with the overwrites.

@mikethompson: That was my guess too, thanks for confirming!