Diseño Opt-in – La Nueva Era de los Marcos de React

Muy bien, hola a todos. Espero que todos estén disfrutando de la conferencia. Lamentablemente me uno a ustedes virtualmente para esta ocasión, pero tengo una gran charla preparada, así que espero que podamos compensarlo. Mi nombre es Ben Holmes, y voy a hablar sobre el diseño opt-in, que audazmente estoy denominando una nueva era en el desarrollo web, nuevas tendencias que he notado. Así que para aclarar qué es el diseño opt-in, no es una charla de diseño de UI, aunque el diseño gráfico es claramente mi pasión. Tampoco es una charla de diseño de sistemas. No vamos a hablar sobre clusters de Kubernetes o algo así. Es una charla de diseño de API, así que aprender qué significa tener buenos valores predeterminados cuando estás construyendo una herramienta o estás usando un marco de elección y tanto encontrar como construir esas herramientas para que podamos construir las mejores aplicaciones para nuestros usuarios. Así que una pequeña introducción extendida, soy un mantenedor principal en Astro.build, así que he estado trabajando en código abierto durante un tiempo y me pagan por hacerlo, lo cual es muy raro. También soy el jefe de la pizarra en Astro también. Título no oficial, por supuesto, pero si alguna vez has visto algunos videos de una pizarra vertical en línea, hago mucho contenido educativo, podría haber sido yo y puedes encontrar un archivo justo allí. Y soy un defensor de los formatos de contenido. Así que Markdown, MDX, Markdoc, si alguna vez has usado alguno de esos, los amo y trabajo en mantener todos esos en el marco de Astro. Así que podrías verme en los foros de soporte. Así que para guiarte a través del viaje de construir una aplicación por primera vez y introducir qué es el diseño opt-in, voy a hablar sobre, ya sabes, un ejemplo clásico de cómo podrías haber construido una aplicación en la era 2015, 2016 con create React app. Ahí es donde comencé con los sistemas de componentes podría haber sido tu viaje de aprendizaje también. Así que cuando empiezas, lees esa publicación de blog de quien sea y estás construyendo tu hola mundo por primera vez. Y estás buscando herramientas como React y React dom. Estás usando un enrutador como React router y estás buscando alguna opción de CSS y JS como componentes de estilo. Así que puedes co-ubicar todo. Fue bastante agradable de usar como desarrollador, pero puedes ver nuestro pequeño medidor de kilobytes en la parte inferior va a empezar a subir. Definitivamente hay un costo base para usar estas herramientas. Luego quieres agregar más características a medida que tu aplicación se desarrolla un formulario de registro. Por ejemplo, en reacción, hay muchas bibliotecas de formularios que podrías usar aquí. Tal vez era para mech en los primeros días y vas a estar previniendo el comportamiento predeterminado del navegador. Así que puedes manejar todo con Java script, lo que por supuesto significa un paquete más grande Pero te quedas con esa experiencia de desarrollo que te dijeron, o estás probando, es una buena idea. Y luego avanza un poco más. Ahora tenemos un flujo completo de e-commerce, y queremos agregar una burbuja de carrito para decir cuántos artículos hay en tu carrito, como el número 2 o algo así. Y necesitas persistir eso en el almacenamiento, tal vez estás usando Redux para duplicar el estado del servidor dentro de tu cliente, así que no tienes que lidiar con flashes mientras está buscando cosas por primera vez, y estás usando almacenamiento en el lado del cliente, tal vez almacenamiento local o algo así. Nuevamente, vamos a subir nuestro medidor de JavaScript un poco más, porque a medida que agregamos nuevas características, todas tienen que ser replicadas en el paquete de React, en el flujo de React.

