forked from kay-is/react-from-zero
-
Notifications
You must be signed in to change notification settings - Fork 4
/
13-element-refactor.html
101 lines (70 loc) · 3.2 KB
/
13-element-refactor.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
<!doctype html>
<title>13 Refactorización de elementos - React desde Cero</title>
<script src="https://unpkg.com/react@16.4.0/umd/react.development.js"></script>
<script src="https://unpkg.com/react-dom@16.4.0/umd/react-dom.development.js"></script>
<script src="https://unpkg.com/create-react-class@15.6.3/create-react-class.js"></script>
<script src="https://unpkg.com/@babel/standalone/babel.min.js"></script>
<div id="app"></div>
<script type="text/babel">
// Refactorizar un elemento es un poco más complicado
// Primero, debemos determinar si una etiqueta de JSX es un elemento o componente
// minúsculas significa elemento
// mayúsculas significa componente
var element = <div/>
// becomes
element = React.createElement("div", null)
try {
var component = <Div/>
// becomes
component = React.createElement(Div, null)
} catch(e) {}
// Segundo, React convierte todos los eventos que estos elementos lanzan, a
// eventos sintéticos. Esto a menudo no es un problema, porque son simplemente eventos.
// sin embargo no puedes activar el tuyo.
// Entonces, incluso si su componente <Input> acepta la llamada onClick como propiedad
// no puedes llamarlo con el mismo evento que un elemento <input>
// Simplemente implementamos nuestro propio método onChange
// Aquí creamos una entrada numérica que solo llama a Cambio en entradas numéricas
// (los elementos que no sean números lanzan un cambio vacío)
var NumberInput = createReactClass({
getInitialState: function() {
return {value: ""}
},
handleInput: function(e) {
// podríamos intentar modificar el evento para obtener nuestros datos
// pero esto podría romper las cosas
// en su lugar, evitamos que este evento de otras acciones
e.preventDefault()
var newNumber = e.target.value
// filtro para los cambios vacíos
if (newNumber.length < 1 || newNumber === this.state.value) return
this.setState({value: newNumber})
// luego, extraemos neustros datos y los pasamos a onChange
this.props.onChange(newNumber)
},
render: function () {
return <input type="number" value={this.state.value} onChange={this.handleInput}/>
},
})
function logChange(v) {
console.log(v)
}
// Aquí vemos, que el nuevo NumberInput tiene una interfaz diferente
// la propiedad onChange implica que se recibirán eventos, pero esto no es
// el caso. Además, incluso si quisiéramos llamarlo como la entrada original,
// necesitaríamos usar mayúsculas y no ganaríamos nada
var reactElement = <div style={{width: 300, margin: "auto"}}>
<h2>Logging number inputs</h2>
<h2>Before Refactor</h2>
<input type="number" onChange={function(e) { logChange(e.target.value) }}/>
<h2>After Refactor</h2>
<NumberInput onChange={logChange}/>
</div>
ReactDOM.render(reactElement, document.getElementById("app"))
// Otros enfoques incluyen no usar nombres de propiedades "predeterminados" en primer lugar
// onUpdate en lugar de onChange
// También puede ocurrir que un componente use onMouseDown para hacer algo interno.
// y activa un onChange, lo que podría causar confusión
// A menudo los componentes entregan interacciones más ricas que los elementos en primer lugar
// entonces sus métodos de apoyo pueden reflejar eso con el nombre
</script>