Fork me on GitHub
#om
<
2017-02-27
>
tony.kay17:02:29

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?

tony.kay17:02:10

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

tony.kay17:02:36

perhaps react-type?

anmonteiro18:02:03

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

tony.kay18:02:42

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

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

anmonteiro18:02:12

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

anmonteiro18:02:25

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

tony.kay18:02:47

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

anmonteiro18:02:48

a React element is just a JS object

tony.kay18:02:06

or is adv opt going to bite me

anmonteiro18:02:49

you want .-type, sure

anmonteiro18:02:56

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

tony.kay18:02:17

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

anmonteiro18:02:27

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

tony.kay18:02:16

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

anmonteiro18:02:24

that I cannot speak to

tony.kay18:02:34

I think 0.12

tony.kay18:02:19

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

anmonteiro18:02:05

happy to help!

qqq20:02:24

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` ?

qqq20:02:29

========== 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! ?

qqq21:02:19

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

raspasov21:02:21

@qqq (initLocalState [this] {})

qqq21:02:53

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

qqq21:02:09

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

raspasov21:02:40

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

qqq21:02:00

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

anmonteiro21:02:02

@qqq

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

qqq21:02:14

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

qqq21:02:22

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

raspasov21:02:29

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

qqq21:02:44

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

qqq21:02:02

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

qqq21:02:15

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

qqq21:02:32

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

qqq21:02:45

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 ?

qqq21:02:32

anyone? is question too verbose or too unclear? 🙂