Y luego obtienes tu auditoría de performance cuando has alcanzado un cierto estado, y te preguntas por qué tienes un 39 en tu puntuación de Lighthouse. Y estabas siguiendo la publicación del blog. Estabas haciendo lo que la community decía que era una buena idea. Pero esa es la consecuencia de usar un SPA. Estás asumiendo toda esta reactivity, y podrías tener que retroceder y cavar a través de las herramientas de desarrollo de React para averiguar cómo puedes recuperar esas métricas de Lighthouse de nuevo. Y ese es el dolor de un sistema opt-out. Entonces, hablando de opt-out, ¿qué significa realmente? Bueno, en primer lugar, mirando la biblioteca Create React, el marco, lo que quieras llamarlo, tiene un camino feliz donde gestionan una gran configuración web para ti. Y si alguna vez necesitas modificar eso o empaquetar tu aplicación de una manera diferente, necesitas optar por no participar, que es usar el asiento de eyección, literalmente solo presionando un botón y gestionándolo todo tú mismo. Lo cual, por supuesto, es una cosa muy aterradora de hacer, por lo que muchas personas simplemente se quedan con Create React app y lo que te da, y evitan optar por no participar en ninguna de las opiniones. También tenemos componentes de estilo, donde el camino feliz es usar JavaScript primero para impulsar la experiencia. Función para impulsar variables en tu CSS, y puedes optar por no participar en cualquiera de los JavaScript del lado del cliente que se desplaza con tus estilos usando variables CSS o alternativas en su lugar. Y se siente como si estuvieras yendo contra la corriente, tienes que hacer un trabajo extra para obtener más performance, por lo que duele que tengas que estar informado sobre las preocupaciones antes de que puedas abordarlas. Y los paneles opt-out de React context. Este es el más fácil de entender, honestamente, donde estás almacenando el estado más arriba, lo cual es muy conveniente si estás almacenando el carrito en la parte superior de tu aplicación para que todos sepan cuántos artículos hay en el carrito. Pero va a ser muy costoso si ese carrito cambia alguna vez, porque como sabes, en cualquier lugar del árbol de React que dependa de ese estado va a volver a renderizar, por lo que necesitas optar por no participar con usememo en cualquier lugar de la aplicación que tenga cálculos intensos, lo cual no es una experiencia muy divertida. Eso, de nuevo, es la auditoría de performance. No es el camino feliz. Podemos resumir eso en un ethos opt-out. Asumes un objetivo, que es una aplicación altamente interactiva, y reduces la fricción del desarrollador para llegar allí, pero necesitas empaquetar la mejor caja de herramientas de antemano para llevarlos allí, ocultando la complejidad, y luego pidiendo a los desarrolladores que se ocupen del monstruo de la complejidad más tarde una vez que hacen esa auditoría de performance y tienen que averiguar qué podrían hacer de manera diferente. Quiero cambiar esa mentalidad con los frameworks más modernos que tenemos hoy. ASTRO es, por supuesto, mi ejemplo favorito, opinión imparcial como empleado. Es una gran manera de hacer un diseño opt-in. Comenzaremos con nuestro Hello World de nuevo. En este caso, no tienes que juntar un montón de herramientas. Puedes usar ASTRO y la plantilla estática para simplemente escribir el Hello World y mostrarlo al usuario. Cero kilobytes de JavaScript. Solo estás usando HTML y CSS para llegar allí. Luego añadimos esa complejidad, el formulario de registro, pero podemos ser un poco más inteligentes sobre cómo lo hacemos. Ahora que es una aplicación estática o quizás una aplicación impulsada por el servidor, podrías usar una simple solicitud POST a un endpoint. Tal vez prevenir el comportamiento predeterminado.

Quizás no. Depende de ti. Podrías usar una biblioteca ligera como Zod para validar en el cliente y obtener esa agradable experiencia donde estás escribiendo un correo electrónico no válido. Luego lo haces válido de nuevo y te da instantáneamente esa retroalimentación de que estás bien. Todavía quieres eso en tu paquete de JavaScript. Nadie necesita React para llegar allí. Solo aumentamos un poco nuestro JavaScript, pero aún obtenemos la misma experiencia.

Luego quieres agregar de nuevo tu burbuja de carrito. ¿Cuántos artículos hay en el carrito? Quizás quieras hacer esto de una manera impulsada por el cliente con el estado del cliente. Puedes optar por usar un marco del lado del cliente con Astro. Es una opción de CLI, Astro add React, que instalará las dependencias y agrupará React en las páginas que lo necesiten. Evitará React en las páginas que no lo necesiten. Luego puedes usar una opción más ligera, como nanostores, para almacenar ese estado global. No tienes que lidiar con tantas preocupaciones de re-renderizado. Eso aumentará el JS del lado del cliente solo al nivel de React y React-DOM, pero no está agregando nada innecesario encima de eso. Elegiste ese camino, y puedes recurrir a una herramienta como el CLI de Astro para llegar allí.

