@kishanov oh, that's very nice!!

@pesterhazy was it this? http://stackoverflow.com/questions/33299746/why-are-multi-methods-not-working-as-functions-for-reagent-re-frame

@mikethompson, exactly

although I still don't understand what makes a multimethod different from a regular fn doing (case key :a ... :b ...) in this scenario

there's also no issue in reagent's github

Happy holidays everyone! I have a question about (maybe dynamic?) subscriptions in Form 3 components. I have a react component that stores its DOM element in app-db:

(defn scaled []
  (create-class
    {:component-did-mount    (fn [e] (dispatch [:cr.events/register-element (js/$ (dom-node e))]))
     :component-will-unmount (fn [e] (dispatch [:cr.events/deregister-element (js/$ (dom-node e))]))
     :reagent-render         (fn [content]
                               [:div.cr-content content])}))

To shed some light on why, the window has a listener on resize that fires an event to calculate the width and height of the parent node of all registered elements which I then want to pass back to the components.

I can't see any way of getting (subscribe [:parent-dimensions (js/$ (dom-node e))]) outside of the create-class form

(And accessing the dom-node inside the render function throws an exception (dom-node (reagent/current-component)): Warning: reagent25 is accessing findDOMNode inside its render(). render() should be a pure function of props and state. It should never access something that requires stale data from the previous render, such as refs. Move this logic to componentDidMount and componentDidUpdate instead. )

IMO it would be better to find a way that doesn't require storing dom elements in app-db

you're probably right. the other option is to give each component an ID, but i was hoping to make this "just work" in the sense that wrapping any reagent component in the scaled component wouldn't require effort

think of it this way: app-db (and events) should ideally be serializable, so you can save/restore a snapshot or history

my rule of thumb is to store only things in global state that can be pr-str'd

that's definitely good advice and i'll refactor. the parent dimensions of elements aren't really ever relevant except for "right now" and so i thought i could spare some jquery lookups by storing them in transient part of app-db. but maybe i'm just complicating things. 😉 thanks for the advice

you can store stuff like that in local atoms