Get actual data by cursor? about om

[swannodette]

The only time you need this is if some reason the cursor is "stale". I think we need to think through preventing the likelihood of this case. What are you trying to do that made you need actualize?

[amakurin]

Ok. I have range-editor component, with slider and textboxes. Two handles of slider and two textboxes are subcomponents themself, and puts updates in common channel. Editor handles change events by handle-change function

(defn range-editor [range-value {:keys [min-bottom max-top] :as opts}]
  (let [config {:bottom (fn [v] (min (max min-bottom v) (:top (actualize range-value))))
                :top (fn [v] (max (min max-top v) (:bottom (actualize range-value))))}

        handle-change (fn[{:keys [bound value] :as e}]
                        (when (not(js/isNaN value))
                          (om/update! range-value [bound] (fn [_] ((bound config) value)))))]
  (reify
...

where i have updated bound and its new value. I found that after updating the cursor is always "stale", but in other cases i could solve this without actualize by restructuring my code.

[swannodette]

Ok this appears to be true because you are closing over the cursor for some reason? I suspected early on this might be an issue, I'm inclined to make update! error out if given a stale cursor because it's likely to be too large a source of confusion. Needs more thought.

[amakurin]

I'm using cursor this way:
first, on render of root component:

...
(om/build uire/range-editor app {:path [:monthly-cost-range] 
                                :opts {:min-bottom 0 :max-top 80000 :step 500 }})
...

then, on render of range-editor i'm giving whole range to subcomponents, cuz cant split it to leafs, which are numbers (subcomponents only reads cursor to render)

...
(om/build slider-handle range-value {:opts bottom-opts})
...

and the only place where i update! is in range-editor's handle-change (snippet in prev comment).
Am i doing not as designed?

[swannodette]

I still can't see why your design requires you to dereference cursors. It seems like the range-editor should be storing and accessing its bounds in local component state via om.core/set-state!, om.core/get-state which would allow you to avoid these issues.

[amakurin]

Yes.. i can do so and this allow to avoid troubles but i want changes of bounds to affect my app-state, cuz range editors are parts of more complex, let's say "filter". Filter has its actual state which i can use without composing it by controls-state... Of course i can duplicate range data in editor's state but... actualize seems to be pretty.
By the way updated actualize (may be helpful for somebody)

(defn actualize [cursor]
  (let [state (.-state cursor)
        path (.-path cursor)]
    (if (empty? path)
      @state
      (get-in @state path))))

Actually i do not meaningly dereference cursor. I thought dereferencing happens when range data updates on DRAG event of google.fx.Dragger, cuz it is out of React scope or something like that...

[swannodette]

I'm pretty convinced actualize is a bad idea and I will likely make update! throw on stale cursors.

[swannodette]

Ok after further consideration this actually supported now that I have a better feel for the semantics. You can only read from cursors from within a React render pass. Asynchronous operations like event handlers are no longer allowed to do any operations on cursors as they are outside of render, to read the latest value of a cursor you may use om.core/read in master.