React: Advertencia al cambiar el tipo y valor de un campo de entrada

Creado en 8 abr. 2016  ·  13Comentarios  ·  Fuente: facebook/react

En mi método de render tengo algo como

<input type={dynamicTypeValue} value={dynamicValue} />

Si primero renderizo esta entrada como un número (por ejemplo, dynamicTypeValue = 'number'; dynamicValue = 5 ) pero luego cambio la entrada a una cadena: ( dynamicTypeValue = 'string'; dynamicValue = '01/01/2016' ) recibo una advertencia
que el nuevo valor no es un número válido:

The specified value "01/01/2000" is not a valid number. The value must match to the following regular expression: -?(\d+|\d+\.\d+|\.\d+)([eE][-+]?\d+)?
DOMPropertyOperations.js:142 The specified value "01/01/2012" is not a valid number. The value must match to the following regular expression: -?(\d+|\d+\.\d+|\.\d+)([eE][-+]?\d+)?

screen shot 2016-04-07 at 6 07 45 pm

¿Es este el comportamiento esperado?

Bug

Comentario más útil

Todavía sucede con la versión 16.4.1

Todos 13 comentarios

Parece que estamos aplicando los cambios de prop en mal orden. La lógica para hacerlo bien se puede resolver en general (para tipos conocidos), pero podría ser complejo perfeccionarlo si queremos minimizar las operaciones DOM.

Me sorprende que este caso en particular sea problemático porque este código debería garantizar que siempre establezcamos .type antes de cualquier otro atributo en un <input> :

https://github.com/facebook/react/blob/0b1fd186855a48dff78987f13466cec1e579b78c/src/renderers/dom/client/wrappers/ReactDOMInput.js#L74

No estoy seguro de por qué eso no funciona según lo diseñado. No me queda del todo claro si el tipo de configuración primero siempre resuelve casos como estos o el tipo de configuración primero simplemente causaría la misma advertencia al cambiar al otro lado.

(Ver también # 2242, que es algo que podríamos querer que sucediera pero que puede ser difícil de implementar limpiamente en el sistema actual. Era más fácil cuando teníamos envoltorios compuestos completos para estos componentes pero ya no los tenemos. Crear un nuevo elemento cada vez que los cambios de tipo podrían ser sorprendentes porque significaría que la referencia a ese componente cambia durante la vida útil del componente que nunca tenemos en otro lugar).

La solución alternativa más fácil aquí es establecer un key en la entrada que cambia con el tipo para que se cree un nuevo elemento de entrada cuando cambia el tipo.

¿Podría ser causado por un error de pedido de Object.assign V8? ¿O fue esto antes de las 15?

@gaearon esto todavía está en la versión 15

@gurinderhans ¿Qué navegador? Además, ¿puede proporcionar un jsfiddle que demuestre el problema?

@jimfb Aquí tienes.
Navegador: Chrome 50.0.2661.86 (64 bits)
JSFiddle: https://jsfiddle.net/mb90na04/1/

Siguiendo el depurador de Chrome encontré esto:
Existe esta línea de código, https://github.com/facebook/react/blob/master/src/renderers/dom/shared/ReactDOMComponent.js#L829 , que luego hace una llamada a https://github.com/ facebook / react / blob / master / src / renderers / dom / client / wrappers / ReactDOMInput.js # L221 y luego se intenta cambiar el valor de la entrada mientras que _updateDOMProperties aún no se ha llamado para actualizar el atributo del elemento type , por lo que se genera la advertencia. Una vez que se llama _updateDOMProperties , type se establece antes de value , como se supone y todo va según el plan.

_ PD: Por supuesto, eliminar la llamada a ReactDOMInput.updateWrapper , dentro de switch case elimina la advertencia, pero esto puede ser necesario para algunos otros casos, ya que también noto que se llama si el elemento type es textarea ._

Puede verificar el cambio de tipo y no establecer el valor, o actualizar el tipo y luego establecer el valor dentro de ReactDOMInput.updateWrapper . También me pregunto por qué se requiere la llamada para casos como <input> o <textarea>

Aquí hay un caso más simple que reproduce el problema: https://jsfiddle.net/97gr5e65/1/

Parece que solo sucede si cambia de number a text . Tampoco puedo reproducir la advertencia en Safari o Firefox en OS X. Tampoco parece ocurrir usando ReactTestUtils .

Este fue un error interesante de verificar, así que investigué un poco. Mi pensamiento inicial fue simplemente asignar type antes de value en el updateWrapper. ¿Es esto cuerdo?

https://github.com/facebook/react/compare/master...nhunzaker : nh-input-change-fix? expand = 1

Elimina el error, pero es demasiado simple. Se siente poco profundo. ¿Qué piensas?

¿Podemos mover las llamadas .updateWrapper por debajo de la llamada _updateDOMChildren (dividiéndolas de las llamadas getNativeProps)? Creo que esa es la mejor solución aquí y parece que debería funcionar.

Si. También pude obtener cobertura de prueba sobre esto. El DOM anula el valor cuando el tipo cambia de manera que el valor ya no es válido, o si se asigna un nuevo valor que no es válido.

Sin relación, es genial que JSDOM recoja esto.

Hecho en https://github.com/facebook/react/pull/7333

Todavía sucede con la versión 16.4.1

¿Fue útil esta página
0 / 5 - 0 calificaciones