Descubre si tu sistema de diseño es mejor que nada

Rate this content
Bookmark

Construir un sistema de diseño no es suficiente. Tu equipo de desarrollo debe preferirlo sobre los componentes individuales y las bibliotecas de terceros. De lo contrario, todo el esfuerzo es una pérdida de tiempo. Aprende cómo utilizar el análisis de código estático para medir si tu sistema de diseño supera a la competencia interna y formas basadas en datos para mejorar tu posición.

20 min
21 Jun, 2022

Comments

Sign in or register to post your comment.

Video Summary and Transcription

Construir un sistema de diseño sin adopción es una pérdida de tiempo. La adopción de Grafana UI está creciendo de manera constante con el tiempo. Los factores que afectan la adopción del sistema de diseño incluyen el cambio en la mezcla de fuentes, la sustitución de los componentes de Homebrew por Grafana UI y las limitaciones del estado actual de Grafana UI. Medir la adopción es importante para determinar el éxito de un sistema de diseño. El análisis del código a través de herramientas de análisis de código estático es valioso para detectar y rastrear el uso de componentes.

Available in English

1. Measuring Design System Adoption with Grafana UI

Short description:

Un sistema de diseño no tiene valor si no se utiliza. Construir un sistema de diseño sin obtener una adopción suficiente es una pérdida de tiempo y esfuerzo. En esta charla, te contaré cómo medir la adopción de un sistema de diseño. Grafana es una plataforma de monitoreo de DevOps con un sistema de diseño llamado Grafana UI. Veamos qué tan bien le está yendo a Grafana UI. La línea va en aumento. El número de usos crece constantemente con el tiempo. La razón por la que no lo sabes es la competencia.

Un sistema de diseño no tiene valor si no se utiliza. Un sistema de diseño es una herramienta, no es suficiente con solo existir. Debe ser utilizado activamente para mejorar el producto o ayudar a entregarlo más rápido. Esa es la única forma en que un sistema de diseño puede ser valioso. Construir un sistema de diseño sin obtener una adopción suficiente es una pérdida de tiempo y esfuerzo.

Mi nombre es Arseniy, soy un Arquitecto de Soluciones en Rangel Amsterdam. En esta charla, te contaré cómo medir la adopción de un sistema de diseño basado en una métrica que establecí recientemente para uno de nuestros clientes. La conversación sobre métricas requiere datos. Desafortunadamente, no es posible mostrar datos de un cliente corporativo, así que encontré un sustituto de código abierto. Usaré Grafana como ejemplo. Si no lo sabes, Grafana es una plataforma de monitoreo de DevOps. Es un proyecto antiguo y grande. Fue reescrito de Angular a React a partir de 2018. Tiene un ecosistema de complementos y, lo más importante, para el stock, Grafana tiene un sistema de diseño. Se llama Grafana UI. En su introducción de Storybook, dicen que lo construyeron para tener un ciclo de desarrollo más corto y una experiencia de usuario consistente. Estos objetivos están en línea con lo que esperarías encontrar en un sistema de diseño corporativo. Quiero que mis productos se parezcan a mis productos y quiero construirlos más rápido.

Veamos qué tan bien le está yendo a Grafana UI. En este gráfico, estamos rastreando cómo evolucionó un proyecto y su ecosistema y cómo adoptaron un sistema de diseño. La escala de tiempo horizontal es de cinco años. Las mediciones se toman en intervalos semanales. El número vertical representa los usos de los componentes de Grafana UI. Un uso ocurre cuando un componente se menciona en el código. Discutiremos más adelante qué significa esto, pero de manera simplificada, ocurre cuando mencionas un componente en una etiqueta JSX. Para tener una idea de la escala, la semana pasada en el extremo derecho del gráfico, los componentes de Grafana UI se utilizaron más de 7,000 veces en Grafana en sí y en 290 de sus bases de código de complementos.

¿Qué imagen te muestra este gráfico? La línea va en aumento. El número de usos crece constantemente con el tiempo. ¿Esto es bueno para el sistema de diseño? ¿Significa esto que el sistema de diseño está siendo adoptado continuamente? La respuesta es que no lo sabes. La razón por la que no lo sabes es la competencia.

2. El Rol del Sistema de Diseño y los Componentes Homebrew

Short description:

Los desarrolladores tienen la opción de cómo construir las cosas, ya sea utilizando bibliotecas de terceros, construyendo sus propios componentes o utilizando un sistema de diseño como Grafana UI. También es importante considerar los componentes Homebrew, que son componentes de bajo nivel implementados directamente en el código del producto. Al analizar el gráfico, podemos ver que tanto el sistema de diseño como los componentes Homebrew están creciendo, lo que indica un proyecto y un ecosistema saludables.

Soy un ingeniero. Puedo usar un sistema de diseño. Puedo usar bibliotecas de terceros o puedo construir mis propios componentes. Los desarrolladores tienen la opción de cómo construir las cosas. Esto es especialmente cierto para los complementos de código abierto en este análisis. Si construyo un complemento y lo alojo en mi propia cuenta de GitHub, ¿quién puede obligarme a usar Grafana UI? La única opción para afectar mi elección es crear un buen sistema de diseño y hacer que sea fácil de usar.

Incluso si tu producto no utiliza bibliotecas de terceros, en cualquier proyecto habrá componentes Homebrew. Homebrew son los componentes de bajo nivel implementados directamente en el código del producto. Si construyes tu propio botón, eso es Homebrew. Es muy importante centrarse en los componentes de bajo nivel. No estamos buscando encontrar cada posible uso de componente. Estamos buscando la competencia. El Componente Online 2 no es Homebrew porque es compositivo, solo utiliza otros componentes. Los componentes compositivos se esperan en cualquier base de código y no compiten con el sistema de diseño. Por otro lado, el Componente Online 1 es Homebrew, utiliza una etiqueta JSX en minúsculas en lugar de una en mayúsculas. De esta manera, sabemos que se trata de un marcado sin procesar. Debido a que se trata de un marcado sin procesar, lo contamos como Homebrew.

Ahora que sabemos lo que estamos viendo, agreguemos Homebrew al gráfico. Este es el mismo gráfico que antes. Mismo eje, mismos datos, excepto que ahora se agregan los usos de Homebrew. Quiero señalar la escala una vez más. Estamos viendo un total combinado de 11,000 usos de componentes en el borde derecho del gráfico, en 291 repositorios. El área sombreada total es casi un millón de usos, aunque no son únicos ya que estamos rastreando el código a lo largo del tiempo. ¿Qué puedes ver en este gráfico? El área gris en la parte superior, que representa Homebrew, comienza antes que el área roja, que representa Grafana UI. Al principio, no había Grafana UI. Ambas líneas están creciendo. Mientras el sistema de diseño de usuario está creciendo, también lo hace Homebrew. El hecho de que las dos líneas estén creciendo significa que el proyecto y el ecosistema están creciendo. Parecen saludables. Las formas se ven bastante similares, en particular, durante el último año.

3. Factores de Adopción del Sistema de Diseño

Short description:

Las irregularidades en las líneas indican cambios en el uso de componentes. La forma de las líneas no siempre se refleja entre sí, lo que sugiere un cambio en la combinación de fuentes de componentes. Al analizar el cambio en la combinación de fuentes a lo largo del tiempo, podemos comprender los factores que afectan el crecimiento del sistema de diseño. El gráfico muestra la proporción de uso de componentes Homebrew y Grafana UI, lo que indica el desplazamiento de los componentes Homebrew por Grafana UI. Los desarrolladores están optando cada vez más por utilizar Grafana UI en lugar de Homebrew. El gráfico también revela la ausencia inicial de Grafana UI, un salto significativo cuando los componentes existentes se incorporaron a él, y una desaceleración reciente en el desplazamiento debido a las limitaciones del estado actual de Grafana UI.

Las irregularidades en estas líneas son características de cada cambio importante, cada conjunto de cambios agrega una irregularidad o una disminución en la línea, porque significa que los componentes se utilizan más o se eliminan de la base de código. Pero observa que las formas no siempre se reflejan entre sí. Especialmente alrededor del punto 721. Si las líneas no son similares, significa que la combinación de fuentes de componentes está cambiando.

Imagina que tienes dos cubetas, Homebrew y Grafana UI. Tomas componentes de ambas cubetas y los compones para crear tu funcionalidad. Las cubetas son tus fuentes. Cuánto tomas de las cubetas es tu combinación de fuentes. Un cambio en la combinación de fuentes significa que estás tomando más o menos de una de las cubetas de lo que hacías antes. Podemos inferir a partir de este gráfico los dos conjuntos de factores que afectan el crecimiento del sistema de diseño. Cómo crece el proyecto y cómo se está desempeñando el propio sistema de diseño.