Tenemos una alternativa a eso. Si quisieras hacerlo una experiencia impulsada por el servidor, podrías optar por la representación del servidor en su lugar. Astro tiene una serie de adaptadores para esto. Astro add node configuraría tu aplicación para ser un servidor node, punto final por punto final. Puedes elegir qué páginas se pre-renderizan, y luego quizás usar almacenamiento de sesión y middleware para hacer un seguimiento del usuario. Eso reduce el JS del cliente, y te da aproximadamente la misma experiencia con algo más de estado del servidor para gestionar. Ahora, cuando llegas a la auditoría de performance, recuerdas por qué HTML se ejecuta en 3 mil millones de dispositivos. Estoy bromeando aquí, es una burla a Java. Pero sí, comenzar con HTML y progresar desde allí es una mejor idea que comenzar desde JavaScript y trabajar para volver a la representación del servidor. Es simplemente agradable comenzar con el servidor, porque eso es lo que va a calcular las cosas un poco más rápido y evitar cosas del lado del cliente. Así que ahora resumamos esto en algunos principios de diseño opt-in. Primero, quieres encontrar el denominador común más bajo de tu herramienta. También quieres facilitar la adición de complejidad, solo cuando se pretenda. Y quieres mantener al usuario primero con el diseño de la API, no al desarrollador primero.

Estos son tres principios que guiaron cómo se construyó Astro, y voy a profundizar en cada uno de estos. Entonces, el primero, encontrar el denominador común más bajo. ¿Cuál es el caso de uso más simple para la herramienta que estás utilizando? Para una aplicación Create React, el más simple es enviar algo de HTML sin ningún estado, eso es un hola mundo. Quieres ser inteligente y no tener un coche con ruedas opt-in, por ejemplo. No quieres un marco que no te ayude a hacer nada en absoluto, y tienes que agregar un complemento para renderizar HTML. Pero siempre que entiendas cuál es el caso de uso más pequeño para tu público objetivo, puedes llegar allí.

Además, quieres facilitar la adición de complejidad, solo cuando se pretende. No empieces con un fregadero de cocina como una aplicación Create React de la que tienes que expulsar. En cambio, quieres agregar interruptores realmente simples para optar por cosas que son más complejas, como el CLI de Astro, para agregar React cuando quieras agregar interactividad. Por último, quieres mantener al usuario como prioridad mientras estás construyendo una herramienta, o quieres elegir herramientas que pongan al usuario como prioridad. La experiencia del desarrollador importa, pero debe ser guiada por lo que es la experiencia del usuario una vez que se envía. Por lo tanto, quieres la línea de base de baja complejidad para la base de la experiencia, el LCD, y una opción es optar por re-renderizados, lo que significa menos ciclos de CPU, mejor rendimiento. Y el rendimiento no es la única métrica del usuario de la que puedes hablar. También puedes medir la seguridad de una aplicación, por ejemplo. Y tengo una pequeña bandera de Deno para mostrarte allí. Así que todo un mundo de ejemplos a los que puedo recurrir aquí para explicarlo. Deno, como mencioné, trae permisos opt-in. Cuando estás ejecutando una tarea CLI, puede que necesite llegar al mundo y acceder a cosas en tu sistema. Y no debería poder hacer eso a la ligera. Deberías poder decir, quiero permitir el acceso a la red. Quiero que leas desde mi sistema de archivos. Quiero que accedas a mis variables de entorno. Pero sin estas banderas, no se te permite hacer eso. Es una locura cuando registras el proceso punto env y nodo, y te das cuenta de cuánto tiene acceso. Sería bueno si pudiéramos hacer eso opt-in en su lugar. Entonces, ¿cómo aborda esto nuestros tres principios? Bueno, primero, este es el denominador común más bajo. Lo más simple que puedes construir con DNO es solo una herramienta CLI, tal vez un juego de aventuras de texto, sin ningún IO. Y luego puedes agregar complejidad con simples banderas que describen lo que se añade. Así que no hay armas de pie aquí. Y es centrado en el usuario.

