Fork me on GitHub
#re-frame
<
2016-12-31
>
mikethompson00:12:17

@kishanov oh, that's very nice!!

pesterhazy08:12:38

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

pesterhazy08:12:07

there's also no issue in reagent's github

joshkh11:12:05

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])}))
The component needs to subscribe to app-db using its DOM node as an argument to react to changes. But the DOM node doesn't exist until it's rendered. I think I have a chicken-and-egg problem?

joshkh11:12:29

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.

joshkh11:12:31

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

joshkh11:12:19

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

pesterhazy12:12:07

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

joshkh12:12:07

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

pesterhazy12:12:40

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

pesterhazy12:12:01

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

joshkh12:12:03

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

pesterhazy12:12:33

you can store stuff like that in local atoms