Para aislar la adopción del sistema de diseño del crecimiento del proyecto y otros factores, debemos analizar cómo cambia la combinación de fuentes a lo largo del tiempo. Y esto, en mi opinión, es el gráfico más importante para un sistema de diseño. Muestra el cambio en la combinación de fuentes a lo largo del tiempo. Es una proporción de uso de componentes Homebrew y Grafana UI. El tamaño de una base de código no es fijo. Crece y a veces disminuye con el tiempo, pero cada funcionalidad tiene oportunidades limitadas para utilizar los componentes. De un conjunto de componentes competidores que hacen probablemente lo mismo, solo vas a usar uno en cada caso. Esto significa que la elección de la fuente del componente es un juego de suma cero. Si utilizas un sistema de diseño, no estás utilizando Homebrew y viceversa. Por lo tanto, el gráfico que estás viendo muestra el desplazamiento. Representa a Grafana UI tomando las decisiones que los desarrolladores hacen al construir cosas. Cada vez más, los desarrolladores eligen utilizar los componentes de Grafana UI en lugar de Homebrew.

Algunas cosas que puedes notar en este gráfico. Al principio, solo existía Homebrew, Grafana UI aún no existía. Luego, ves un salto drástico cuando los componentes existentes se incorporan a Grafana UI por primera vez. El proyecto aún era pequeño en ese momento, por lo que esto crea un gran cambio en la proporción. Cuando ves un período de crecimiento durante un par de años, y durante el último año, el desplazamiento casi se detuvo. Grafana UI alcanzó el límite de lo que las personas pueden hacer con él en su estado actual. La simetría de las dos líneas que has visto en el gráfico anterior es casi perfecta durante el último año porque la combinación de fuentes no ha cambiado.

4. Medición de la Adopción del Sistema de Diseño

Short description:

Grafana UI alcanzó un estado en el que cada nueva característica utiliza la misma combinación de un sistema de diseño y componentes Homebrew. El gráfico muestra la preferencia del equipo por el sistema de diseño sobre la competencia. También tiene en cuenta la disponibilidad. Si tu sistema de diseño no logra desplazar a la competencia, la participación que obtiene en el uso de componentes disminuirá con el tiempo. Si el sistema de diseño tiene éxito en desplazar a la competencia, eso es cómo sabes que está funcionando bien. Subir es bueno. Bajar es malo. ¿Cuál es un nivel lateral apropiado? Para un sistema de diseño de propósito general, idealmente deberías alcanzar un nivel en el que no haya otros componentes Homebrew excepto los snowflakes. Si solo tienes snowflakes entre los componentes Homebrew, estás haciendo un trabajo fantástico.

Grafana UI alcanzó un estado en el que cada nueva característica utiliza la misma combinación de un sistema de diseño y componentes Homebrew, incluso si los componentes en sí son diferentes. ¿Por qué este gráfico es mucho mejor que los anteriores? La combinación de fuentes es independiente del crecimiento del proyecto, el tamaño del equipo, el nivel de inversión, etc. Si duplicas el tamaño del equipo mañana, el gráfico sigue siendo válido. Elimina cualquier volatilidad debido a las características, los únicos cambios son la combinación de fuentes, nada más.

Básicamente, muestra la preferencia del equipo por el sistema de diseño sobre la competencia. Curiosamente, también tiene en cuenta la disponibilidad. Si quiero usar un componente del sistema de diseño, pero no lo encuentro, es más probable que use Homebrew. Para un negocio o un producto, puedes mirar la cuota de mercado. Este gráfico es la cuota de mercado del sistema de diseño dentro del proyecto.

¿Es tu sistema de diseño mejor que nada? Si no haces nada, si no construyes un sistema de diseño en absoluto, el producto seguirá existiendo. Las características seguirán siendo construidas utilizando otros componentes. Si tu sistema de diseño no logra desplazar a la competencia, la participación que obtiene en el uso de componentes disminuirá con el tiempo desde las posiciones iniciales. De esa manera, el proyecto crece más rápido de lo que el sistema de diseño se adopta y las características no lo utilizan mucho. Si el sistema de diseño tiene éxito en desplazar a la competencia, eso es cómo sabes que está funcionando bien. Lo que nos lleva a la propiedad básica de esta métrica. Subir es bueno. Bajar es malo. Si el gráfico baja durante un tiempo, algo está mal. Si el gráfico sube, sigue haciendo lo que estás haciendo. Aunque no puede subir para siempre. No importa lo que diga el entrenador, no puedes dar más del 100%. Incluso si haces todo absolutamente bien, la línea se mantendrá lateral en algún momento.

