Suppose a parent renders <ChildComponent callback={(value)=>setState(value)} />
. Suppose the parent re-renders. The pointer values of the callback
prop will be different (ie. not triple-equals-equal) but the callback
prop's value is conceptually the same for all intents and purposes. This is a "new value" despite being the "same value". You run into the same problem when the parent creates an object <ChildComponent data={{foo: 'bar', bar: 'noise'}} />
(pointers differ, despite it being the "same" object from a value-type perspective).
You also run into the reverse problem due to mutability. Suppose I say:
var value = {foo: 'bar', bar: 'noise'};
ReactDOM.render(<ChildComponent data={value} />, ...);
value.bar = 'drinks';
ReactDOM.render(<ChildComponent data={value} />, ...);
As you can see, the props have clearly "changed" (ie. componentWillReceiveProps
should get called, so the ChildComponent can respond accordingly), but the values are triple-equals-equal.
In general, there is no way to solve this, except to always call componentWillReceiveProps
any time the values might have changed.
If javascript always used value types (like they do for integers; two renders of integers or strings are always "equal" if they are equal from a value-type definition) for all data types, than this problem would not exist. Also, mutation creates an issue, because the meaning of a value can change (when it is mutated) but is still triple-equals equal to the original prop. But because javascript uses reference equality and supports mutation, you can't rely on triple-equals to tell you if two things are conceptually the same.
Please see reactjs/react-future#40 (comment) and reactjs/react-future#40 (comment). For the purposes of this discussion, we should use the full/complete/existing lifecycle names; otherwise everyone picks their own names for their methods in their comments, and it becomes literally impossible to follow the discussion.
Overall, I think you're trying to squeeze too many changes into a single issue. For instance, the lifecycles take in props+state in case you want to compare your props to your state in order to determine something (as people clearly do in the issue facebook/react#3279). You're welcomed to continue to think about these things, but note that a lot of design went into these APIs, and there are several concerns that you've been overlooking in your proposals (like the value-type and mutability points, or the reasons that the lifecycles often take multiple parameters, etc - primarily because you don't know the history of these design decisions). Since we've completely covered the original point of this gist, I'm going to bow out of this discussion here, but feel free to continue the discussion here for the benefit of others. We'll continue to watch these threads and maybe jump in from time to time.