Sabes, nos preocupamos por las vulnerabilidades de security, opt-in, siempre que se necesita abordar la security. Y el usuario entiende lo que se está permitiendo. Y también podemos hablar de componentes del servidor.

Sabes, es una novedad en React. También en Astro. Trae opt-in a JS del lado del cliente, que por supuesto no es un mal raíz ni nada. Es solo algo de lo que quieres ser consciente y solo recurrir cuando lo necesitas.

Entonces, en este ejemplo, tengo una plantilla de Astro. El HTML estático es el predeterminado. Y si quieres recurrir a la interactividad del lado del cliente, puedes importar un componente construido en cualquier marco, incluyendo React, tal vez Solid, tal vez Vue, tal vez Svelte. Y puedes optar por el JavaScript del lado del cliente usando una directiva de cliente. Esto está diciendo cargar JavaScript cuando el componente es visible en la página. Y de nuevo, el denominador común más bajo, página de inicio estática, es un buen predeterminado para tener. Añadida complejidad. Sí, la directiva del cliente es cómo optas por el JavaScript del lado del cliente, con control granular para cuando se carga el JavaScript, como cuando es visible. Y esto por supuesto es primero el usuario. Nos preocupamos por esos core web vitals. Sabemos que HTML es un buen punto de partida. Ahí es donde vamos a empezar cuando estés construyendo tu aplicación también. Y también trae opt-in al streaming.

Entonces, los componentes del servidor de React son un poco más picantes, tienen más cosas para la renderización del servidor de tu aplicación. Te darás cuenta en este ejemplo, tendremos una demostración de código en vivo para profundizar un poco más en esto. Pero sabes, comienza con HTML estático, como nuestro ejemplo de Astro, y también te permite transmitir información desde un servidor sin mucho JavaScript del lado del cliente para renderizarlo en la página. Entonces, en este ejemplo, tal vez tenemos un componente de Álbumes. Este componente de Álbumes extrae de una database, toma algunos álbumes y los muestra al usuario. Pero tal vez depende de una API de terceros que tarda tiempo. Sabes, no podemos acelerar este cliente de terceros, tarda un segundo en cargar, pero aún queremos mostrarle algo al usuario. Así que no es solo un spinner en su navegador durante uno o dos segundos que no pueden controlar. Así que cargamos nuestro componente de Álbumes, llamamos a esa API de terceros, y usamos React Suspense para mostrar un marcador de posición y transmitir la información cuando está disponible. Y no estamos haciendo esto con spinners de carga del lado del cliente y si no, estamos dejando que React lo maneje y Next.js es el marco en la parte superior que puede manejarlo por nosotros.

Entonces sí, esto asume el denominador más bajo, que es, de nuevo, renderizar todo en el servidor sin spinners, por lo que nuestro encabezado no va a estar dentro del spinner, podemos simplemente enviarlo de inmediato. Y es una complejidad aditiva. Por supuesto, transmitir es más complejo que no transmitir. Así que el predeterminado es no transmitirlo, simplemente bloquear y esperar a que se hagan todas las cosas del servidor. Y si quieres optar por los spinners, que pueden tener un desplazamiento de diseño, entiende el riesgo, puedes agregar un límite de suspense para decir qué fallback quieres mostrar mientras se resuelve el servidor. Y por supuesto, eso es primero el usuario, nos preocupamos por el desplazamiento del diseño, queremos evitar eso tanto como podamos. Pero cuando es necesario, cuando no podemos controlarlo, vamos a recurrir al suspense. Intentemos darte algún feedback de inmediato, simplemente se siente un poco más rápido.

Obviamente no puedo hacer esto en persona. Así que no puedo ver sus manos. Pero supongo que esto les ha sucedido en algún momento en su viaje con react, donde llaman a use effects, olvidan su array de dependencias. Y suceden cosas. No necesitan una auditoría de performance para saber que probablemente hay algo mal aquí. Y eso es debido al modelo de reactivity de React.

Así que voy a pasar por esto bastante rápido. Comparemos react y Solid aquí. Solid es un marco de trabajo declarativo de JavaScript con interfaces de usuario rápidas, control máximo sobre la reactivity. Es la nueva sensación. Es de fireship, el segundo mejor YouTuber que citó esto como el segundo mejor porque estoy en la plataforma. ¿De acuerdo?