¿Cuál es un nivel lateral apropiado? Para un sistema de diseño de propósito general, idealmente deberías alcanzar un nivel en el que no haya otros componentes Homebrew excepto los snowflakes. Los snowflakes son esos componentes Homebrew verdaderamente únicos y exclusivos. Imagina que estás construyendo una página de destino para una campaña publicitaria de un millón de dólares. Está bien tener un montón de componentes únicos específicamente para esa situación. Tener snowflakes en el proyecto está bien y probablemente inevitable. Si solo tienes snowflakes entre los componentes Homebrew, estás haciendo un trabajo fantástico. Es posible que no alcances ese nivel. Si solo hiciste lo básico, no esperes que la línea suba demasiado alto.

5. Factores que afectan la adopción del sistema de diseño

Short description:

Si tu base de código tiene demasiado legado, la línea no subirá rápidamente. El nivel de adopción depende de los objetivos y casos de uso específicos. El sistema de diseño requiere gobernanza y colaboración en toda la organización. La falta de adopción puede ocurrir en cualquier punto del proceso de toma de decisiones. Este análisis es valioso y debe formar parte del proceso de gobernanza. Las computadoras pueden leer código a través del análisis estático de código. Las herramientas que leen código programáticamente se utilizan comúnmente.

Si tu base de código tiene demasiado legado, no esperes que la línea suba demasiado rápido porque refactorizar el legado es lento, por lo que desplazar el legado también es lento. Y el nivel que alcanzas depende de los objetivos. Si te enfocas en un caso de uso específico, por ejemplo, obtener imágenes de productos perfectas para el e-commerce, está bien no obtener demasiada adopción en relación con todo el código personalizado en el proyecto.

Si tienes un enfoque específico, debes ajustar tu definición de la competencia para obtener una métrica significativa. Recuerda que hasta ahora, la definición de código personalizado era cualquier componente que renderiza código sin formato. La participación del usuario es una métrica basada en el código. Si no alcanza el nivel deseado, es posible que te tientes a culpar a esos molestos desarrolladores por entrometerse en el éxito de la adopción. Eso no es correcto. El sistema de diseño requiere gobernanza para decidir qué se incluye y qué no. Requiere mucha colaboración entre diferentes personas en toda la organización: diseñadores, desarrolladores y propietarios de productos. La falta de adopción puede deberse a cualquier punto en el proceso de toma de decisiones. Si a un diseñador no le gusta el sistema, no lo incorporará en los diseños, por lo que el desarrollador tampoco lo usará. Esta medición se encuentra al final del proceso de desarrollo y se ve afectada por todas las decisiones involucradas en él.

Sin embargo, el análisis sigue siendo válido porque, al final, el producto de software es código y el sistema de diseño se envía como parte de él. Para que este análisis sea útil, debe formar parte de tu proceso de gobernanza y, para eso, debe ser económico y repetible. Deberías poder ejecutarlo en cada sprint para ver cómo cambian las cosas, reaccionar y planificar el trabajo futuro. Afortunadamente, podemos automatizarlo. Aquí tienes un famoso ejemplo de palabras sin sentido. Si te pido que me digas de qué trata la declaración, deberías poder decir que se trata de ideas haciendo algo. Deberías poder encontrar el sujeto. Observa que la frase está diseñada para no tener sentido, sin embargo, podemos hacer algunos juicios sobre ella basados puramente en la sintaxis.

¡Sorpresa! Las computadoras pueden leer código. En términos prácticos, esto significa que el código es formal. Tiene una sintaxis estricta. Tiene que ser formal para que las máquinas lo ejecuten. Podemos enseñar a una computadora a leer código y encontrar patrones en las declaraciones estructuradas. Esto se llama análisis estático de código. Al igual que con el sinsentido de Chomsky, no tenemos que ejecutar el código para averiguar qué está haciendo. Es suficiente con mirar el código. Es probable que ya estés utilizando herramientas que leen el código programáticamente.

6. Detectando Componentes y Usos de Homebrew

Short description:

