2

I am trying to grasp the purpose of the two OM functions get-state and get-props. Have a look at the following example: 

(defn example [app owner]
  (reify
    om/IInitState
    (render-state [this state]
      (println "app-state: " app )
      (println "state: " state )
      (println "get-props: " (om/get-props owner) )
      (println "get-state: " (om/get-state owner) )
      (dom/div nil "hello"))))

You will notice that app and state contain exactly what get-props and get-state return, which seems at the first glance pretty redundant.

Now, not all the lifecycle functions (e.g. IWillMount ) pass the state argument, so when you need it in such circumstances, it's obvious that you need to invoke om/get-state to get access to it.

However, for the app-state it looks different to me. You always have the app-state cursor available in all functions since it's a top-level argument of the function, even if you need it in callbacks you can just pass it around. Most examples/tutorials make use of get-state but I can't find an example of get-props. Is get-props redundant? Where would I use it?

And one more thing related to this construct. In React we have props and state, but in OM we have app-state and state (internal state) which confused me when learning OM. Props are passed from parent to child in React, likewise in OM we pass app-state (cursors) to children. Are the following observations valid?

  • app-state is the OM equivalent of React' props
  • props is React is just data, while app-state in OM is data wrapped in cursors
  • this means that OM doesn't have props, only app-state cursors, hence the function get-props really means get-app-state
shaft
  • 2,147
  • 2
  • 22
  • 38
  • It sounds like you are missing the distinction between app-state and component state. get-props is about app-state (ie. props in React), while get-state is about component state. And figuring out what should be app-state and what should be component state is not necessarily simple. – skillet-thief Aug 15 '14 at 13:15
  • 1
    I don't think I miss this distinction, as you see in the question I distinguish between app-state (props equivalent) and "internal state" (local component state) . What is not clear is the function get-props. Why is there when I have the cursor anyway? And since there are no props in OM, I find this name confusing. Can't find an example that shows how to utilize this fn. But you're right, figuring out what goes into app-state/local-state is very tricky. – shaft Aug 15 '14 at 13:59
  • I totally agree with you. I am going from regular React to Om and this app-state vs props distinction is super confusing. I too don't understand why get-props exists. – lk135 Jan 09 '15 at 23:02

1 Answers1

2

According to the docs, get-props is mostly (or exclusively) needed in the IWillReceiveProps phase. will-receive-props gets a next-props argument, which contains the future app-state/props. get-props gives you the current app-state/props so that you can compare the two.

From the Om docs for IWillReceiveProps:

In your implementation if you wish to detect prop transitions you must use om.core/get-props to get the previous props. This is because your component constructor function is called with the updated props.

So the rest of the time, get-props isn't necessary because, as mentioned in the question, you have access to the cursor.

skillet-thief
  • 549
  • 4
  • 8
  • it could still be useful in helper functions. For example, I often pass `owner` to helper functions so I can access local state, so using `get-props` could save on arguments since you can access app-state through `owner`. Certainly not necessary, but could be useful, I guess. –  Aug 16 '14 at 17:34
  • So `will-receive-props` passes the `next-props` to your function which is redundant since the component constructor also has the updated props. In that case `get-props` is the only way to get the old props. Thanks, this makes a lot of sense. – shaft Aug 18 '14 at 06:38