5

I'm trying to implement the should-component-update lifecycle function in order to avoid some unnecessary rendering. My current implementation looks like this:

(def my-component
  (with-meta
    (fn 
      [props]
      (fn-body-here-with-some-reactive-deref'ing-going-on))

    {:should-component-update 
     (fn [this old-argv new-argv]
       false)}))

The component always updates even though I return false from should-component-update. The function doesn't even seem to be called as adding some debugging (.log js/console ...) statements doesn't produce any messages in console. What am I missing here?

kliron
  • 4,383
  • 4
  • 31
  • 47
  • 1
    From the [docs](https://facebook.github.io/react/docs/component-specs.html): "Invoked before rendering when new props or state are being received. This method is not called for the initial render or when forceUpdate is used." Is the component receiving new props|state? – pdoherty926 Nov 25 '14 at 18:44
  • 1
    It is receiving new props, I don't think that's the problem though. Isn't the whole point of shouldComponentUpdate to do a cheaper-than-re-rendering comparison between old-props and new-props and make a decision whether to update or not? I think the reactive derefing in the function body is to blame but I'm not sure. – kliron Nov 25 '14 at 19:27
  • Is `:should-component-update` triggered if you replace the "reactive derefing" with a function that returns a simple value? – pdoherty926 Nov 26 '14 at 17:38
  • Yes. I also found this googling: http://logs.lazybot.org/irc.freenode.net/%23clojurescript/2014-10-31.txt (Interesting at [13:45:20]) – kliron Nov 26 '14 at 19:23
  • Unless you have a serious(!) performance problem, you should never override this function to just _not_ render. React is very performant and smart of what it's re-rendering so it's only in rare occasions that you have to use `shouldComponentUpdate`. _If_ there is a performance problem your component's properly doing too much anyway. – Hulvej May 24 '15 at 17:17

0 Answers0