Video Summary and Transcription
Esta charla cubre consejos importantes para el desarrollo de software, enfocándose en React. Se enfatiza comenzar con lo que sabes y construir sobre ello. Hacer las preguntas correctas y simplificar los componentes demuestra experiencia. Leer código y hacer preguntas son cruciales para encontrar mejores soluciones. Se destacan la función connect en la biblioteca React Red Hook y el patrón de componente función-como-hijo. Se enfatiza escribir código que sea fácil de entender y mantener para otros. Se menciona la importancia de reintentar en el servidor y refactorizar para el ecosistema.
1. Introducción
Hola a todos, bienvenidos a la Gran Charla de Wear All Hemi. Mi nombre es Krasimir Tzonev y trabajo para una empresa llamada Antidote. Ayudamos a los pacientes a acceder a ensayos clínicos y utilizamos React en todas nuestras aplicaciones de front-end. Hoy he decidido compartir con ustedes los consejos más importantes que he encontrado. Y espero que también les resulten útiles.
♪ Hola a todos, bienvenidos a la Gran Charla de Wear All Hemi. Mi nombre es Krasimir Tzonev y trabajo para una empresa llamada Antidote. Ayudamos a los pacientes a acceder a ensayos clínicos y utilizamos React en todas nuestras aplicaciones de front-end. Cuando no estoy trabajando, paso la mayor parte del tiempo con mi familia. Tenemos dos hijos, así que tengo que llevarlos un poco a la escuela y al jardín de infantes. No sé cocinar en casa, así que mi esposa cocina. Yo lavo los platos. Solía correr antes. Últimamente no corro tanto, pero solía hacerlo. Y durante todas estas tres actividades, en realidad estaba escuchando audiolibros. Así es como mantengo mi cerebro activo. Y empecé escuchando libros de no ficción y luego pasé a los libros de ficción. Y en algún momento, siendo yo mismo autor, pensé por qué no hacer mi cuarto libro una obra de ficción. Hasta ahora solo había escrito libros técnicos, así que pensé por qué no probar algo diferente. Y lo tomé como un proyecto, así que empecé a abordarlo como abordo todos mis otros proyectos, básicamente viendo cómo hacerlo, porque no tengo experiencia escribiendo ficción. Así que decidí ver un tutorial al respecto, como en este caso fue más bien escuchar otros libros, que son libros sobre cómo escribir un libro. Y los encontré realmente útiles y empecé a sacar algunas citas, algunos tips de allí. Y cuando tenía esta lista grande, la revisé y me di cuenta de que en realidad, la mayoría de estos tips también funcionaban para el desarrollo de software. No era solo sobre escribir ficción, por ejemplo. Algunos de estos consejos eran realmente buenos para los programadores. Y si miramos la fecha de la primera novela y la fecha del primer programa, vemos que hay una gran brecha. Así que probablemente todas estas personas que escriben increíbles libros de ficción tienen algo que enseñarnos. Y aproximadamente en este momento, vi una charla de Jane Creighton en React Conf 2019 llamada React es Ficción y pensé, oh mierda, no solo soy yo. Hay otras personas que también se dieron cuenta de lo mismo. Así que hoy he decidido compartir con ustedes los consejos más importantes que he encontrado. Y espero que les resulten útiles.
2. Starting with What You Know
Lo primero en escribir, al igual que en programación, es comenzar con lo que sabes. Por ejemplo, en React, si no estás familiarizado con la escritura de aplicaciones, puedes comenzar renderizando un componente de respaldo. Luego, a medida que aprendes más, puedes construir sobre lo que ya sabes. La complejidad surge a medida que adquieres conocimiento, tanto en la escritura como en el desarrollo de software.
Los encontré útiles también. Entonces, lo primero que creo que la mayoría de los escritores de ficción realmente enfrentan es el síndrome de la página en blanco cuando miras la página en blanco y no sabes cómo empezar o no sabes cómo continuar escribiendo. Tenemos lo mismo en la programación también, especialmente cuando te unes a un nuevo equipo o abres una nueva base de código o eres tal vez más junior, realmente no sabes cómo empezar a escribir algo. Y aquí está lo que Hemingway dice, escribe sobre lo que sabes. Y esto puede sonar algo muy simple, pero encontré que funciona muy bien, al menos funciona para mí. Así que pongamos un ejemplo. Digamos que tenemos este componente y tenemos que escribir este componente de obtención de datos, no existe, simplemente recibimos esto como una tarea. Sabemos cómo debería ser la API, el componente debería aceptar una propiedad de URL, debería tener un respaldo, que es un componente que se renderiza cuando los data están cargando. Tal vez el nombre de respaldo no sea el correcto, pero... luego tenemos los data pasados fuera del componente. Entonces, ahora si no tienes experiencia escribiendo aplicaciones de React, tal vez sabemos algo sobre React pero no mucho. Entonces, si sigues este consejo de escribir sobre lo que sabes, puedes simplemente comenzar renderizando el respaldo. Esto es lo más básico con React, simplemente renderizar algo. Así que simplemente renderizamos el respaldo. Este es nuestro primer paso. Luego, probablemente si comenzamos a leer la documentación, veremos esta cosa llamada estados, que es como el bloque de construcción básico sobre la gestión de estados locales, y reservaremos un lugar para los data. Si los data están allí, codificamos los hijos, que esperamos que sea una función. De lo contrario, simplemente renderizamos los componentes de respaldo. Y en este punto, ya tenemos suficiente, así que podríamos comenzar a hacer más preguntas. Y descubrí que esta es una etapa realmente importante donde tienes algo en qué confiar y luego construyes sobre eso, porque si no tienes nada, ni siquiera sabes qué preguntar, en realidad. Entonces, el siguiente paso sería probablemente preguntarle a alguien más experimentado cómo manejar operaciones asíncronas, cómo hacer solicitudes HTTP, o tal vez simplemente continuar leyendo la documentación, probablemente descubrirás este gancho use effect. Y luego colocas dentro la solicitud real, obtienes los data y lo envías usando la función de los hijos. Entonces, esto es lo primero que encontré útil, especialmente cuando comienzo algo nuevo, escribo lo que sé y luego construyo sobre eso. Y esto realmente te pone en una posición de hacer preguntas, que es un buen lugar para comenzar a hacerlo. Luego, cuando comienzas a conocer cosas, viene la complejidad. Cuando estaba escuchando todos estos libros, descubrí que también hay libros complejos, la complejidad no está solo en el software. Escuché algunos libros que tenían muchas líneas argumentales, tenían muchos personajes, muchas conexiones entre los personajes, había algunos flashbacks. Así que tenía que estar realmente atento. Por ejemplo, cuando estaba corriendo, era difícil escuchar libros tan complejos porque tenía que estar realmente consciente de lo que estaba sucediendo en el libro. Y podemos hablar mucho sobre la complejidad en el desarrollo de software, especialmente en nuestro ecosistema de JavaScript. Y aquí está lo que Stephen
3. Writing Components and Asking Questions
Cuando escribes software, es importante centrarse en la historia. Pregúntate si cada componente o función es realmente parte de la historia. Por ejemplo, al manejar errores en un componente fetch, renderizar mensajes de error puede que no sea parte de la historia del componente. En su lugar, considera pasar el error como argumento a los hijos del componente. Al hacer las preguntas correctas y simplificar los componentes, puedes demostrar tu experiencia.
King habla sobre escribir. Cuando estás escribiendo una historia, te estás contando una historia a ti mismo. Cuando estás reescribiendo, estás eliminando todas las cosas que no son una historia. Y, para ser honesto, si vas a llevar algo de esta presentación, quiero que sea esta última frase. Lo que entiendo de esta cita es que debemos eliminar todas las cosas que no forman parte de la historia. Y la pregunta que me hago todo el tiempo es, ¿esto forma parte de la historia? Cada vez que escribo un componente o una función o cualquier cosa, siempre me pregunto, ¿esto forma parte de la historia? Y esta es una pregunta tan poderosa para hacer. Especialmente cuando tienes tu primer borrador de algo, entonces deberías realmente preguntarte, ¿esto forma parte de la historia? Y si continuamos con el mismo componente fetch, digamos que tenemos que manejar el error, por ejemplo, no hay manejo de errores. Y recibimos otra tarea sobre, Oye, tenemos que asegurarnos de que si hay un error, la aplicación no se bloquee. Y tenemos que renderizar un mensaje en la pantalla en caso de fallo en la solicitud HTTP. Entonces, escribimos lo que sabemos. Así que simplemente reservamos un espacio para el error usando otro estado local. Y adjuntamos un catch al final de la cadena de promesas. Entonces, si hay algún error, simplemente almacenamos el error en el estado local. Y luego, tenemos que mostrar el mensaje. Tenemos que renderizar el mensaje al usuario. Y podríamos, quiero decir, podríamos verificar si el error no es nulo. Si no es nulo, simplemente renderizamos este mensaje. Y aquí es donde debemos preguntarnos, ¿esto forma parte de la historia? Y para ser honesto, este mensaje no forma parte de la historia de este componente. Porque este componente se trata solo de obtener data. No se trata de copiar. No se trata de estilos. Solo se trata de obtener los data o manejar el error, si lo hay. Definitivamente no forma parte de la historia de este componente. Probablemente forma parte de la historia del componente que consume fetch. Entonces, lo que podemos hacer es verificar si hay algún error. Si hay algún error, podríamos enviar el error como primer argumento de los hijos. Quiero decir, esta es solo mi elección, pero podría ser cualquier otra firma. Al hacer esto todo el tiempo, al preguntarte si esto forma parte de la historia, básicamente estás escribiendo componentes más simples. Al menos esa es mi experiencia. Luego, cuando estés en esta etapa donde comienzas a hacer más preguntas, y para ser honesto, creo que se puede ver claramente la diferencia entre una persona más junior y una persona de nivel medio cuando comienzan a hacer preguntas. Si comienzas a hacer las preguntas correctas y especialmente a responder estas preguntas, entonces puedes hablar de experiencia senior.
4. Importancia de Hacer Preguntas y Leer Código
Hacer preguntas es crucial para encontrar mejores soluciones. Sin embargo, la falta de experiencia puede dificultar saber qué preguntas hacer. Para adquirir más experiencia, se recomienda leer código escrito por otros desarrolladores.
Hacer preguntas todo el tiempo es realmente un buen enfoque para encontrar mejores soluciones. El problema es cuando no tienes suficiente experiencia, no sabes qué preguntas hacer. Entonces, ¿cómo puedes obtener más experiencia? Bueno, Hemingway dijo que cuando estaba escribiendo, era necesario que leyera y Stephen King tiene otra cita sobre si no tienes tiempo para leer, no tienes tiempo para escribir. Estoy bastante seguro de que leer mucho código, especialmente el de tus colegas o de tu base de código porque tienes que hacer revisiones de solicitudes de extracción, por ejemplo. Pero de lo que estoy hablando
5. Explorando la Función Connect y Leyendo Código
Me fascinó cómo funciona la función connect en la biblioteca React Red Hook. Esto me llevó a escribir un artículo y lanzar una biblioteca basada en este patrón. Sin embargo, más tarde descubrí que este patrón no era nuevo y se había utilizado durante años. Leer código, especialmente en bases de código grandes como React, puede enseñarte mucho.
Una de las cosas que deberías intentar es leer el código de otros desarrolladores. Yo, por ejemplo, y estoy bastante seguro de que tú también, probablemente escribas este fragmento de código muchas veces. Y esta es la forma en que conectamos un componente o una tienda Red Hook. Y en el pasado, me preguntaba cómo funcionaba esta función connect. Y cuando abrí el código de la biblioteca React Red Hook, esta captura de pantalla es similar a lo que tenemos ahora. Supongo que antes era más o menos lo mismo. Pero vemos una función que acepta nuestro componente y luego, en su interior, hay otro componente que renderiza nuestro componente original. Así que empecé a jugar con este patrón y me pareció muy interesante cómo funcionaba todo. Luego empecé a escribir un artículo al respecto. Le di a esta cosa un nombre. Incluso lancé una biblioteca que lo hacía. Y cuando lo compartí en la web, la gente decía que era como un componente de hardware. No era algo nuevo. La gente lo ha estado usando durante años. Así que estaba reinventando la rueda para mí mismo una vez más. Fue realmente interesante descubrir cómo funcionaba todo simplemente leyendo el código. Te puedo decir cuántas cosas he aprendido simplemente leyendo el código de los demás. No solo el código en el trabajo, sino también el código de bibliotecas. Y no tengas miedo de sumergirte en una base de código grande, como la de React, por ejemplo. Incluso solo leyendo paso a paso cómo está organizado todo, aprenderás mucho.
6. El Patrón de Componente Función como Hijo
El patrón de componente función como hijo, ejemplificado por Formic, es uno de mis favoritos. Permite que componentes como Formic tengan responsabilidad mientras brindan valor al consumidor. Leer código de bibliotecas populares, que a menudo implican colaboración entre desarrolladores, puede ofrecer ideas valiosas y decisiones inteligentes.
Hay otro patrón que realmente me gusta. Y este es el patrón de componente función como hijo. Este es un ejemplo de Formic. Pero creo que el primer lugar donde vi este patrón fue en la biblioteca de enrutamiento de React. Y aquí, si no sabes cómo funciona esto, podríamos ir directamente a la biblioteca de Formic y ver cómo hay este componente Formic. Oh, leen los hijos de las props. OK, así que esta es la prop nativa de React. Oh, y simplemente llaman a los hijos como una función, lo cual, la primera vez que lo vi, fue un poco extraño. Pero los hijos realmente pueden ser cualquier cosa. Incluso podrían ser una cadena o un número. No importa para React. Entonces, este patrón en particular, para ser honesto, es mi favorito porque le da cierta responsabilidad al componente, como en este caso Formic, pero al mismo tiempo puede proporcionar algo fuera de él, como en el consumidor del componente. Así que lee el código de los demás, especialmente todas estas bibliotecas realmente populares, porque generalmente estos proyectos son una colaboración entre muchos desarrolladores, y estoy bastante seguro de que, colectivamente, han hecho algo realmente inteligente y han tomado decisiones interesantes y buenas. Así que si tienes la oportunidad, solo revisa algunas de estas bibliotecas.
7. Escribiendo Código para Otros
El código que escribimos no es solo para nosotros, sino para que otros lo lean, mantengan y amplíen. Stephen King dijo: 'escribe con la puerta cerrada, reescribe con la puerta abierta'. Al escribir código, es importante hacerlo simple para que otros lo entiendan y revisen. Debemos renombrar componentes y props para reflejar su propósito y eliminar los innecesarios. Siguiendo este enfoque, podemos ayudar a otros a comprender mejor nuestro código, incluso sin entrar en los detalles de implementación.
Entonces, la última parte de mi presentación es realmente una pregunta. Nuevamente, vuelvo al punto donde tienes que hacer preguntas todo el tiempo. Entonces, mi pregunta principal suele ser, ¿quién es el lector? Y cuando estamos escribiendo libros de ficción, supongo que esta pregunta es un poco debatible, supongo, para los escritores de ficción, pero para los desarrolladores de software, creo que está muy claro que el código que estamos escribiendo no es solo para nosotros. Es principalmente para que otras personas lo consuman, lo lean, lo mantengan, lo amplíen. Por lo tanto, es importante escribir para otros, para otras personas. Y esto es lo que dijo Stephen King, escribe con la puerta cerrada, reescribe con la puerta abierta. Siempre recuerdo esta cita cuando reviso mis solicitudes de extracción antes de anunciarlas a mis colegas, porque incluso Hemingway dijo que el primer borrador siempre es una mierda, cito textualmente, pero luego de eso, tienes que volver atrás, tienes que preguntarte, ¿esta parte de la historia está siempre presente? Entonces, tienes que escribirlo de una manera que sea simple para que otras personas lo entiendan, sea simple para que otras personas incluso realicen la revisión de código. Si alguien pasa como una hora revisando tus 50 líneas de cambios, significa que no es realmente bueno. Entonces, si tomas este ejemplo, por ahora, no te enfoques en esta área, la prop action del componente form. Digamos que este es un componente sobre, se llama obtener correo electrónico, tenemos un campo de entrada llamado escribimos el correo electrónico. Cuando cambiamos algo, almacenamos el valor en un estado local llamado valor. Y tenemos un botón de enviar, que probablemente, si lo presionamos, vamos a la acción del componente form y registramos al usuario usando el correo electrónico. Entonces, esto lo considero un borrador. Y podría hacer un par de mejoras. La forma en que refactorizo mis componentes es primero mirar los componentes desde el exterior, como la API, lo que significa el nombre del componente y las props. Y en este caso, sé que este componente está registrando al usuario. No se trata solo de obtener el usuario del campo de entrada de correo electrónico. Se trata de realmente registrar a los usuarios, así que es mejor que lo llamemos simplemente registrar. Tenemos una prop llamada callback. Seguro que callback es una función, pero realmente no habla sobre por qué se dispara esta función más tarde. Entonces onSuccess, supongo, es mejor. Error ni siquiera parece una función. Entonces, desde el exterior, no tenemos idea de que tenemos que proporcionar una función, así que es mejor llamarlo onError. Al hacer estos pequeños cambios, aunque solo sea un cambio de nombre, ayudamos a otras personas a comprender mejor nuestro componente, incluso sin entrar en la implementación. Este es mi enfoque. Inicialmente, comienzo desde el exterior, miro la API, y generalmente solo cambio el nombre de las cosas. A veces encuentro props que no deberían estar allí. No forman parte de la historia, por ejemplo. Cuando avanzas hacia adentro, el valor es en realidad un correo electrónico, así que ¿por qué no llamarlo simplemente correo electrónico? Sería más fácil cuando estás leyendo el archivo de arriba a abajo, y cuando llegas al correo electrónico, simplemente ves que esto es un correo electrónico. Y ahora, esta pieza de lógica, que se trata de hacer las solicitudes usando este
8. Reflexiones Finales y Recomendaciones
Si se trata de algo en el servidor, lo intentamos de nuevo. La historia aquí trata de hacer una solicitud y manejar el error. La refactorización se trata de probar el código para otros compañeros de equipo y personas en el ecosistema. Gracias por ver y escuchar.
API.users.register, si esto falla, entonces verificamos el tipo de error. Si se trata de algo en el servidor, lo intentamos de nuevo. Y incluso ahora podemos ver que esto tiene un error potencial, porque si esto falla, la aplicación explotará. Y aquí está, una vez más, mi pregunta favorita, ¿cuál es la historia aquí? Y la historia aquí trata de hacer una solicitud y manejar el error. Y podríamos simplemente escribir dos funciones, y es mucho más limpio, creo, e incluso estamos solucionando el error, porque si la segunda solicitud falla, aún estaremos en un error try-catch. Así que toda esta refactorización realmente se trata, supongo que se trata de Measville, porque después de una semana, probablemente no recuerdo qué está sucediendo. Pero en general, es solo para otras personas. Así que debemos probar el código para otros compañeros de equipo, para otras personas, que ni siquiera conocemos en el ecosistema.
Y con esto, quiero terminar mi presentación. Si te gustaron algunos de los tips que mencioné, te recomiendo encarecidamente que consultes estos libros porque los escuché. Y tal vez encuentres algo interesante también. Gracias por ver, por escuchar. Este es mi nombre de usuario de Twitter y este es el enlace para las diapositivas. Sí, gracias.
Comments