Tu linter realiza un análisis estático para encontrar problemas sin tener que entender qué hace tu código. Para detectar un componente Homebrew, buscaremos funciones con etiquetas JSX en minúsculas. El código que ves también crea un componente React. Prometí antes decirte qué es un uso. La etiqueta online2 hace referencia a un identificador de botón definido en la línea 1. JavaScript generalmente no es tan simple como eso. El uso indirecto como este sigue siendo un uso de un botón. Toma dos archivos, uno donde exportas el botón y otro donde lo importas.

Tu linter realiza un análisis estático para encontrar problemas sin tener que entender qué hace tu código. Echemos un vistazo a la sintaxis de un componente. Ya hemos visto este código antes. ¿Cómo sabemos exactamente que homebrew es realmente un componente Homebrew? Un componente React es una función que devuelve JSX o una clase con una función de renderizado si eres de la vieja escuela. Tanto Homebrew como no Homebrew son componentes. Ambos son funciones que devuelven JSX.

Además, Homebrew menciona una etiqueta en minúsculas. Repitamos. Para detectar un componente Homebrew, buscaremos funciones. En las funciones, buscamos etiquetas JSX en minúsculas. Si la función contiene una etiqueta en minúsculas, es un componente Homebrew. Lo mismo ocurre con las clases. Al realizar este análisis, asumimos que el código es válido porque debe ser correcto para ser enviado a producción. Si estás enviando código no válido a producción, tienes problemas más grandes y no puedo ayudarte.

Además, asumimos que el código es coherente. Es realmente difícil escribir un programa que analice todo el Javascript posible. El código que ves también crea un componente React. No creo que sea razonable intentar analizar código como este porque este código no es coherente. Afortunadamente, los humanos tampoco suelen poder leer bien el código como este. Si alguien de tu equipo está enviando esto a producción tienes problemas más grandes y no puedo ayudarte. Prometí antes decirte qué es un uso. La etiqueta online2 hace referencia a un identificador de botón definido en la línea 1. Esa referencia es un uso de un componente de botón. JavaScript generalmente no es tan simple como eso. Así que las cosas pueden complicarse un poco. El uso indirecto como este sigue siendo un uso de un botón. Hemos tomado un botón, lo hemos asignado a otra variable y hemos hecho referencia a esa variable. Esto aún cuenta. Toma dos archivos, uno donde exportas el botón y otro donde lo importas. Hay varias formas de importar, incluyendo alias, espacios de nombres y reexportaciones.

7. Importando y Rastreando el Uso de Componentes

Short description:

Importar y rastrear el uso de componentes es esencial. El uso se puede determinar en función de las exportaciones de paquetes y el uso posterior. Los componentes de orden superior también pueden afectar el recuento de uso. El uso en el código no está bien definido y depende de la sintaxis. La herramienta utilizada para el rastreo se llama Radius Tracker. Para calcular la métrica, encuentra componentes Homebrew, importaciones del sistema de diseño y recopila los usos. Ajusta los pesos según la complejidad del componente para obtener un gráfico significativo. Construye lo que sea valioso para tu equipo y mide el porcentaje de participación de uso. La herramienta de código abierto Radius Tracker de Wrangle puede ayudar con el análisis.

La importación es extremadamente común y tenemos que llevar un registro de ella. El uso del botón en la línea 6 debería contar. Observa que es posible rastrear el uso de un botón a partir de la importación en la línea 5. No necesitamos saber qué es el botón, solo si el paquete exporta algo llamado botón y luego se utiliza ese algo. De esta manera podemos rastrear los usos de un sistema de design importado como un paquete.

Tienes un botón, lo colocas en el objeto y lo expandes en props. Ahora has pasado el botón como una render prop. Aún es un uso de un botón. No sabemos qué sucede con el botón dentro del componente pero sabemos que es probable que se use el botón. Otro caso de uso común son los componentes de orden superior. Observa que el botón se utiliza no cuando se crea el componente de orden superior en la línea 5 sino cuando se utiliza en las líneas 6 y 7. Cada vez que se utiliza el componente de orden superior, también se utiliza el componente de botón original. Este código cuenta como dos usos del botón.

La razón por la que estoy revisando estos casos además de presumir la sofisticación de mi herramienta de rastreo es señalar que el uso en el código no es un concepto bien definido. Para la máquina, el uso solo existe en runtime. No estamos analizando código muerto. No estamos determinando con qué frecuencia algo se renderiza para un usuario en el navegador. Si estamos analizando el código estático, tenemos que definir qué significa el uso basándonos puramente en la sintaxis. Dadas todas las formas en que se puede escribir JavaScript esa definición depende de lo que consideres como uso. Mi definición está implementada en la herramienta que estoy utilizando para recopilar los data. Se llama Radius Tracker. Te daré un enlace al final.

