Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

When will-update is called, data is already equal to next-props #80

Closed
piranha opened this issue Jan 27, 2014 · 7 comments

Comments

Projects
None yet
2 participants
@piranha
Copy link

commented Jan 27, 2014

This code demonstrates it:

(ns willupdate.core
  (:require [om.core :as om :include-macros true]
            [om.dom :as dom :include-macros true]))

(enable-console-print!)

(def app-state (atom {:text "Hello world!"}))

(defn root [data owner]
  (reify

    om/IWillUpdate
    (will-update [this next-props next-state]
      (let [old-text (:text @data)
            new-text (:text next-props)]
        (js/console.log "==" (= @data next-props)) ;; -> true
        (js/console.log "old ->" old-text)
        (js/console.log "new ->" new-text)))

    om/IRender
    (render [this]
      (dom/div nil
               (dom/h1 nil (:text data))
               (dom/button #js {:onClick
                                (fn [e]
                                  (om/update! data
                                              #(assoc % :text (str (:text %) "1"))))}
                           "click me")))))

(om/root app-state root (. js/document (getElementById "app")))
@swannodette

This comment has been minimized.

Copy link
Member

commented Jan 27, 2014

Oh right, this isn't really a bug, but a quirk of the React model coupled to our use of functions instead of an OO approach. app must be the new props if you think about it. In order to get the "previous" props in will-update you need to use om.core/get-props.

@swannodette

This comment has been minimized.

Copy link
Member

commented Jan 27, 2014

I've amended the documentation wiki to reflect the quirk and the solution.

@piranha

This comment has been minimized.

Copy link
Author

commented Jan 27, 2014

Argh, I actually did om/get-props yesterday, but I've deref'ed it: @(om/get-props owner), and that gave me new data. I think disallowing dereference or returning same data on dereference would help here.

@swannodette

This comment has been minimized.

Copy link
Member

commented Jan 27, 2014

@piranha good catch, we'll disallow deref during the render phase.

@piranha

This comment has been minimized.

Copy link
Author

commented Jan 27, 2014

Was it during the render phase? Not sure if that's what you call 'render phase', it was in will-mount anyway.

@swannodette

This comment has been minimized.

Copy link
Member

commented Jan 27, 2014

@piranha anything that happens directly because of React is considered the render phase - everything outside, event handlers, core.async loops is not.

@ghost ghost assigned swannodette Jan 28, 2014

@swannodette

This comment has been minimized.

Copy link
Member

commented Jan 30, 2014

fixed in master, a2e1f25

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.