Crímenes de Código para una Buena API de Componentes

Ahora, trabajo en el lado de React. Trabajo en esta biblioteca de componentes que usamos para construir otras páginas en GitHub, y esta es una pregunta en la que pienso, que es qué hace que una interfaz de API de componente sea buena. Porque eso es lo que tus usuarios, los desarrolladores, están consumiendo. Y es más o menos lo mismo. Debe ser intuitiva para leer y escribir código, debe ser accesible por defecto y debe ser consistente. Entonces, por consistente, me refiero a que debe tener una superficie de API pequeña. Si sabes cómo usar un componente, puedes adivinar cómo usar otro componente, porque la API es consistente. Ese es el objetivo, al menos. Pero no siempre es fácil. A veces no está en las partes buenas y felices de React, y ahí es donde entran los crímenes. Así que veamos algunos.

Tengo este componente. Se llama AnchoredOverlay, y se llama AnchoredOverlay porque abre una superposición que está anclada a este botón. Entonces, AnchoredOverlay. Y la forma en que funciona este botón, la forma en que funciona este componente es que tienes que gestionar su estado. Entonces, pasas open, le das las funciones onOpen y onClose, y luego le das un renderizado. Entonces, esto es una render prop. Puedes renderizar el elemento adentro. En este caso, estoy renderizando un botón. Y luego te pasa algunas props que se supone que debes pasar al elemento. Entonces, hay cosas como, tengo props en esto. Hay algunos estilos para este AnchoredOverlay. Así que una API simple, no hay mucho más. Y luego dentro de él, puedes poner children, que se renderizan allí. Entonces, buen componente. Ahora, el lugar donde podríamos usar este componente es, esta es una página de solicitud de extracción de GitHub. Y ves que hay un montón de menús aquí.

Puedes asignar etiquetas, puedes asignar asignados a una solicitud de extracción, y esto parece ser un buen caso de uso para AnchoredOverlay, porque hay una superposición y está anclada a este botón. Ahora, si tengo que construir este componente, la forma en que lo haría es usando AnchoredOverlay. Tengo que gestionar su estado, así que digo open. Voy a hacer un set state, y luego simplemente establezco open en true y no abierto y establezco open en false y no cerrado. Y en el ancla renderizada, puedo usar el componente de botón de la biblioteca de componentes, pasar las props de ancla. Y tenemos esta convención de diseño de que si un botón abre un pop-up o un menú, no debería verse como un botón normal. Debería tener esta indicación. Así que tenemos un ícono de triángulo hacia abajo y la zanahoria es la predeterminada, así que el ícono de triángulo hacia abajo de la biblioteca de íconos. Pero en este caso, también podría ser esta flecha. Y voy a ajustar este botón para que parezca un oso. Me gusta. Se ve bastante bien aquí, y funcionaría. La superposición está anclada al botón. Todo está bien.

Ahora, lo que no me gusta de esto es que la API no es tan agradable. Así que AnchoredOverlay es perfecto, pero si tengo que crear este menú y estoy tratando de crear esto en un solo componente y tomar algunas de estas decisiones, primero que nada, tal vez lo llamaría algo como menú de acción porque es un menú de acciones, y realmente no quiero que el estado sea gestionado por defecto. El componente debería ser lo suficientemente inteligente como para hacer esto por defecto, que cuando hagas clic, se abra el menú. Así que voy a eliminar esto. Y lo siguiente que eliminaría es esta API de renderizado de ancla. Nuevamente, quiero que sea lo suficientemente inteligente como para saber qué props pasar y luego pueda pasarlas por sí mismo. Así es como funciona. El ícono de flecha, nuevamente, es una convención de diseño que ya conocemos y queremos que las personas sigan, así que sería bueno si estuviera incluido como predeterminado. Así que voy a decir menú de acción.boton. Este es un botón que usas con el menú de acción y tiene el triángulo, la zanahoria, todo incluido. Y finalmente, voy a crear menú de acción.superposición para adaptar el contenido porque voy a agregar algunas props como el ancho es medio. Esto se ve bien para mí. Vamos a pasar a la implementación. La implementación del menú de acción es un poco

