I normally don't write stateless React components with children in Om, but am finding a need to. I notice that instance? does not work to figure out what type a child has. I can use the type property: (= (.-type child) ClassName) Is that the recommended approach?

or should I instead use the "name" property and compare strings?

perhaps react-type?

@tony.kay please clarify

what do you mean by “does not work to figure out what type a child has”?

(defui A ...) 
(def ui-a (om/factory A)

(instance? A (ui-a {})) => false

@tony.kay oh OK I know the problem you’re having

so at that point you don’t have a component instance, but a React element

ah. so is (= (.-type react-instance) react-class) the right thing to do?

a React element is just a JS object

or is adv opt going to bite me

you want .-type, sure

you definitely want .-type, but you may have to make an extern for it

OK. Hard to keep straight what is meant to be "implementation detail".

@tony.kay to be clear: it’ll work today, but if we start consuming React from node_modules it might be munged by Closure

Yeah, and type was added in React some-version-or-another, wasn't it?

that I cannot speak to

I think 0.12

doesn't matter. the advanced optimization will be something to keep an eye on though

thanks

happy to help!

It appears that a render function can get information from three places: * local sate * props * computed Now, I know what to put in local state -- basically any datta that is allowed to 'vanish' if the user closes the browser. What I don't get is props vs computed -- docs talk about computed being used for callbacks -- but where do I draw the line for: this goes in props vs this goes in computed` ?

========== If I need to (1) update local state via update-state! and (2) make a callback passed to me via (om/get-computed) Should I: (1) update-state! // make-callback OR (2) do the make-callback INSIDE the update-state! ?

in om/next, is there a way to pass an initial value for localstate ?

@qqq (initLocalState [this] {})

sorry, I meant "is there a way for the parent element to pass an initial value to a child element's local state" ?

I think what you have described is : is there a way to globally declare an localstate for a component

@qqq there is computed but I don't believe anything specific for local state

I thought about using computed -- but is it only passed once, or is it passed multiple times?

@qqq

(initLocalState [this]
  (let [{:keys [foo]} (om/props this)]
    {:foo foo}))

it seems like if the computed changes something, it may be possible that the computed gets passed a 2nd time and overwrites the original inititLocalState

can you guys load up http://dodv-demos.appspot.com ? I need some advice on this om component I'm building

@anmonteiro s approach is good : ) if you need local state from props

You see a little "window" with two slider bars right? (the sliders don't work in this particular release)

so locally, I have an example where the sliders work, and the sliders have all their state stored in localState

however, when the sliders move, I also need the content inside the "body" to scroll

to make that happen, should I be (1) using a om/computed + callback or (2) storing this in global state?

Full Question: 1) I have http://dodv-demos.appspot.com 2) the sliders are supposed to move up/down + left/right (but do not yet) 3) I have a local version where dragging works. 4) In local version, all state of sliders is localState 5) However, when sliers move, I need inner body to pan 6) To make this happen, should I be (1) attaching callbacks via om/computed to the sliders or (2) having the sliders om/transact! into some global state ?

anyone? is question too verbose or too unclear? 🙂