Add unknown property warning for use of autofocus

[hkal]

Resolves #3248

This PR also:

• Resurrects property warnings when ReactDOMFeatureFlags.useCreateElement is on
• Adds property validity event to debug tool

I wrote some tests for this work, but didn't notice any other __DEV__ specific warnings being tested. I can include them with this PR if they're wanted.

[facebook-github-bot]

@hkal updated the pull request.

[hkal]

Went ahead and added the test-case after seeing some other tests for __DEV__ only code paths.

@jimfb - noticed you set the label on the original bug. Let me know if this adequately addresses the problem.

[facebook-github-bot]

@hkal updated the pull request.

[gaearon]

Hmm. I think the plan was to move these warnings to element creation: #6345
cc @jimfb

[jimfb]

@hkal Sorry for letting this one slip through the cracks. Can you rebase and move it to element creation like in #6345 and then I think this is ready to merge.

[hkal]

@jimfb - No worries.

Just so I'm clear, is the direction to consolidate onCreateMarkupForProperty, onSetValueForProperty, onDeleteValueForProperty and the event I added into a single event that is fired on element creation?

cc @gaearon

[gaearon]

I think so. Afaik this event already exists, check out #6800. You might want to tweak that code.

[hkal]

@gaearon You're right, looks like the event is already there. I removed the unnecessary code and updated the tests.

@jimfb Am I missing anything, or is this good?

[aweary]

getPossibleStandardName: __DEV__ ? {autofocus: 'autoFocus'} : null,

@hkal the values in getPossibleStandardName are injected in DOMProperty using HTMLDOMPropertyConfig.DOMAttributeNames. Could you move this into that object instead so it's injected like the other values are? I think this can be merged after that change, as far as I can see.

[aweary]

@hkal ping! Would you by chance have any free time soon to make this small change? I'd like to get this in soon. If not, no worries, I can get #7471 in 👍

[hkal]

@aweary my bad. Somehow I missed these notifications. Updated the pull request, let me know if anything else needs changing.

[aweary]

Thanks @hkal, looks good to me 👍

[zpao]

I'm actually going to revert this - it actually has more impact than just the warning and changes how autoFocus handling will behave. I can't demonstrate it in jsfiddle because frames and focus don't play nicely. But just take an example and render 2 inputs with autoFocus={true}. 15.x will consistently focus the 2nd. After this change the first will get focused (in Chrome) and we're otherwise subject to whatever the browser decides to do when nodes are updated or removed. That's not to say we should necessarily be handling this ourselves, but for the time being we shouldn't change it.

When we get to removing the whitelist we'll have to deal with that side of things. For now, if we want this to work, we need to handle this without adding the property to the whitelist as we don't want it to end up in the DOM.

[aweary]

Thanks for clarifying @zpao, I had tested that autoFocus still worked before merging but didn't notice the order may have been inconsistent.

[hkal]

Thanks for explaining the issue, @zpao. Didn't even think to test that case.

@aweary I'm pretty confident we can still get the warning without any unintentional side affects if we go back to pre-defining the autofocus property in getPossibleStandardName. Aside from attribute injection, the only call to it is for producing warnings.

[aweary]

edit: see #3248 for discussion