Entonces, ahora que estoy viendo este componente e intentando implementarlo, las cosas de estado son fáciles, eso está bien, pero luego tengo esta renderización de ancla, necesito un componente para pasarle estas props, ¿verdad? Así es como funciona. Necesito renderizar este componente, y la API que hemos creado es este es el botón y esta es la superposición. Entonces necesitamos alguna forma de enviar realmente este botón del menú de acciones a la superposición y React realmente no tiene una forma de comunicarse entre hermanos. Una vez que un hijo no puede decirle a su hermano qué es lo que necesita. ¿Entonces cómo lo hacemos? La forma de hacerlo en React sería subir esto al padre, ¿verdad? A React le gusta que los datos se pasen del padre a los hijos. Y luego, si quieres hacerlo en sentido contrario, tienes que pasar una devolución de llamada al hijo y el hijo puede llamar a esa función. Así es como lo hacemos. Subimos el ancla al padre. Entonces ahora el menú de acciones tiene un estado, define el ancla. Y luego creamos un contexto, pasamos tanto el ancla como el conjunto de anclas y los hijos envueltos para que tanto el menú como la superposición puedan acceder a esto. Dentro del menú decimos, si el ancla no está definida, entonces la definimos. Establecemos el ancla y aquí está el botón que vimos. Y luego las props que pasas se pasan al botón. Así que eso funciona. Y luego devolvemos null porque este botón realmente no necesita devolver nada. El ancla se renderiza en realidad por la superposición anclada. Así que dentro de la superposición del menú usamos el contexto, obtenemos el ancla de allí y hacemos una renderización de ancla. Un poco extraño pero no demasiado complicado. Esta es la forma en que abstraerías el estado hacia arriba en un componente padre y luego lo pasarías a todos los hermanos que lo necesiten. Y esto funciona bien, como ahora si recargo verás que los asignados, el botón del menú no renderiza nada porque la superposición del menú lo renderiza. Así que renderiza tanto el botón como la superposición.

Ahora, lo interesante es que en el lado del cliente todo está bien, pero si hago esto con la renderización en el servidor, ocurre algo curioso. Verás, hay un poco de retraso aquí, ¿verdad? Y eso obviamente no es bueno y eso sucede porque digamos que hacemos una renderización en el servidor y luego la pausamos. La primera renderización en el servidor, el estado del ancla era nulo y luego cuando se establece el ancla, como cuando se renderiza el botón del menú con el ancla establecida y provoca una nueva renderización y eso establecerá este ancla de renderización para la superposición. Así que necesitamos dos renderizaciones y si estás en la renderización en el servidor, entonces la primera vez que renderices, enviarías ese HTML al cliente y aunque la segunda renderización ocurra después de eso, después de establecer el ancla, no importa porque el HTML ya se ha enviado. Y ahora en el cliente, el paquete de JavaScript llegaría, React se hidrataría y luego llamaría a establecer el ancla y ahí es cuando realmente se renderizaría el ancla. Así que es por eso que ves esta gran brecha donde en el servidor, la página completa se renderiza sin el ancla, luego llega el paquete, ocurre la hidratación y ahí es cuando lo ves. Entonces, nuevamente, si es solo en el lado del cliente, no es tan importante, pero en el momento en que comenzamos a renderizar en el servidor, especialmente con redes lentas, esto podría llevar un tiempo para que llegue el paquete. Así que eso no es genial, no es ideal, nada de eso. Entonces, ¿cómo podemos hacer que este botón se renderice antes? ¿Cómo podemos establecer el ancla en el servidor en lugar del cliente? La respuesta es el cliente. Lo siento, entonces lo que hacemos aquí es decir que el ancla es nula, comencemos con eso en el menú de acciones y luego React tiene esta API de nivel superior llamada react.children y tiene un montón de funciones. Entonces lo que haces es darle props.children y luego te permite recorrer el hijo e inspeccionar sus propiedades. Una de las propiedades que tiene un hijo es child.type y child.type es realmente interesante porque te da la función que se usó para crear este componente. Entonces, en el caso del botón del menú de acciones, te daría la función que se usó, que es este botón de menú, lo que significa que puedes hacer cosas como esta. Puedes decir child.type y simplemente usar la referencia para comparar. Si child.type es el botón del menú, eso significa que tienes el botón del menú de acciones y luego puedes simplemente decir establecer el ancla. Así que estoy diciendo que el ancla es nula, estoy mapeando si es el botón del menú, simplemente digo que el ancla es el hijo. Y si es la superposición del menú, entonces clonemos ese elemento y pasémosle una prop adicional. Nuevamente, todos estos son API de nivel superior y estoy pasando la prop render anchor. Estoy creando eso sobre la marcha y pasándolo a la superposición del menú. Así que esto es súper interesante porque todo esto ha sucedido incluso antes de que el menú de acciones haya hecho algo. Entonces, ahora, incluso en una red 3G lenta cuando recargo, verás que todo viene del servidor. Esto ya está hecho. Y este es un patrón interesante. Y la restricción aquí, por supuesto, es que debes usar el botón del menú o la superposición del menú, no puedes usar un tercer componente. Y lanzamos un error si lo intentas, dice que el menú de acciones no identifica lo que pasaste, por favor, no uses ninguno de estos o consulta la documentación. Y luego agrego un comentario agradable para mis compañeros de trabajo porque no soy un monstruo. Entonces, déjame preguntarte, ¿esto es un truco? Absolutamente. ¿Pero es esto un crimen de código? Para todos nosotros. Entonces, un componente que, déjame decirlo de esta manera, el objetivo de un buen componente, al igual que un buen diseño de interfaz de usuario, es abstraer palabras molestas. Especialmente el trabajo que no es fundamental para los objetivos del usuario o el desarrollador en este caso.