Permítanme mostrarles un ejemplo de cómo podemos llevar el opt-in al nivel de componente, lo cual quizás no hayan visto antes. Tengo dos componentes aquí, uno construido en react, y otro construido en Solid, notarán que a primera vista. Parecen casi iguales, pero hay una diferencia sutil que he resaltado aquí. Entonces, estamos construyendo un carrito de compras, ¿verdad? Tenemos nuestra cantidad, que es cuántas cosas hay en el carrito. Tenemos nuestro precio, que se basa en cuántas cosas hay. Y luego tenemos algunas búsquedas en el servidor no relacionadas para resolver. Como obtener las imágenes del producto y obtener el texto de envío. Así que hay algunas cosas que muestran información sobre el producto. Y podemos escribir esto con JSX como se esperaría. Pero la parte interesante es esta dependencia que estamos dibujando aquí. El precio depende de la cantidad, por lo que necesita volver a calcularse cada vez que cambia la cantidad. Y si vemos cómo están escritos estos, React y Solid, tengo demos funcionando aquí mismo. Pueden ver que cuando hacen clic en el ejemplo de React, va a actualizar el precio cada vez que se actualiza la cantidad. Pero también va a volver a ejecutar las imágenes del producto y el texto de envío porque necesitan preocuparse por useEffect y useMemo y todas estas otras cosas para prevenir que otras cosas se recalculen detrás de escena, lo que podrían necesitar herramientas de desarrollo para incluso averiguar qué está pasando. Lo hice muy obvio aquí, pero puede que no sea tan obvio en su aplicación. Así que React asumió que quieres que todo se vuelva a renderizar. Ese es el modelo mental más simple, así que optaron por este enfoque aquí. Lo cual puede ser un poco aterrador. Es un poco peligroso. Ahora Solid toma el enfoque opuesto.

En lugar de volver a ejecutar todo el componente cada vez que cambia el estado, simplemente va a volver a ejecutar la parte de la página que se preocupa por ese estado. Solo va a volver a renderizar la cantidad cada vez que se actualiza la cantidad. Y no actualizará las imágenes del producto y el texto de envío, yay, pero ni siquiera actualizará el precio. Tienes que ser muy específico sobre qué partes de la página se vuelven a renderizar.

Entonces, en Solid, por ejemplo, si quieres declarar dependencias, como que el precio depende de la cantidad, puedes simplemente crear una función de ejecución. Y, el Compilador de Solid es lo suficientemente inteligente para decir, de acuerdo, esto es una función ahora, voy a rastrear las dependencias dentro de esta función, cantidad, y voy a volver a ejecutar esa función cada vez que una de esas dependencias cambie. Así que ni siquiera un array de dependencias, así que es simplemente inteligente. Ahora que hemos hecho esta función, podemos ver que Solid actualizará el precio. Pero a diferencia del problema de React, no vamos a recargar nada más que no dependa de la cantidad, porque de nuevo, optas por la reactividad con funciones. Así es como funciona todo el marco de trabajo, y es una primitiva realmente agradable. Y, veremos esto en ejemplos modernos como Svelte, y Vue, y Angular, todos ellos están basados en este modelo de donde el estado inicial se va a ejecutar una vez, y luego solo volvemos a ejecutar donde se usa el estado. Así que volvemos a ejecutar el elemento JSX aquí en lugar de volver a ejecutar tu función de arriba a abajo como lo harías en React. Pequeño truco genial, pequeño modelo mental genial.

Y Svelte hace lo mismo. Usando el operador del signo del dólar, y esto está cambiando en futuras versiones, aparentemente a un operador de estado, que volverá a ejecutar el precio cada vez que cambie la cantidad. El mismo tipo de bandera para decir, hey compilador, mira las dependencias, vuelve a renderizar estas cosas cada vez que esas dependencias cambien. Todos ellos funcionan más o menos así, y estamos convergiendo en un modelo de señales para gestionar esto.

