Video Summary and Transcription
Siddharth analiza el diseño de buenas API de componentes, centrándose en interfaces de usuario intuitivas, accesibles y consistentes. Demuestra la creación de varios componentes, como el menú de acciones, el botón de menú, la lista de navegación y el grupo de navegación. Siddharth también aborda desafíos como la representación en el servidor, la configuración de valores predeterminados y la optimización de la representación de componentes. Enfatiza el uso aceptable de trucos de código dentro de límites razonables y la importancia de considerar la legibilidad del código. Además, destaca el papel de la retroalimentación de los desarrolladores en la conformación de los sistemas de diseño.
1. Introducción a las buenas API de componentes
Soy Siddharth y trabajo en el equipo de diseño de ingeniería en GitHub. Voy a hablarles sobre algunos crímenes de código que cometemos para crear buenas API de componentes. ¿Qué hace que una interfaz de usuario sea buena? Debe ser intuitiva, accesible y consistente. Trabajo en el lado de React, en esta biblioteca de componentes que usamos para construir otras páginas en GitHub. ¿Qué hace que una interfaz de API de componente sea buena? Debe ser intuitiva, accesible y consistente. Veamos algunos crímenes. Tengo este componente llamado AnchoredOverlay, que abre una superposición anclada a un botón. Es una API simple. Ahora, el lugar donde podríamos usar este componente es en una página de solicitud de extracción de GitHub.
Voy a hablarles sobre algunos crímenes de código que cometemos para crear buenas API de componentes. Antes de llegar allí, déjenme preguntarles, ¿qué hace que una interfaz de usuario sea buena? Las palabras que escucho con frecuencia son que debe ser intuitiva, debe ser accesible, y debe ser consistente. Si sabes cómo usar una parte de la aplicación, puedes adivinar cómo usar otra parte, porque todo es consistente.
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í.
2. Construyendo el Componente del Menú de Acción
Puedes asignar etiquetas y asignados a una solicitud de extracción usando AnchoredOverlay. La API de AnchoredOverlay no es ideal, así que crearía un nuevo componente llamado menú de acción. Este componente manejaría la apertura del menú por defecto al hacer clic y pasaría automáticamente las props necesarias. El botón por defecto para el menú de acción tendría los íconos de triángulo y zanahoria. Además, crearía un componente de superposición para adaptar el contenido del menú. La implementación del menú de acción es sencilla, ya que simplemente renderiza sus hijos.
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
3. Construyendo el Componente del Botón de Menú
El componente del botón de menú renderiza el botón con un icono de cierre predeterminado. La personalización es posible mediante la asignación de props. Los componentes en React pueden estar conectados entre sí, lo que permite llamadas de función convenientes. La superposición del menú utiliza el componente de superposición anclado, gestionando el estado internamente. Para pasar props a la superposición, subimos el ancla al componente padre y creamos un contexto. Esta abstracción del estado al padre y su paso a los hermanos es un patrón común en React. La superposición del menú renderiza tanto el botón como la superposición.
aburrido. Simplemente renderiza a sus hijos. No hay nada especial que haga. El botón de menú es más interesante. Es un componente que renderiza el botón, y puedes ver que ya estamos incluyendo el icono de cierre predeterminado, que es el icono de cierre por defecto. Pero también pasamos props. Así que si quieres personalizar el icono de cierre y poner este icono de engranaje, puedes hacerlo. Y la forma en que creamos esta API o menú de acciones y botón de menú de acciones es un poco tonta, pero cada componente en React es una función, como si llamara a una función, y cada función en JavaScript también es un objeto, lo que significa que puedes hacer cosas como adjuntar un componente a otro. Así que puedes decir que el botón del menú de acciones es en realidad el botón de menú. Entonces, cuando renderizas esto y dices botón del menú de acciones, en realidad estás llamando a esta función. Es genial. Y luego tienes una superposición de menú donde usamos la superposición anclada, el componente que mostré primero, y aún usa la superposición anclada internamente, que gestiona todo el estado, pero cuando creas este menú, no tienes que preocuparte realmente por todo eso.
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.
4. Renderización en el Servidor y Configuración del Ancla
Al renderizar en el servidor, puede haber un retraso en la configuración del estado del ancla, lo que provoca una brecha en la renderización. Para solucionar esto, podemos usar la API de nivel superior de React, react.children, para inspeccionar las propiedades del hijo. Al comparar el tipo de hijo, podemos configurar el ancla y pasar props adicionales a la superposición del menú. Esto permite que el botón se renderice antes, incluso en redes lentas. Si bien este enfoque es un truco, ayuda a crear un buen componente al abstraer el trabajo innecesario.
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.
5. Hacks de Código Aceptables
A veces, los trucos que hacen que el código sea más fácil de leer y ayudan a los desarrolladores a trabajar de manera más eficiente dentro de límites razonables son aceptables. En el caso del componente del menú de acciones, se requiere el uso de componentes específicos de la misma biblioteca. Sin embargo, esto puede no ser aplicable a bibliotecas de código abierto como material o chakra.
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.
6. Construyendo el Componente de Lista de Navegación
Tenemos un componente llamado nav list o lista de navegación que permite renderizar elementos con iconos. El estado seleccionado se muestra utilizando la propiedad aria-current, promoviendo el uso de propiedades accesibles. Para agrupar elementos similares, creamos el componente navlist.group, que admite listas de navegación anidadas. El elemento seleccionado actual se determina leyendo aria-current de la lista. Si un elemento forma parte de un grupo, el grupo está abierto de forma predeterminada.
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.
7. Construyendo el Componente de Grupo de Navegación
El grupo necesita saber si uno de sus elementos es el valor actual. El valor predeterminado del grupo de navegación se puede establecer en verdadero si tiene un elemento con ARIA actual. Pedir al desarrollador que establezca el valor predeterminado puede ser redundante y no ideal. Un componente inteligente puede establecer automáticamente el valor predeterminado verificando los hijos para ARIA Aparente.
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.
8. Estableciendo el Valor Predeterminado para el Grupo de NavList
Pero recuerda que dije que las aplicaciones que generan código son aceptables dentro de los límites razonables del sistema. ¿Puede el grupo NavList asumir que tendrá este elemento y poder seleccionar ARIA Aparente es donde encontramos problemas. No podemos asumir hijos, así que la respuesta es Grandioso. Usamos CreatorRef y QuerySelector para ARIA actual para establecer el valor predeterminado. Es un poco antipatrón, pero ¿es un crimen de código? Creo que no debería ser parte de ello. Entonces, está bien. Este crimen se siente bien.
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.
9. Optimización de la Representación de Componentes
Si está en el lado del cliente, entonces está bien. Pero si están utilizando SSR, entonces 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. Pero si está en una conexión 3G lenta, no debería funcionar. Entonces, si está en una conexión 3G lenta, se abrirá después de mucho tiempo, ¿verdad? Es posible que ya estés viendo alguna otra configuración y de repente se abre y te distrae. 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.
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.
Impactos de los Hacks en la Legibilidad del Código
A veces los hacks hacen el trabajo. Con la forma en que el equipo de React se compromete a respaldar la compatibilidad con versiones anteriores, no pueden romper las API de nivel superior. Cuando se trata de hacks, es importante considerar el impacto en la legibilidad del código a largo plazo. Si React no tiene una solución de nivel superior, es mejor poner el código en una biblioteca reutilizable y escribir pruebas para ello.
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.
Complejidad y Retroalimentación en los Sistemas de Diseño
Es importante encontrar dónde colocar la complejidad y mantenerla con confianza. La retroalimentación de los desarrolladores que utilizan GitHub ayuda a identificar patrones para el sistema de diseño. La primera etapa es el inventario, observando las cosas existentes y simplificándolas en meta patrones.
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.
Comments