Entonces, a veces los crímenes están bien, ya sabes. Y una mejor manera de decirlo podría ser que los trucos que hicieron que el código sea más fácil de leer y entender, ayudando a los desarrolladores a hacer un buen trabajo más rápido dentro de los límites razonables del sistema están bien. Entonces, las limitaciones razonables aquí son que si estás usando el menú de acciones, debes usar action menu.button y action menu.overlay, lo cual funciona muy bien porque también son componentes de la misma component library y estamos usando todo esto para construir GitHub. Tal vez si eres una biblioteca de código abierto como material o chakra, es posible que no puedas imponer esas limitaciones. Las personas pueden usar su propio botón, pero funciona bien para nosotros.

Entonces, siguiendo adelante. Genial. Respira profundamente. Vale, más crímenes. Entonces, tenemos este componente llamado nav list o lista de navegación. Y la forma en que funciona este componente es que tenemos una lista de navegación y puedes renderizar elementos de lista de navegación dentro de ella. Lo usamos en la página de configuración donde tienes un montón de componentes, un montón de páginas de configuración y luego agregamos este elemento como una lista. Puedes tener un icono. Puedes tener un regalo.

Entonces, por ejemplo, cuando hago clic en este perfil público, este es el elemento seleccionado. Y la forma en que mostramos este estado seleccionado en el sitio es mediante el uso de la propiedad aria-current. Entonces, en una lista de, en una lista de navegación, es una buena práctica. Es como si hiciera que la página fuera accesible para el lector de pantalla donde dices aria-current y luego si esta es la página actual que está seleccionada, entonces dices aria-current esta página, de lo contrario no dices nada. Entonces, intentamos reutilizar esta propiedad aria para mostrar los estilos para el estado seleccionado como una forma de incentivar a las personas o promover el uso de propiedades accesibles.

Y, por supuesto, hay un montón de estos. La configuración es muy larga. GitHub es grande. Entonces, tenemos un montón de ellos. Solo tiene sentido agruparlos de alguna manera. Así que creamos este componente llamado navlist.group. Es bastante similar. Toma un título. Toma un icono y luego toma, nuevamente, navlist.items. Puedes tener navlist.items sin ningún grupo o puedes agruparlos dentro de esto y obtienes una lista de navegación anidada.

Entonces, lo interesante de esto, nuevamente, es la forma en que mostramos el IO actual. Mostramos el elemento de navegación actual seleccionado, leyendo el IO actual de esta lista. Entonces, cuando recargas esta página, el elemento seleccionado se resaltará. También eres tú. Pero lo más interesante es, si es parte de un grupo, entonces este grupo estaría abierto. Entonces, si intento abrir el perfil público, todos los grupos están cerrados, pero si recargo uno de los implantes de facturación, que es parte de acceso, el grupo estaría abierto de forma predeterminada, lo cual tiene sentido, ¿verdad? Quieres saber dónde está la cosa.

