Fix issues introduced by createElement() warning #6880
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| } | ||
|
|
||
| if (isValidConfigRefOrKey(config, 'ref')) { |
There was a problem hiding this comment.
I think this may be slower (in prod mode). We should avoid passing around object keys as strings whenever possible because engines can't optimize it as well.
| @@ -165,7 +165,59 @@ describe('ReactElement', function() { | |||
| expect(element.type).toBe(ComponentClass); | |||
| expect(element.key).toBe('12'); | |||
| expect(element.ref).toBe('34'); | |||
| var expectation = {foo:'56'}; | |||
| var expectation = {foo: '56'}; | |||
| Object.freeze(expectation); | |||
There was a problem hiding this comment.
What are the freezes for? (I guess they were here already too…)
There was a problem hiding this comment.
I have no idea 😄 . They were there and spread like fire. I wouldn’t be surprised if the first freeze was added for a completely unrelated purpose. (Maybe from the pre-element times?)
We don’t want to have different behavior in development and production. Previously, we used to ignore getters on key/ref in dev, but we’d read them in prod. Now, we only ignore the getters that we *know* we created so the production logic doesn’t differ.
This fixes an incorrect way of checking introduced in 95373ce (it had no effect).
|
Can you inline all the |
|
@gaearon updated the pull request. |
|
For the changelog:
|
enlight
added a commit
to debugworkbench/hydragon
that referenced
this pull request
May 31, 2016
This version seems to produce some spurious warnings like these: > Element: `key` is not a prop. Trying to access it will result in > `undefined` being returned. If you need to access the same value > within the child component, you should pass it as a different prop. I'm pretty sure these warnings can be safely ignored and will go away in the next release (see facebook/react#6880).
zpao
pushed a commit
to zpao/react
that referenced
this pull request
Jun 8, 2016
Fix issues introduced by createElement() warning (cherry picked from commit 2d74280)
zpao
pushed a commit
that referenced
this pull request
Jun 14, 2016
Fix issues introduced by createElement() warning (cherry picked from commit 2d74280)
1 task
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This builds on top of #6268.
I fixed a few style nits and indirection in it, and later I realized it introduces a bug in
cloneElement(). As I was tracing this bug, I found that it already existed increateElement()in 15.x (#6879).So I fixed the bug for both cases, added more tests, and shuffled them around to sit in the corresponding files.
reforkeythat areundefinedin development (@gaearon in Fix issues introduced by createElement() warning #6880)cloneElement(@ericmatthys in Do not clone key and ref getter props #6268)