Make autofocus show up in rendered markup

[zpao]

We currently don't because we handle this specially during runtime, but for server-rendered content it would be good to make this actually work.

cc @syranide

[syranide]

@zpao I never really liked the way it turned out.

It does focus once mounted, so it's decent the way it is now at least... but it also does so if you've already manually focused elsewhere, which is not very nice at all. This is kind of tricky, should we just ignore browsers that doesn't support autofocus? We could make something smart that doesn't focus if focus has already been set, but that's not 100% either. So perhaps it just shouldn't do it when reusing?

As far as autofocus is supported, it behaves as you would expect at page load in all browsers, which is good. So yeah, it makes sense to add it to the markup when server-rendering. But we currently can't add it to the markup selectively, we must remove it from the markup when reusing and it must not be rendered to the markup when client-side.

So it seems to me that to solve this, we need something like #1979 I think? Make server- and client-rendering detectable and reusing should incur an additional render where it transitions from server- to client-state (allowing properties to be removed, etc). And this is something that seems to be creeping up more and more elsewhere, having to be able to tell server- and client-rendering apart and being able to generate different markup for the two.

[jimfb]

it must not be rendered to the markup when client-side.

What is the issue with using autofocus when rendering client side?

[syranide]

@JSFB "We" decided not to use it because every browser has their unique interpretation of how it should work, literally all browsers do it differently. Overloading it and rendering it to the markup at the same time seems like a bad idea.

[jimfb]

Ok, we're probably going to get rid of the tag whitelist eventually anyway, so we would be sending autofocus to the DOM. If the behavior of autofocus is browser-dependent, user beware. Maybe we can do something to clean up the behavior and make it more consistent, but it's not entirely clear we should (though if it can be done easily/well, it seems reasonable). Either way, I think the assumption that autofocus can't be used client-side shouldn't be taken as a given/assumption going forward. The correct behavior, as I see it, would be to make autofocus work as consistently as possible in both environments (ie. it should be isomorphic).

[syranide]

Maybe we can do something to clean up the behavior and make it more consistent, but it's not entirely clear we should (though if it can be done easily/well, it seems reasonable).

That's what we did? The problem is that IIRC FF autofocuses only on pageload, Chrome autofocuses only on initial element creation, IE autofocuses every time the element becomes visible, iOS does not autofocus at all, etc, or something like that, my memory is fuzzy but it's a total mess. It's literally useless now for anything but pageload or targetting a specific browser. Overloading is how we normalized the behavior.

Ok, we're probably going to get rid of the tag whitelist eventually anyway

I know it's been talked about, but I just can't see it happening practically, the translation between attribute and property is arbitrary, how would we handle boolean attributes and avoid garbage ending up in the markup? Should attributes really be forwarded as-is? React DOM to me needs to be a good and safe abstraction, removing the whitelist is going in the opposite direction regardless of how enticing it is. But you know more about this than me.

[matthewmueller]

+1, I believe this also prevents you from changing the focus when you render:

Example: http://jsbin.com/getigu/1/edit?html,js,output

[jimbolla]

Given the contested correct behavior of autoFocus, I'd rather abandon it until browsers agree upon its usage. I'd rather be able to do something like:

<input type="text" focusOn="mount" ...  />

or

<input type="text" focusOn="visible" ...  />

Since that syntax is probably not doable, maybe something like

<Focus on="mount">
    <input type="text" ... />
</Focus>

[matthewmueller]

FWIW, I was able to get this working using refs. Probably a better way to do this, but also perhaps a use-case for multiple ref support.

Example: http://jsbin.com/getigu/4/edit?html,js,output

[DenisIzmaylov]

Up! Is there any news?

[jpdevries]

Is it possible to set <input autofocus> when using server side rendering? I've got it working on the client side, but I need it in the initial markup as well

Update:
Seems to not be possible. Well, ReactDOM.renderToStaticMarkup gets you a string, so I then used String.replace to sneak in my autofocus attribute. Feels pretty dirty, but it worked.

[nescalante]

Since React is not supporting this, is there a way/hack/workaround to force attributes not officially supported by React?

[danawoodman]

This seems to be a clear bug in React. Not passing a valid attribute to a form element is not the right behavior, especially since React supports server side rendering. Any chance this behavior will change soon?

[michaelcox]

In React 16 you can now add any DOM attributes. So you can add autofocus="true" to your element now to get it to work.

However, it would be nice if server side rendering translated <input autoFocus /> into <input autofocus="true" /> in the rendered markup.

[gaearon]

In React 16 you can now add any DOM attributes. So you can add autofocus="true" to your element now to get it to work.

I believe React will warn you about this, since autoFocus is the intended spelling. (And that one is handled specially.)

We‘re probably planning to pass the normal autoFocus={true} version through. Track this in #11159.

[gaearon]

Fixed in #11192.