Entonces, el grupo básicamente tiene que saber si uno de sus elementos es el valor actual de IO. ¿Entonces, cómo funciona esto?

Ahora, esto es un poco aburrido. Es una navegación con una lista dentro. Y ese elemento también es un poco aburrido. Es el elemento de la lista dentro, porque el padre es un UL. Entonces, esto tiene que ser un LI. Y luego renderizamos un componente de enlace del design de la component library. Entonces, todas las cosas divertidas están ahí.

Entonces, ese grupo, por supuesto, es el elemento de la lista porque se renderiza dentro de un UL. Y esta cosa es un botón, porque haces clic en él y puedes cambiar el estado. Tiene un icono de reunión. Renderizamos los hijos junto a él. Y ahora necesitamos una forma de identificar básicamente si esto está abierto o cerrado. Entonces, establecemos el estado, decimos, gestionamos el estado. El estado se puede alternar con el botón. Y luego incluso podemos hacer esto, llevarlo como un icono adicional. Lo llevo hacia arriba o lo llevo hacia abajo, ¿verdad? Como este.

Entonces, todo esto es bastante genial cuando interactúas con él. Pero, ¿cuál es el valor predeterminado de esto? Necesitamos saber si este grupo de navegación tiene un elemento dentro de él, que tiene ARIA actual, para que podamos establecer eso como abierto por defecto es igual a verdadero. Ahora, un recordatorio de que esto es lo que estamos buscando, pero estamos buscando, necesitamos acceder a este valor aquí arriba en el grupo. Entonces, una de las opciones podría ser simplemente preguntar al usuario, ¿verdad? Preguntar al desarrollador que está usando este componente que establezca el valor predeterminado. Y eso obviamente funciona, pero si piensas en qué sería la developer experience aquí, qué tipo de código tendrían que escribir, probablemente sería algo como esto, donde tienes que mantener una lista de todos estos, y luego decir si incluye alguno de ellos, entonces esto debería estar abierto. Y ya están haciendo parte de esta información aquí, y esto se siente un poco redundante. Esto obviamente no funcionaría en SSR, así que probablemente tendrías que acceder a un enrutador aquí. Y se siente como mucho trabajo que es fundamental para lo que están tratando de hacer, lo que también significa que podemos ser pasados por alto y luego obtienes una mala user experience. Entonces, un componente inteligente simplemente absorbería esto.

Entonces, ¿cómo enviamos este valor automáticamente? Una forma, por supuesto, sería hacer crímenes para seleccionar los componentes de los hijos. Y hemos hecho algo así antes, donde podemos decir que el valor predeterminado abierto es falso, y luego mapeamos todos los hijos. Y si alguno de ellos tiene ARIA Aparente, entonces ese valor predeterminado abierto debería ser verdadero, ¿verdad? Eso tiene sentido. Y eso es bastante fácil.

