The React Playbook

Un conjunto de jugadas, que a lo largo de mi experiencia desarrollando, han servido para mantener sana la salud de nuestro código. Preparada en conjunto con #MercadoLibre para el #DevFest19 #DevFestSantiago.

Transcript

1. The React Playbook The React Playbook Daniel Ochoa
3. ¡Hola! ¡Hola!
4. ¿De qué podemos ¿De qué podemos hablar hoy? hablar hoy?
5. Hooks? Hooks? State? State? Profiler? Profiler?
6. Esos son temas Esos son temas interesantes, pero interesantes, pero solo son una parte solo son una parte del ciclo de vida de del ciclo de vida de una app una app
7. Hablemos de Hablemos de fricciones... fricciones...
8. ¿Cuál es la variable ¿Cuál es la variable que más se repite en que más se repite en las complejidades de las complejidades de implementación? implementación?
9. La salud del código La salud del código del proyecto del proyecto
10. Que los Que los componentes sean componentes sean buenos buenos
11. Objetivo Objetivo Entender cómo podemos Entender cómo podemos escribir buenos escribir buenos componentes componentes
12. ¿Qué es un ¿Qué es un buen buen componente? componente?
13. ¿Cuál es el objetivo de ¿Cuál es el objetivo de un desarrollador? un desarrollador?
14. Construir aplicaciones que Construir aplicaciones que sean... sean... Fáciles de leer Fáciles de leer Fáciles de mantener Fáciles de mantener Fáciles de extender Fáciles de extender
15. El negocio Arquitectura y diseño Manejo del estado Estructura de archivos Convenciones de escritura (linters) Muchos más! Requerimientos Implementación Hay muchos factores que Hay muchos factores que influyen en esto! influyen en esto!
16. Pero al final, el Pero al final, el átomo átomo de de nuestra app, negocio, nuestra app, negocio, feature, siempre será... feature, siempre será...
17. import React from 'react' const Component = ({ name }) => ( <h1>Hi {name}</h1> ) Un componente Un componente
18. Si nuestros componentes Si nuestros componentes son son limpios limpios y y concisos concisos... ... Muy probablemente nos Muy probablemente nos cueste más "romper" el cueste más "romper" el diseño o la arquitectura diseño o la arquitectura
19. ¿Asegura esto que ¿Asegura esto que nuestra aplicación nuestra aplicación será perfecta? será perfecta?
21. Entonces, ¿cómo Entonces, ¿cómo escribimos un escribimos un buen buen componente? componente?
22. Jugada Nº1 Jugada Nº1 Nunca olvidemos tratar a Nunca olvidemos tratar a nuestros componentes nuestros componentes como funciones como funciones
23. Cuando nos olvidamos de Cuando nos olvidamos de esto... esto... Los componentes "hacen demasiado" Conocen muchas muchas props Tienen más de un nivel de abstracción Son "booleano-dependientes" (más de esto en breve) Cambian por las razones equivocadas Nos convertimos en todo lo que juramos destruir: que todo ocurra en el mismo lugar
24. ¿Han visto un componente ¿Han visto un componente parecido a este? parecido a este? const Layout = () => ( <div className="layout"> <header> <nav> <a href="/home">Go home</a> <a href="/heeey">Hooo</a> <a href="/we-are">More than 100</a> </nav> </header> <ProductDescr /> <SomeCallToAction /> <footer> <h2>Hi mom! I'm doing a tech talk!</h2> <a href="http://tiny.cc/q4trdz">Careers</a> // Wink wink ;) </footer> </div> ) * Esta es solo una aproximación. Este markup definitivamente podría ser peor.
25. Este podría ser un enfoque Este podría ser un enfoque más limpio más limpio const Layout = () => ( <div className="layout"> <Header /> <ProductDescr /> <SomeCallToAction /> <Footer /> </div> ) Fácil de leer Es "pequeño" Se entiende lo que hace
27. Jugada Nº2 Jugada Nº2 Cuidado con padecer Cuidado con padecer "Booleanitis"! "Booleanitis"!
28. Ejemplo clásico: UI Feedback Ejemplo clásico: UI Feedback const Component = (props) => ( <div> {props.succeeded ? <Alert success text='Vamo!' /> : <Alert failure text='Y, bueno... esto es incómodo' /> } </div> Si tenemos un segmento de código así: Esperamos ver en la UI algo como esto:
30. Peeeeeerooo.... Peeeeeerooo....
31. Nadie nos detiene de hacer Nadie nos detiene de hacer una maldad como esta: una maldad como esta: const Component = () => ( <div> <Alert success failure text='OMG' /> </div> )
32. El problema principal es que en la El problema principal es que en la implementación hay que hacerse cargo implementación hay que hacerse cargo de de num_bools num_bools combinaciones, cuando realmente combinaciones, cuando realmente hay hay solo solo num_bools num_bools estados posibles estados posibles válidos! válidos! 2 2
33. ¿Qué nos dice ¿Qué nos dice la literatura? la literatura? “ Flag arguments are ugly. Passing a boolean into a function is a truly terrible practice. It immediately complicates the signature of the method, loudly proclaiming that this function does more than one thing. It does one thing if the flag is true and another if the flag is false!"
35. ¿Habrá alguna ¿Habrá alguna manera de escribir manera de escribir mejor este mejor este componente? componente?
36. Hagamos más general la diferenciación Hagamos más general la diferenciación const Component = (props) => ( <div> {props.succeeded ? <Alert variant='success' text='Vamo!' /> : <Alert variant='failure' text='Oh =(' /> } </div> ) ¿Qué valores puede tomar la prop variant? Alert.propTypes = { variant: PropTypes.oneOf(['success', 'failure']) };
37. Ahora pensemos en el uso... Ahora pensemos en el uso... ¿Qué API querría yo ¿Qué API querría yo que tuviera? que tuviera?
38. const SuccessAlert = ({text}) => ( <Alert variant='success' text={text} /> ) const FailureAlert = ({text}) => ( <Alert variant='failure' text={text} /> ) const Component = (props) => ( <div> {props.succeeded ? <SuccessAlert text='Vamo!' /> : <FailureAlert text='Oh =(' /> } </div> ) Busquemos más encapsulamiento Busquemos más encapsulamiento
39. Con esto... Con esto... No hay más booleanos en la API del componente La implementación sigue el principio de mínima sorpresa Cada componente que encapsula hace sólo una cosa La implementación de los componentes puede variar de forma independiente
40. Jugada Nº3 Jugada Nº3 Recordar quién es el Recordar quién es el usuario del componente usuario del componente
41. ¿Cuál es el uso que ¿Cuál es el uso que tendrá el tendrá el componente que componente que estoy escribiendo? estoy escribiendo?
42. Consideremos el siguiente componente Consideremos el siguiente componente <Modal content={"modal content"} customContentStyle={{ backgroundColor: "blue" }} /> Y hagámonos la pregunta... Y hagámonos la pregunta... ¿Cómo puedo cambiar de posición el ¿Cómo puedo cambiar de posición el botón para cerrar el modal? botón para cerrar el modal?
43. La primera respuesta sería hacer algo La primera respuesta sería hacer algo como esto: como esto: <Modal content={"modal content"} closeButtonPosition="top-right" customContentStyle={{ backgroundColor: "blue" }} /> Modal.propTypes = { closeButtonPosition: PropTypes.oneOf( [ "top-right", "top-left", "bottom-left", "bottom-right" ] ) };
44. ¿Y qué pasa si ahora ¿Y qué pasa si ahora necesito invertir la necesito invertir la posición del header posición del header y el footer del y el footer del modal? modal?
45. El componente empieza a contradecir El componente empieza a contradecir todo lo que hemos hablado hoy todo lo que hemos hablado hoy <Modal content={"modal content"} displayFooterOnTop // WTF displayHeaderOnBottom // WTF x 2 closeButtonPosition="top-right" customContentStyle={{ backgroundColor: "blue" }} /> Es altamente probable que cada feature Es altamente probable que cada feature request que tenga que ver con layout, request que tenga que ver con layout, implique una nueva prop implique una nueva prop
46. De forma similar, un caso IRL De forma similar, un caso IRL Es evidente que la información de ambas cards es distinta... ¿Podemos decir lo mismo del layout?
47. En el caso del Modal... En el caso del Modal... Muy probablemente estemos en el punto de vista de una biblioteca consumida por developers, la flexibilidad en la implementación del layout es clave! ¿Cómo debería ser el API del componente?
48. Cosas que debería tener el API del Cosas que debería tener el API del Modal Modal Flexible en la definición del layout Abstracción de funcionalidad básica Ser declarativa
49. ¿Y si tuviéramos un API como...? ¿Y si tuviéramos un API como...? <Modal> <Modal.Content> <Modal.Header> <div>Personalización del layout</div> <Modal.CloseButton>X</Modal.CloseButton> </Modal.Header> <Modal.Body> <h1>Heeeey! Este es el contenido del modal</h1> <Modal.CloseButton> Y si haces click acá, el modal se cierra </Modal.CloseButton> </Modal.Body> </Modal.Content> <Modal.OpenButton text="Abrir!" /> </Modal> ¿Han visto algo así en sus implementaciones?
50. De esta manera De esta manera invertimos el control invertimos el control en la definición del en la definición del layout layout
51. Esto es un Esto es un compound compound component component Un Un compound component compound component es un tipo de es un tipo de componente que maneja el estado componente que maneja el estado interno de un feature, mientras delega interno de un feature, mientras delega el control de la presentación a quien el control de la presentación a quien implementa y no a quien declara implementa y no a quien declara
52. Implementación con Implementación con Context API Context API
53. La definición de ToggleButton La definición de ToggleButton import React from 'react' const ModalContext = React.createContext() const { Provider, Consumer } = ModalContext const ToggleButton = ({ children, openOnClick = false, ...props }) => ( <Consumer> {({ toggleModal }) => { const changeModalState = () => toggleModal(openOnClick) return ( <button {...props} onClick={changeModalState}> {children} </button> ) }} </Consumer> ) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
54. La definición de los componentes static La definición de los componentes static class Modal extends Component { state = { isModalOpen: false } static CloseButton = ({ children, ...props }) => ( <ToggleButton openOnClick={false} {...props}> {children} </ToggleButton> ) static OpenButton = ({ children, ...props }) => ( <ToggleButton openOnClick={true} {...props}> {children} </ToggleButton> ) static Content = ({ children }) => ( <Consumer> {({ isModalOpen, toggleModal }) => { const closeModal = () => isModalOpen && toggleModal(false) return ( <Portal> <div onClick={closeModal}> <div onClick={e => e.stopPropagation()} > {children} </div> </div> </Portal> ) }} </Consumer> ) } 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
55. La definición de render() La definición de render() class Modal extends Component { ... toggleModal = newModalState => this.setState({ isModalOpen: newModalState }) render() { return ( <Provider value={{ isModalOpen: this.state.isModalOpen, toggleModal: this.toggleModal, }} > {this.props.children} </Provider> ) } } 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
56. Hablemos de Hablemos de métricas... métricas...
57. ¿Qué tienen en común estas UI? ¿Qué tienen en común estas UI?
58. Necesitamos Necesitamos monitorear el uso monitorear el uso
59. Veamos una implementación Veamos una implementación class MapItem extends Component { render() { <div onClick={() => this.notifyEvent("click")}> <svg /> </div> } } class ItemBookmark extends Component { render() { <div onClick={() => this.notifyEvent("click")}> <svg /> </div> } } class Slider extends Component { render() { <div className='slider'> <SliderItem onMouseEnter={() => this.notifyEvent("mouseEnter")} /> <SliderItem onMouseEnter={() => this.notifyEvent("click")} /> </div> } } * Algunas partes de la implementación fueron intencionalmente omitidas o simplificadas
60. ¿Qué podemos hacer ¿Qué podemos hacer para no repetir para no repetir código? código?
61. Tratemos de generalizar Tratemos de generalizar class Tracker extends Component { trackEvent = (action_type, options) => { TrackerService.track(this.props.title, action_type, options) } trackClick = (options) => { trackEvent("Click", options) } trackMouseEnter = (options) => { trackEvent("MouseEnter", options) } render() { { this.props.children({ trackEvent: this.trackEvent, trackClick: this.trackClick, trackMouseEnter: this.trackMouseEnter, })} } }
62. Actualicemos la implementación Actualicemos la implementación class MapItem extends Component { render() { <Tracker title="MapItem"> {({ trackClick }) => { <div onClick={() => trackClick()}> <svg /> </div> }} </Tracker> } }
63. Esto es un Esto es un Render Props Render Props Render props es un patrón que permite Render props es un patrón que permite compartir funcionalidad entre compartir funcionalidad entre componentes, delegando el control de componentes, delegando el control de la implementación a un componente la implementación a un componente padre padre
64. De esta manera De esta manera invertimos el control invertimos el control en la en la implementación del implementación del componente componente
65. Render Props en Render Props en 2019 2019
66. Hooks Hooks
67. Veamos cómo cambia el patrón Veamos cómo cambia el patrón import React, { useState } from 'react' const useTracker = title => { const [tracking, setTracking] = useState(false); const trackEvent = (action_type, options) => setTracking(true) TrackerService.track(title, action_type, options) .then(() => { setTracking(false) }) return { tracking, trackClick: trackEvent("Click", options), trackMouseEnter: trackEvent("MouseEnter", options), trackEvent } }
68. Y así queda el componente Y así queda el componente const MapItem = (props) => { const { trackClick, tracking } = useTracker('MapItem') return ( <div onClick={() => trackClick()}> { tracking ? 'Tracking' : 'Not Tracking' } </div> ) }
69. ¡Muchas Gracias! ¡Muchas Gracias! ¿Preguntas?