Strange optimization only in production mode

[AlexGalays]

The 0.14-rc1 version brings a few performance optimisations that unfortunately behave differently when React is compiled in development or production mode.

This is very confusing as code that works in one mode should still work in the other.

Development mode Fiddle
Logs

render Hello
render World
render Hello
render World

(That's the React 0.13.x behavior)

Production mode Fiddle
Logs only

render Hello
render World
render Hello

The "optimization" seems to trigger when a component reference didn't change.
This fiddle uses the production build but the child component is always a new instance and it works as expected :

Production mode with workaround

[sophiebits]

Yup, this is a bug. The prod mode behavior is correct.

In dev mode we don't bail out because the contexts differ (code) because of secret validateDOMNesting tracking we do. Hmmmmmmmm.

[jimfb]

I feel like we knew about this "issue" and it was well documented at the time that the diff was merged. We were using context for our own purposes and didn't have a good workaround at the time. We decided to not worry about it, since renders should be deterministic (and side-effect free) it should have no influence on the rendered output. It sucked that we had a different path in dev/prod, but that was life. I think this is going to be fixed when we stop using context for our own hidden purposes, right?

[jimfb]

The "bug" is that your render function is not side-effect free (it prints something).

[sophiebits]

@jimfb I didn't know about this issue. Did anyone make a comment to that effect on my diff? I don't see any notes on #3467.

[jimfb]

@spicyj #4344 (comment)

[sebmarkbage]

@AlexGalays How did this surface? I.e. how did you notice the change? Is there some kind of behavior change or is it just slower in development mode?

[AlexGalays]

@sebmarkbage

We took the shortcut of having a few key top level components manually pull their data from flux stores in their render methods. It's not pure thus not ideal but it was much more convenient than the alternatives (we use a flux wrapper and a route wrapper component, it's not straightforward at all to flow all props through both without convoluted cloneWithProps calls)

I'm willing to review the way we did things, but it's good that the behaviour is now consistent in both env.

A quick workaround for us would be to produce a new component instance every time the parent renders (like the third fiddle) but It feels like you could even optimize that in the future and it would break too ? (although I don't see how you would optimize that without making the pure render strategy the default one, seeing as how some people deeply mutate their props)

EDIT: I'm going to use cloneElement everywhere we do { this.props.children } inclusions.