Pero recuerda que dije que las aplicaciones que generan código son aceptables dentro de los límites razonables del sistema. Ahora, cuando comenzamos a probar esto, ¿es una restricción válida? ¿Puede la lista de navegación... Perdón, ¿puede el grupo NavList asumir que tendrá este elemento y poder seleccionar ARIA Aparente es donde encontramos problemas. Muy a menudo, la gente usaría un enrutador diferente, como pueden usar Next router o un enrutador de React o un enrutador de Remix. Y luego, lo que terminarían teniendo es que la lista de navegación podría tener un componente personalizado como un enlace de enrutador, e incluso dentro de eso, el ARIA Aparente podría ni siquiera estar en NavList.item. Podría estar en algo como Next link. Así que perdemos eso. No podemos simplemente ir al componente y leer las propiedades porque ese no sería el caso aquí. Así que esas no son restricciones razonables en el sistema. Ni siquiera podemos confiar en las devoluciones de llamada porque, como puedes ver aquí, NavList.item ni siquiera sabe si está seleccionado porque ahora es una propiedad de next link. Podríamos cambiar algunas cosas. Podríamos volver a usar el valor predeterminado abierto, pero sería realmente bueno si este componente pudiera hacerlo por sí mismo. Entonces, si no podemos asumir hijos, ¿cómo podemos establecer el valor predeterminado? La respuesta, por supuesto, es Grandioso. Entonces, lo que hacemos aquí es el CreatorRef y luego la asignación en el elemento raíz del grupo. Y después de que se haya montado, el imperativo dirá QuerySelector para ARIA actual. Y esto es algo divertido porque QuerySelector ocurre en el DOM renderizado. Así que realmente no le importa cómo están estructurados los componentes. ¿Es un hijo directo? ¿Está profundamente anidado? Nada de eso realmente importa porque, bueno, en este caso ya está renderizado y está en algún lugar dentro del grupo. Así que hacemos un QuerySelector y establecemos setOpens. Por supuesto, incluso, ya sabes, funciona perfectamente aquí. Entonces, lo interesante de todo esto es, ¿es un antipatrón? Lo es en cierto modo, ¿verdad? Cuando hacemos llamadas de API imperativas con QuerySelector dentro del componente de la aplicación, que tiene una destreza de diseño. Así que es un poco antipatrón, pero ¿es un crimen de código? Ayúdame. Creo que el objetivo de un buen componente es abstraer todo este trabajo molesto. Y averiguar si un grupo tiene un elemento seleccionado y abrirlo, se siente como si no fuera parte esencial de la configuración. ¿Verdad? Quieres centrarte más en qué configuraciones estás cambiando, ¿cuáles son los formularios para la experiencia del usuario? Esto se siente como un beneficio adicional. Así que creo que no debería ser parte de ello. Entonces, está bien. Este crimen se siente bien.

Bueno, uno más antes de irnos, porque tenemos poco tiempo. Hay algo, esto aún no es perfecto. Si está en el lado del cliente, entonces está bien. Sabes, no importa realmente. Pero si están utilizando SSR, esto lleva a esto, donde el uso de layout effect solo ocurre en el lado del cliente, no en el servidor. Sucede después del montaje. Entonces terminas con algo como esto, donde está cerrado en el servidor y luego solo se abre en el cliente. Lo cual, quiero decir, no me malinterpretes. Esto se ve genial. Me gusta que sea como una pequeña animación. Así que eso funciona. Pero si está en una conexión 3G lenta, no debería funcionar. Sí, esto está bien. Entonces, si está en una conexión 3G lenta, se abrirá después de mucho tiempo, ¿verdad? Como si aún no supiera que ha llegado el paquete y solo entonces se hidrata, ejecuta use layout effect y se abre. Y esto lleva mucho tiempo. Es posible que ya estés viendo alguna otra configuración y de repente se abre y te distrae. Entonces eso no es realmente bueno. La respuesta, la pista que puedo darte, es que obviamente son los clientes. Y lo que queremos es que el valor predeterminado se establezca más pronto, ¿verdad? No necesariamente necesitamos que esto ocurra en el servidor. Solo queremos que sea más pronto. Y eso es todo lo que te diré como pista.

Y te dejaré con esta última parte, que son acciones que hacen que el código sea más fácil de leer y también ayudan a los desarrolladores a hacer un buen trabajo dentro de límites razonables con los sistemas. Así que a veces los hacks están bien. Otras veces, ese soy yo, ese soy yo en Twitter. Nos vemos allí. Sidd, siempre es genial pasar tiempo contigo. Desafortunadamente, no estás aquí, pero siento que hicimos esto el año pasado también, nos unimos virtualmente. Es bueno verte de nuevo, amigo mío.

