input autoFocus causes focus to be emitted before ref

[syranide]

https://jsfiddle.net/nnwd2c34/

Can reproduce on Chrome, but not in IE11.

[LeZuse]

Also came here to report this. Prevents a very usual usecase for focus/select:

<input
  autoFocus
  type="text"
  ref="valueInput"
  onFocus={this.onFocus}
/>

// this.onFocus:
this.refs.valueInput.select();
      ^ refs are not available yet

Using a workaround now:

// this.onFocus:
ReactDOM.findDOMNode(this).children[0]

[syranide]

@LeZuse You can just use event.target as a simpler workaround FYI.

[LeZuse]

@syranide ha, true! Thanks!

[gaearon]

Still happens on 16.

[oliviertassinari]

@syranide The event.target workaround works great. For everybody else, you might need event.currentTarget, be aware of the difference, and pick the one that fit your needs.

[gaearon]

Not sure what the right fix would be. Tagging as good first issue for somebody to investigate.

[RichieAHB]

The issue here seems to be that Ref effects are called after Update effects below (the latter being the effect to do the mounting). Although, if this is the issue, I'm not sure why it would work in IE11 🤔 ...

react/packages/react-reconciler/src/ReactFiberScheduler.js

Lines 312 to 342 in 13c5e2b

	function commitAllLifeCycles() {
	while (nextEffect !== null) {
	const effectTag = nextEffect.effectTag;
	if (effectTag & (Update | Callback)) {
	recordEffect();
	const current = nextEffect.alternate;
	commitLifeCycles(current, nextEffect);
	}
	if (effectTag & Ref) {
	recordEffect();
	commitAttachRef(nextEffect);
	}
	if (effectTag & Err) {
	recordEffect();
	commitErrorHandling(nextEffect);
	}
	const next = nextEffect.nextEffect;
	// Ensure that we clean these up so that we don't accidentally keep them.
	// I'm not actually sure this matters because we can't reset firstEffect
	// and lastEffect since they're on every node, not just the effectful
	// ones. So we have to clean everything as we reuse nodes anyway.
	nextEffect.nextEffect = null;
	// Ensure that we reset the effectTag here so that we can rely on effect
	// tags to reason about the current life-cycle.
	nextEffect = next;
	}
	}

I'm assuming this is to ensure that all refs are guaranteed to be mounted, which seems to make sense. On the off-chance that this isn't a guarantee that React provides then we could just flip the order of effects processing (although this breaks two tests around refs being called at the correct time, suggesting this is a hard constraint). Otherwise, it seems autofocussing would need to be broken away from the mounting process to solve this issue, which seems like an odd thing to do for other reasons.

Edit:
To be clear: the update gets marked here if finalizeInitialChildren returns true (which it does only if the host component needs an autofocus).

react/packages/react-reconciler/src/ReactFiberCompleteWork.js

Lines 505 to 518 in 8d336aa

	// Certain renderers require commit-time effects for initial mount.
	// (eg DOM renderer supports auto-focus for certain elements).
	// Make sure such renderers get scheduled for later work.
	if (
	finalizeInitialChildren(
	instance,
	type,
	newProps,
	rootContainerInstance,
	currentHostContext,
	)
	) {
	markUpdate(workInProgress);
	}

That then gets fired on commitMount in the reconciler, which again, makes sense.