Ahora que sabes cómo detectar componentes Homebrew y encontrar usos aquí tienes cómo calcular la métrica. Encuentra componentes Homebrew. Encuentra importaciones del sistema de design. Recopila los usos de ambos. Calcula la proporción de mezcla de fuentes. Y repite para confirmaciones históricas. He utilizado el botón como ejemplo en esta charla hasta ahora. Pero no todos los componentes son iguales. Si comparas un botón abstracto y un selector de fechas probablemente descubrirás que cada uso de un selector de fechas vale mucho más que el uso de un botón porque el selector de fechas es un componente más grande y complicado. Para obtener un gráfico más significativo, debes descontar los componentes más simples. Esto significa ajustar los pesos según la complejidad del componente. Los gráficos que has visto anteriormente tratan todos los componentes de la misma manera. Para el cliente que mencioné al principio ignoramos todos los usos de componentes como box o typography porque no son valiosos aunque estén significativamente sobrerrepresentados en la base de código. Si tomas algo de esta charla construye lo que sea valioso para tu equipo y luego mide el porcentaje de participación de uso para ver cuánto prefieren las personas lo que estás haciendo en comparación con la competencia interna. Para ejecutar este análisis tú mismo obtén el rastreador de radio que escribimos en Wrangle es de código abierto y te sugiero que lo revises. Pídeme consejo y ponte en contacto con Wrangle para obtener ayuda práctica. Gracias.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Advanced Conference 2021React Advanced Conference 2021
47 min
Design Systems: Walking the Line Between Flexibility and Consistency
Top Content
Design systems aim to bring consistency to a brand's design and make the UI development productive. Component libraries with well-thought API can make this a breeze. But, sometimes an API choice can accidentally overstep and slow the team down! There's a balance there... somewhere. Let's explore some of the problems and possible creative solutions.
TechLead Conference 2023TechLead Conference 2023
35 min
A Framework for Managing Technical Debt
Let’s face it: technical debt is inevitable and rewriting your code every 6 months is not an option. Refactoring is a complex topic that doesn't have a one-size-fits-all solution. Frontend applications are particularly sensitive because of frequent requirements and user flows changes. New abstractions, updated patterns and cleaning up those old functions - it all sounds great on paper, but it often fails in practice: todos accumulate, tickets end up rotting in the backlog and legacy code crops up in every corner of your codebase. So a process of continuous refactoring is the only weapon you have against tech debt.In the past three years, I’ve been exploring different strategies and processes for refactoring code. In this talk I will describe the key components of a framework for tackling refactoring and I will share some of the learnings accumulated along the way. Hopefully, this will help you in your quest of improving the code quality of your codebases.

React Summit 2023React Summit 2023
24 min
Debugging JS
As developers, we spend much of our time debugging apps - often code we didn't even write. Sadly, few developers have ever been taught how to approach debugging - it's something most of us learn through painful experience.  The good news is you _can_ learn how to debug effectively, and there's several key techniques and tools you can use for debugging JS and React apps.
React Advanced Conference 2022React Advanced Conference 2022
22 min
Monolith to Micro-Frontends
Top Content
Many companies worldwide are considering adopting Micro-Frontends to improve business agility and scale, however, there are many unknowns when it comes to what the migration path looks like in practice. In this talk, I will discuss the steps required to successfully migrate a monolithic React Application into a more modular decoupled frontend architecture.
React Advanced Conference 2023React Advanced Conference 2023
22 min
Power Fixing React Performance Woes
Next.js and other wrapping React frameworks provide great power in building larger applications. But with great power comes great performance responsibility - and if you don’t pay attention, it’s easy to add multiple seconds of loading penalty on all of your pages. Eek! Let’s walk through a case study of how a few hours of performance debugging improved both load and parse times for the Centered app by several hundred percent each. We’ll learn not just why those performance problems happen, but how to diagnose and fix them. Hooray, performance! ⚡️

Workshops on related topic