¿Cómo estás? Estoy bien, ¿y tú? Estoy bien. Muy bien, pasemos a las preguntas. Tenemos una pregunta que pregunta, ¿es una buena idea implementar una solución alternativa que dependa de las API internas del frameworks? ¿Y qué pasa si React decide dejar de respaldar eso en el futuro? Esa es una buena pregunta. Diría que definitivamente no es una API interna, pero si es una API de nivel superior como React.java, entonces puedes salirte con la tuya. Voy a ser muy honesto, la mayoría de estos son hacks, ¿verdad? Pero a veces los hacks hacen el trabajo. Y siento que en este punto, con la forma en que el equipo de React está comprometido a respaldar la compatibilidad con versiones anteriores, están retorciendo el brazo. Realmente no pueden romper ninguna de estas API de nivel superior. ¿Sabes qué, Sid? La próxima vez que alguien me haga una pregunta difícil sobre si es una buena idea tomar esa decisión, voy a tomar esa diapositiva. También voy a citarte en ella.

De hecho, una cosa. A mucha gente, siempre me encanta tu estilo de presentación y la forma en que nos muestras código en vivo y nos haces esas demostraciones. Alguien ha preguntado sobre la herramienta que usas. ¿Qué estás usando para controlar la velocidad de las pruebas en los ejemplos? Porque cuando estamos construyendo nuestras propias plataformas, queremos hacer estas pruebas en diferentes entornos. ¿Qué usas? Bueno, lo que suelo hacer es usar la pestaña de red de Chrome que tiene múltiples emulaciones. Para la charla, no estoy haciendo nada de eso. Eso fue una simulación. Básicamente, le dije, por favor, usa esto, esta es la velocidad que se me permite. Y luego reduciría mi código real. No hay problema, como dijimos, los hacks son buenos si puedes salirte con la tuya. Pero en cuanto a los hacks, ¿crees que hacks como estos pueden afectar la legibilidad del código a largo plazo? Especialmente cuando empiezas a encontrar cosas en lugares que tal vez no esperabas ver? Oh, definitivamente. Así que creo que la gran advertencia que pondría aquí es que no recomendaría estos hacks si solo los necesitas una vez, o si puedes, ya sabes, si es una aplicación, hombre. La forma en que justifico mis hacks es que algunos de ellos, alguien tiene que hacerlos, ¿verdad? Si React no tiene una solución de nivel superior para esto, tienes que poner ese código en algún lugar. Así que preferiría ponerlo en la biblioteca que se reutiliza y escribir un montón de pruebas para ello que ponerlo más cerca del usuario para el que probablemente no estoy escribiendo tantas pruebas.

Diría que afecta la legibilidad y también el mantenimiento. Como escribimos un montón de pruebas para estos crímenes porque estás jugando con fuego. Si algo sale mal, podrías romper muchas cosas. Así que sí afecta, pero siento que tienes que encontrar dónde colocar la complejidad porque tiene que ir a algún lugar. Así que colócala donde puedas mantenerla con la mayor confianza.

También, una cosa, esta es una pregunta mía que estoy lanzando aquí. Una cosa que me encanta es cada vez que veo una de tus charlas veo algo nuevo. He aprendido sobre los sistemas de diseño y cosas que claramente obtienes al ver cómo los desarrolladores interactúan con los sistemas de diseño en los que trabajas. ¿Cómo obtienes esa retroalimentación y ves los comportamientos que están construyendo y luego intentas implementar buenas prácticas desde una perspectiva de sistema de diseño?

Esa es una buena pregunta. Creo que lo que terminan haciendo mucho es porque usan GitHub para construir GitHub y su meta, simplemente terminamos mirando patrones y hay patrones que se repiten mucho. Y en esos patrones podemos llevarlos a la escalera del sistema de diseño haciendo código en Figma, realmente haciendo storybook, historias para imágenes, y luego comenzamos desde el final. Luego esto es lo que nos gustaría que tengan nuestros usuarios, los desarrolladores que construyen GitHub. Entonces, ¿qué tipo de abstracción necesitamos construir para respaldar eso? Supongo que la primera etapa es el inventario donde simplemente observas todas las cosas que existen y todas las cosas que se pueden simplificar o convertir en un meta patrón y luego comienzas desde ahí.

Muchas gracias, Sid. Sé que alguien hizo una pregunta justo al final. Desafortunadamente, no tenemos tiempo ahora mismo, pero si te diriges a la sala de preguntas y respuestas del orador o si estás en línea y estás tuiteando en línea, ve a la sala de preguntas y respuestas del orador en Discord y puedes hacerle una pregunta a Sid y él puede responderla. Demos una vez más un aplauso a Sid.