Así que, por último, te dejaré con una pequeña demostración, parece que tengo unos dos minutos, pero yo ya sabes, correré esto, a ver hasta dónde podemos llegar. Está en un repositorio llamado simple-rsc. Así que si después de la charla, quieres probar esta herramienta, incluso contribuir con mejoras a ella, definitivamente lo agradezco. Pero es una referencia básica que te muestra cómo funcionan los Componentes de Servidor de React fuera de Next.js. Así que puedes entender el modelo mental de los Componentes de Servidor, lo que realmente hacen. Así que, tengo ese código aquí mismo, vamos a acercarnos un poco para todos ustedes. Y podemos ver que tenemos nuestra raíz del servidor, esta es solo una página que se está renderizando, no te preocupes demasiado por eso. Y simplemente estamos renderizando el texto estático, abramix. Construí esto con Dan Abramov en Stream. Es un clon de Spotify, así que Abramov, Abramix. Pensé que era gracioso, ¿vale? Pensé que era gracioso. Pero sí. Simplemente está renderizando este texto estático aquí.

Y si nos vamos a nuestro navegador, lo que voy a hacer aquí, podemos ver nuestro texto estático renderizado en la página. Y también un panel de desarrollo que muestra qué información se está enviando a Wire para mostrar esto. Así que en React, estos son mensajes de servidor muy truncados que le dicen a React, construye un H1 con el hijo abramix. Y no estamos enviando un componente al cliente para hacer esto, literalmente estamos transmitiendo en HTML tan pronto como esté disponible.

E incluso puedes renderizar eso desde el servidor de antemano, por lo que no tienes que esperar a que el stream del servidor baje. Y podemos complicarlo un poco más si queremos haciendo una obtención de datos del lado del servidor y viendo qué nos da. Así que tengo un componente de álbum aquí que obtiene datos de una base de datos ficticia y renderiza una pequeña caja de búsqueda con JavaScript del lado del cliente para buscar álbumes en esa lista para volver a obtener todo desde el servidor. Así que solo voy a pasar esta consulta aquí, no te preocupes demasiado por eso. Pero estamos simplemente renderizando un componente de álbumes en la página que va a hacer toda nuestra obtención de datos del servidor y si volvemos, oh eso es el Spotify real, si volvemos a nuestro navegador podemos ver todo eso entrando en vista.

Así que puedes ver que está bloqueando. Ahora estamos esperando un buen segundo para que la base de datos se cargue y para que todo esté disponible porque ese es el comportamiento por defecto en React. Simplemente bloquea todo para que no haya desplazamiento de diseño y podemos mostrarte esa información. Y transmitirá solo la información sobre los álbumes que necesitamos en la página. Esto es un poco como un moderno GraphQL si lo piensas bien, donde no tienes que ser inteligente sobre qué datos estás codificando como JSON. Simplemente va a enviar HTML. Entonces, siempre que seas inteligente sobre la obtención de datos de una base de datos, renderizando lo que necesitas, no tienes que preocuparte por enviar cosas que no necesitas. Va a transmitir exactamente lo que es necesario para la página. Y si decidimos, sabes qué, esa espera de un segundo es un poco larga, realmente no quiero esperar por eso, podemos agregar un límite de suspense aquí para desbloquear nuestro encabezado. Para mostrar el encabezado de inmediato, y luego mostrar un pequeño marcador de posición mientras los álbumes se están cargando en vista. Así que podemos ver eso, y refrescaré varias veces para mostrarte lo que está pasando. Podemos ver que Abramix se transmite desde el servidor de inmediato. Luego mostramos nuestro spinner de carga mientras la base de datos se carga, y luego el servidor transmite el resto de la información un poco más tarde. Y React es lo suficientemente inteligente para resolver eso en la página en función de cómo estructuras tu árbol de componentes. Genial, pequeño truco. Definitivamente emocionado por el futuro de React, y simplemente haciendo que todo sea impulsado por el servidor, pero manteniéndolo en JSX. Es algo que Astro ha estado haciendo durante un tiempo, y creo que React lo está codificando de una manera muy agradable. Bueno, eso es lo que quería dejarles. Consulta la demostración si quieres. Y si quieres, ya sabes, mostrar tu apoyo a Astro y otros marcos opt-in, puedes unirte al Discord de Astro, astro.build slash chat, y puedes encontrarme en todas partes en bhomestev si por alguna razón disfrutas de mi estilo de enseñanza. Está bien. Muchas gracias, y disfruta el resto de la masterclass.