React Summit 2023React Summit 2023
137 min
Build a Data-Rich Beautiful Dashboard With MUI X's Data Grid and Joy UI
WorkshopFree
Learn how to put MUI’s complete ecosystem to use to build a beautiful and sophisticated project management dashboard in a fraction of the time that it would take to construct it from scratch. In particular, we’ll see how to integrate the MUI X Data Grid with Joy UI, our newest component library and sibling to the industry-standard Material UI.
Table of contents:- Introducing our project and tools- App setup and package installation- Constructing the dashboard- Prototyping, styling, and themes - Joy UI features- Filtering, sorting, editing - Data Grid features- Conclusion, final thoughts, Q&A
React Summit Remote Edition 2021React Summit Remote Edition 2021
87 min
Building a Shopify App with React & Node
Top Content
WorkshopFree
Shopify merchants have a diverse set of needs, and developers have a unique opportunity to meet those needs building apps. Building an app can be tough work but Shopify has created a set of tools and resources to help you build out a seamless app experience as quickly as possible. Get hands on experience building an embedded Shopify app using the Shopify App CLI, Polaris and Shopify App Bridge.We’ll show you how to create an app that accesses information from a development store and can run in your local environment.
React Summit 2022React Summit 2022
147 min
Hands-on with AG Grid's React Data Grid
WorkshopFree
Get started with AG Grid React Data Grid with a hands-on tutorial from the core team that will take you through the steps of creating your first grid, including how to configure the grid with simple properties and custom components. AG Grid community edition is completely free to use in commercial applications, so you'll learn a powerful tool that you can immediately add to your projects. You'll also discover how to load data into the grid and different ways to add custom rendering to the grid. By the end of the workshop, you will have created an AG Grid React Data Grid and customized with functional React components.- Getting started and installing AG Grid- Configuring sorting, filtering, pagination- Loading data into the grid- The grid API- Using hooks and functional components with AG Grid- Capabilities of the free community edition of AG Grid- Customizing the grid with React Components
JSNation 2022JSNation 2022
41 min
Build a chat room with Appwrite and React
WorkshopFree
API's/Backends are difficult and we need websockets. You will be using VS Code as your editor, Parcel.js, Chakra-ui, React, React Icons, and Appwrite. By the end of this workshop, you will have the knowledge to build a real-time app using Appwrite and zero API development. Follow along and you'll have an awesome chat app to show off!
GraphQL Galaxy 2021GraphQL Galaxy 2021
164 min
Hard GraphQL Problems at Shopify
WorkshopFree
At Shopify scale, we solve some pretty hard problems. In this workshop, five different speakers will outline some of the challenges we’ve faced, and how we’ve overcome them.

Table of contents:
1 - The infamous "N+1" problem: Jonathan Baker - Let's talk about what it is, why it is a problem, and how Shopify handles it at scale across several GraphQL APIs.
2 - Contextualizing GraphQL APIs: Alex Ackerman - How and why we decided to use directives. I’ll share what directives are, which directives are available out of the box, and how to create custom directives.
3 - Faster GraphQL queries for mobile clients: Theo Ben Hassen - As your mobile app grows, so will your GraphQL queries. In this talk, I will go over diverse strategies to make your queries faster and more effective.
4 - Building tomorrow’s product today: Greg MacWilliam - How Shopify adopts future features in today’s code.
5 - Managing large APIs effectively: Rebecca Friedman - We have thousands of developers at Shopify. Let’s take a look at how we’re ensuring the quality and consistency of our GraphQL APIs with so many contributors.
TypeScript Congress 2023TypeScript Congress 2023
131 min
Practice TypeScript Techniques Building React Server Components App
Workshop
In this hands-on workshop, Maurice will personally guide you through a series of exercises designed to empower you with a deep understanding of React Server Components and the power of TypeScript. Discover how to optimize your applications, improve performance, and unlock new possibilities.
 
During the workshop, you will:
- Maximize code maintainability and scalability with advanced TypeScript practices
- Unleash the performance benefits of React Server Components, surpassing traditional approaches
- Turbocharge your TypeScript with the power of Mapped Types
- Make your TypeScript types more secure with Opaque Types
- Explore the power of Template Literal Types when using Mapped Types
 
Maurice will virtually be by your side, offering comprehensive guidance and answering your questions as you navigate each exercise. By the end of the workshop, you'll have mastered React Server Components, armed with a newfound arsenal of TypeScript knowledge to supercharge your React applications.
 
Don't miss this opportunity to elevate your React expertise to new heights. Join our workshop and unlock the potential of React Server Components with TypeScript. Your apps will thank you.