La Fuente Legendaria de la Verdad: Componentiza tu Documentación!

Rate this content
Bookmark

"En el Espacio, Nadie Puede Oírte Gritar." Lo mismo ocurre con tu proyecto súper-nuevo-revolucionario: la Documentación es la clave para que la gente hable de él.

Crear una documentación bien ajustada puede ser complicado. Mantenerla actualizada cada vez que lanzas una nueva función debe ser una parte desafiante de tu aventura. Hemos intentado muchas cosas para evitar la brecha entre la documentación y el código: documentación generada por código, ejemplos en vivo al estilo de Storybook, REPL...

Es hora de una nueva era de documentación donde el contenido orientado a las personas conviva con ejemplos de código: esta charla te guiará desde las Mejores Prácticas de Documentación - cubiertas por años de documentación colaborativa de FOSS - hasta el nuevo y elegante mundo de los Componentes en Markdown: MDX, MDJS, MD Vite, y todo eso.

¡Construyamos una documentación brillante para personas brillantes!

24 min
25 Oct, 2021

Video Summary and Transcription

Bienvenido a esta sesión sobre documentación en una era impulsada por comandos. El marco de trabajo Data Axis proporciona un enfoque integral para la documentación, cubriendo diferentes áreas del proceso de desarrollo. El desarrollo impulsado por componentes y la sintaxis MDX permiten un desarrollo más rápido, un mantenimiento más sencillo y una mejor reutilización. La incorporación de componentes en Markdown utilizando MDX permite una creación de documentación más avanzada y útil. Se recomiendan herramientas como Storybook y Duxy con soporte MDX para soluciones de documentación. La incorporación de documentación directamente dentro de los componentes y la migración a MDX ofrecen una experiencia de documentación integral y abren nuevas posibilidades para la incorporación y mejora de la documentación.

Available in English

1. Documentación en una Era Dirigida por Comandos

Short description:

Bienvenidos a esta sesión sobre documentación en una era dirigida por comandos. Tu documentación es la clave del éxito de tu proyecto. Mantén tu documentación asociada con tu código para evitar desincronización. Necesitamos una única fuente de verdad, que es tu base de código. Mantén la documentación sincronizada con la base de código e incrusta tu base de código en tu documentación.

¡Hola a todos! ¡Qué bueno tenerlos aquí! Bienvenidos a esta sesión sobre documentación en una era dirigida por comandos. Así que vamos a hablar sobre la documentación como clave del éxito de tu proyecto. Quiero decir, sin importar si estás trabajando en una biblioteca, un componente individual, un sistema de diseño completo o una interfaz final de una aplicación, tu documentación es la clave del éxito de tu proyecto. Porque sin una documentación adecuada, nadie tendrá ni idea de cómo funciona y cómo se supone que debes usar tu proyecto o cualquier parte de tu proyecto. Así que debes mantener tu documentación correctamente asociada con tu código. De hecho, tener una documentación viva es un dolor hoy en día, simplemente porque si tienes que duplicar tu código de tu base de código a tu documentación, obviamente lleva a una desincronización en algún punto de tu documentación en comparación con tu base de código. Así que debes mantenerlos sincronizados si quieres estar listo para simplemente usar y mantener tu documentación a lo largo del tiempo, para tener tu proyecto listo para ser utilizado por cualquier persona en el pasado y en el futuro. Así que hemos intentado muchas cosas para mantener las cosas organizadas entre tu documentación y tu base de código. Hemos intentado cosas como storybook, hemos intentado cosas como incrustar, erpl en tu documentación en sí misma, hemos intentado muchas cosas pero la verdad real es que necesitamos una única fuente de verdad y esta única fuente es tu base de código en sí misma. No tu documentación, no tus ejemplos que estarán desactualizados en algún momento. Necesitas algo que sea definitivamente el único punto donde todo se origina y esto está directamente en tu base de código. Así que tenemos que hacer algo para mantener la documentación sincronizada con la base de código.

2. El Marco de Datos Axis

Short description:

Este es un marco de documentación que muchas empresas están utilizando en este momento. Está orientado en cuatro partes: READMES, O2s, FAQs y páginas principales. Los READMES sirven como punto de entrada para los usuarios, proporcionando guías de inicio. Los O2s son guías o recetas para trabajar con partes específicas del proyecto. Las FAQs contienen discusiones e historias, ayudando a comprender las elecciones e interacciones del proyecto. Las páginas principales proporcionan contenido técnico avanzado. Estas cuatro partes cubren diferentes áreas del proceso de desarrollo.

y necesitamos algo para incrustar tu base de código en tu nivel de documentación. Así que solo un recordatorio sobre el marco de datos Axis. Este es un marco de documentación que muchas empresas están utilizando en este momento. Este marco de documentación está orientado en cuatro partes. Todas estas cuatro partes son las partes dedicadas a tu documentación y todo lo que tienes que hacer es dividir diferentes elementos de tu documentación en la misma área. Así que la primera entrada son los READMES. Los READMES son el punto de entrada de tu documentación. Cuando un usuario llega a tu nueva documentación y no tiene ninguna idea de por dónde empezar, los READMES son el punto de entrada correcto. Son algo así como guías de inicio donde puedes seguir siempre el mismo camino y los mismos pasos en tu proceso de desarrollo y obtendrás el mismo resultado. Esta es una forma muy buena de involucrarte en tu proyecto. La segunda parte son los O2s. Los O2s son más guías o recetas y están dedicados a cómo quieres trabajar con esta parte del proyecto o cómo puedo incrustar mi proyecto en una aplicación React, cómo puedo usar mi biblioteca con este tipo de back-end, y así sucesivamente. Las guías presuponen que tienes una configuración preestablecida y en esta configuración particular hay guías, hay diferentes recetas sobre cómo podrías usar tu proyecto en diferentes aspectos del desarrollo. La tercera parte son las FAQs. En ellas tienes todas las discusiones, todas las historias, por qué se eligió este proyecto, este uso particular de esta herramienta, o esta configuración, y así sucesivamente. Aquí es donde vive toda la historia del proyecto y ayuda a comprender por qué elegimos esta configuración en particular en algún momento y ayuda a comprender cómo todo interactúa entre sí. Luego, las partes finales son las páginas principales en la era de Unix o más específicamente documentación avanzada sobre una parte dedicada, cómo funciona este componente, cómo se utiliza esta biblioteca en algún punto del proyecto. Esta es una guía completa de contenido técnico profundo. Estas cuatro partes están vinculadas a cuatro áreas diferentes. Los Readmes y los O2s son los puntos de práctica. Cada vez que te preguntas, `OK, estoy trabajando en una nueva parte de la documentación y quiero agregar nuevo contenido, ¿a qué tema está relacionado?` Si está relacionado con prácticas, entonces este es el punto correcto para echar un vistazo. Entonces, ¿es algo como un punto de entrada, como una guía de inicio, o es una guía dedicada a diferentes accesos en el área específica de partes específicas del proceso de desarrollo? Entonces, los Readmes y los Hotos, esto es práctica, donde los paquetes y las páginas principales están más dedicados a comprender el proyecto y las bases del proyecto. Pero los Readmes y las FAQs también son partes de aprendizaje, donde aprendes cómo funciona y por qué funciona de esta manera. Donde los Hotos están más dedicados a... Y las páginas principales están más dedicadas a cuando quiero usar el proyecto, ¿en qué parte debo prestar atención? ¿Es en los Hotos? ¿Es en las páginas principales? Estoy buscando contenido técnico detallado, o estoy buscando una guía dedicada sobre este tema en particular, porque esto es lo que estoy buscando en este momento. Entonces, cuando tienes este marco en mente, estás trabajando en una documentación bien adaptada para cualquier tipo de proyecto. Así que te recomiendo que prestes atención al marco de datos Axis, si aún no lo conoces, y trates de ajustar tu documentación a él, porque esto es algo realmente, realmente útil en tu trabajo diario.

3. Desarrollo impulsado por componentes y sintaxis MDX

Short description:

El desarrollo impulsado por componentes permite un desarrollo más rápido, un mantenimiento más sencillo, una mejor reutilización y una mejor TDD. Al aislar los componentes en un entorno de prueba, se pueden mantener, probar y documentar fácilmente. El marco de datos Axis permite organizar la documentación en torno a componentes específicos, facilitando la comprensión de su funcionalidad y uso. MDX, una sintaxis que combina Markdown y JSX, permite crear documentación más avanzada y útil.

Pero ahora estamos trabajando en un área de desarrollo impulsado por componentes. Entonces, en este entorno, estoy trabajando en componentes más que en cualquier otra parte. Y así, este desarrollo impulsado por componentes nos brinda una nueva forma de desarrollar y pensar en nuestra aplicación, porque implica un desarrollo más rápido, un mantenimiento más sencillo, una mejor reutilización, una mejor TDD, porque cada parte de tu aplicación se separa en partes pequeñas, en componentes pequeños.

Y cuando divides toda tu interfaz frontend en componentes solamente, entonces puedes trabajar en partes pequeñas que están aisladas en tu aplicación. Y puedes extraer tu contenido y hacerlo funcionar de forma aislada en un entorno de prueba. Y en este entorno de prueba, tu componente se puede mantener, probar y documentar fácilmente. Y esta es la parte que estamos buscando en este momento. Entonces, en este marco de datos Axis, con una era de desarrollo impulsada por componentes, ¿cómo podemos combinarlos para aprovechar al máximo los dos mundos? Esto es realmente interesante, porque cuando trabajas de esta manera, es muy fácil extraer tu componente de tu aplicación y ponerlo en un entorno de prueba dedicado, trabajar en él, realizar algunas pruebas, utilizar este nuevo componente en vivo y tenerlo disponible para incrustarlo en diferentes partes, diferentes áreas de tu documentación. Así que tu documentación ahora puede ser completamente exhaustiva sobre cómo funciona de esta manera, cómo es este componente realmente útil, cómo podemos confiar realmente en este componente en este contexto particular, y así sucesivamente.

Entonces, en mi marco de datos Axis, poner algunas cosas dedicadas a mi componente en las guías o los README y los O2s, etc., es realmente muy útil porque ahora es fácil entender dónde puedo poner mi documentación para estas partes particulares de mis aplicaciones, que son este componente, mi menú desplegable, mi vista de galería, mi héroe, mi botón. Esto es exactamente cómo quiero realizar mi documentación, porque cuando busco una nueva documentación en un proyecto, lo que busco es: OK, ¿cuáles son los diferentes componentes disponibles en mi biblioteca, cómo puedo usarlos, cómo puedo hacerlos todos, cómo puedo conectarlos todos para interactuar entre mis componentes. ¿Cómo puedo usarlos en React, en Visual Effects, en lo que sea que quieras. Así es exactamente cómo tenemos que cambiar nuestra forma de pensar para colocar la documentación relacionada con un componente en las partes correctas de nuestra documentación general en su totalidad.

Entonces, con eso, ahora podemos jugar con los documentos en vivo porque podemos incrustar nuestro componente que probablemente está aislado de nuestra aplicación final en nuestra documentación a mano. Así que ahora es muy fácil simplemente jugar con nuestro componente en un entorno de prueba con este documento, este componente en nuestra documentación, jugar con él y probarlo, tener alguna especie de experimento, romperlo en algún momento. Pero esto es solo porque puedes usar tu componente en un área dedicada que está en vivo en la documentación. Entonces, necesitamos mezclar este componente en nuestra documentación, importarlo en nuestra documentación y tenerlo en vivo aquí. Entonces, ¿cómo podemos hacer eso ahora mismo? Esta es la respuesta que nos brinda el entorno MDX. Entonces, MDX es Markdown pero un Markdown glorificado.

Entonces, al escribir tus documentos, probablemente estés usando Markdown para escribir tu documentación. Esto es solo azúcar sintáctica en HTML, probablemente conozcas Markdown porque está en todas partes en este momento, desde GitHub hasta cualquier CMS o plataforma de documentación o plataformas de producción de documentos, por lo que es una sintaxis realmente simple, fácil de leer, fácil de contribuir, incluso si no eres técnico en absoluto. Porque esto es simplemente escribir texto con algún tipo de marcado que son solo caracteres simples, por lo que no es tan complejo. Es compatible con cualquier editor de texto, es muy fácil de usar, pero es demasiado simple para usar con documentos realmente complejos. Quiero decir, con Markdown no puedo incrustar mi componente en él, así que tengo que hacer algunas cosas. OK, puedo incrustar HTML directamente en mi Markdown, pero no es suficiente. Necesito algo más avanzado, y necesito algo más útil cuando quiero trabajar con él. Por eso ahora tenemos la sintaxis MDX, y el MDX es simplemente JSX incrustado en Markdown. O más que eso, esto es Markdown convertido a JSX, que ahora se convierte en HTML. Entonces, esto es un paso más entre el Markdown y el HTML en el proceso de renderizado. Esto no es solo una conversión lineal de Markdown a HTML, sino de Markdown a JSX a HTML. Entonces, en este entorno, cuando estoy trabajando en mi Markdown, en realidad estoy trabajando en un documento JS o más bien un documento JSX.

4. Incrustación de componentes en Markdown

Short description:

Ahora tenemos componentes en Markdown directamente. Podemos incrustar componentes externos, pasar props y contar con soporte nativo de TypeScript. MDX nos permite incrustar cualquier tipo de componente utilizando una sintaxis flexible de Markdown. Es fácil configurar MDX con diferentes entornos, desde Gatsby hasta ReactStatic. Solo hay que agregar una línea de configuración.

Así que puedo importar, exportar cualquier tipo de documento en él. Podría escribir Markdown en él, pero también podría colocar mi documento, mi componente en mi documento en este momento al final. Y esto ahora está incrustado en mi Markdown. Y esto se renderiza en mi Markdown, en el proceso final. Así que esto es realmente útil porque ahora tenemos componentes en Markdown directamente.

Bajo el capó, esto es solo el nivel estándar de Markdown con la sintaxis nativa de JSX todo mezclado. Podríamos incrustar componentes externos. Podríamos incrustar la representación de funciones y la representación de funciones externas. Podríamos pasar props. Podríamos contar con soporte nativo de TypeScript. Podríamos tener todo lo que estamos acostumbrados a hacer con JSX pero directamente en nuestro Markdown. Porque en el paso final, esto es solo un proceso de renderizado donde tengo una sintaxis de Markdown, una sintaxis de MDX, luego esto se convierte en un AST. Este es un AST de JSX. Luego, este AST de JSX se convierte en un AST de HTML. Luego, este AST de HTML se convierte en HTML. Esto es solo un proceso de conversión diferente. Esto es exactamente lo que estamos buscando. Ahora tenemos una sintaxis de Markdown lo suficientemente flexible como para ser utilizada para incrustar cualquier tipo de componente.

Tengo un diseño simple de MDX. Puedo incrustar cualquier prop en él, cualquier componente en él y puedo renderizar cualquier cosa que desee. Esa es una sintaxis JSX regular o una sintaxis de Markdown regular y las mezclo todas. Ahora tenemos diferentes entornos listos para incrustar el MDX. MDX es realmente simple. Solo hay que agregar una línea de configuración en tu configuración de Webpack o tu configuración de relab. Esto es realmente fácil de hacer. No es una configuración compleja de tener. Pero ahora dividimos este entorno en dos mundos. Tenemos por un lado las herramientas básicas que están listas para incrustar el MDX. Puedo hacer MDX con cualquier tipo de generador estático, desde Gatsby hasta ReactStatic o cualquier cosa que desees. Solo tengo que incrustar mi configuración de MDX en mi Webpack o relab, y todo funcionará libremente.

5. Frameworks y Soluciones de Documentación

Short description:

Este es un marco de documentación que proporciona herramientas para incrustar MDX y crear documentación adecuada. Es útil si estás buscando producir documentación en lugar de solo Macdon con componentes. Se recomiendan herramientas como Storybook y Duxy con soporte MDX para soluciones de documentación.

Pero esto está totalmente desnudo en el sentido de que no tengo ningún preajuste, no tengo ningún diseño, ningún playground, ninguna prop, más sobre eso más adelante. Así que tienes que hacer todo lo que quieras por ti mismo. Eres totalmente libre, esto es completamente flexible, pero es mucho trabajo al principio solo para tener algo funcionando y una documentation funcionando.

Esto es realmente, realmente útil si solo quieres producir un Macdon con sintaxis JSX. Por otro lado, tienes soluciones orientadas a la documentation que incrustan MDX en primer lugar y que proporcionan cualquier tipo de herramienta que necesites para incrustar tu documentation en algún momento con un diseño adecuado, una tabla de props adecuada, playgrounds adecuados, etc. Esta es una solución como Storybook con soporte nativo de páginas MDX o Dubbd. Viene con más restricciones porque es un marco de documentation, pero esto es realmente útil si lo que buscas es producir documentation y no solo producir Macdon con componentes en ellos. Si estás buscando una solución de documentation, te animo a que eches un vistazo a herramientas de documentation orientadas como Storybook, Duxy, etc., con soporte nativo de MDX en ellas. Porque te brindan todo lo que necesitas para simplemente producir tu propia documentation con ellas.

6. Incrustación de Documentación en Componentes

Short description:

Cuando trabajas con componentes, es esencial incrustar la documentación directamente dentro del propio componente. Backlight, un editor de sistemas de diseño, permite un desarrollo completo orientado a componentes. Cada componente puede tener su propia documentación, pruebas y herramientas de diseño incrustadas en él. MDX proporciona una forma de importar componentes directamente en la documentación. Los playgrounds y las tablas de props son herramientas útiles para renderizar y personalizar componentes en la documentación.

Ahora tienes que organizar tu proyecto. Cuando estás trabajando en una documentation que está relacionada con componentes, es sentido común incrustar la documentation en el propio componente, en lugar de tener una documentation que está decorada a partir de los componentes, debes incrustarlo todo en ellos. Esta es la vista de Backlight.

Backlight es una herramienta en la que estamos trabajando en DivRiots. Es un editor de sistemas de diseño. Por lo tanto, está totalmente orientado a componentes. Cada parte de la interfaz de separación de preocupaciones está orientada a componentes. Entonces, cuando tengo mis componentes, puedo escribir mi código en mis componentes, pero más específicamente, puedo tener mis historias, mis pruebas, mi documentation, mis herramientas de diseño, todo está incrustado en mi componente. Así que tengo uno superior, donde tengo un gran readme o una gran descripción general de mi aplicación. Ese es mi componente superior, finalmente. Cada vez que quiero tener una documentation relacionada con un componente dedicado, como mi botón, solo tengo que ir a mi botón, abrir la carpeta de documentación en la carpeta de mi componente, que es la carpeta de mi botón, y en mi carpeta de documentation, tengo todo lo relacionado con mi componente, con mi botón, escrito directamente en MDX con soporte de GSX, en Madinx, y con esta sintaxis de MDX, puedo importar mi botón directamente en mi documentation. Veamos cómo. Entonces, tenemos un componente GSX. Se ejecutan en un entorno aislado, que reacciona al entorno de envoltura de nuestro componente. Así que solo quiero incrustarlo todo de la misma manera. Entonces, cómo trabajar con ellos con tu propio playground. El hecho es que MDX es demasiado básico. Necesitamos algo más avanzado para trabajar con ellos. Hablé de los playgrounds y las tablas de props. Los playgrounds son finalmente una especie de sandbox que puedo usar para renderizar directamente cualquier tipo de componente directamente en mi documentation. Así que con mi playground, puedo escribir mi componente o incrustarlo directamente, y mi playground estará listo para extraer cualquier parte de él para mi proceso de renderizado. Puedo tener una sola importación de mis componentes, y puedo tenerla en la vista de renderizado, la vista de compilación, una vista EST, lo que quiera. Y este playground me permite tener una sola importación en mi MDX, y esto está renderizando cada parte de mis diferentes vistas de mis componentes y lo que quiero. Otra cosa es la tabla de props. Porque mi componente viene con diferentes props que me permiten personalizarlo, quiero tenerlos directamente en mi documentation para ver cómo se supone que funcionan mis componentes. Así que esto es una especie de reflector para las propiedades del componente. Esto se genera automáticamente con cualquier tipo de propiedades que pueda exponer desde mi componente. Así que esto está actualizado porque todo lo que tengo que hacer es poner algo como, dame la tabla de props de este componente y todo funciona. Esta es la vista de

7. Incrustación de Componentes y Migración a MDX

Short description:

Puedes incrustar un solo componente como un reflector de tu componente y tener acceso a todas sus propiedades en tu documentación. MDX, combinado con componentes, historias, playgrounds y tablas de props, permite una experiencia de documentación completa. La migración a MDX es fácil si ya estás trabajando con Markdown. Solo organiza tu documentación utilizando el framework ADDXS, aísla la documentación de cada componente y elige la herramienta o plataforma adecuada. MDX es solo el comienzo de una nueva era con más formatos y herramientas para incrustar y mejorar la documentación. Enfócate en las herramientas avanzadas de DevTools e incrusta código en la documentación. Las herramientas de DevRiot, como webcomponents.dev y backlight.dev, ofrecen soluciones completas para la documentación y el desarrollo orientado a componentes.

Sistema de tablas de props de storybook. Esto es solo una línea. Solo incrustas un solo componente que es un reflector de mi componente. Y en mi documentación, tengo acceso a cualquier parte de las propiedades de mi componente en absoluto. Así que esto es realmente útil si quiero tenerlo. Luego puedes codificar desde tu documentación, puedes importar el componente que deseas documentar, puedes escribir tu Markdown como estás acostumbrado cuando trabajas en la documentación y puedes incrustar cualquier tipo de elementos relacionados con esta descripción del componente, el playground, la tabla de props, todo estará en una sola línea alineada con mi código porque la documentación no está decorada para mis componentes en este momento, los incrusta en ella. Así que finalmente, MDX más componentes, historias, formato, más playgrounds, más tablas de props, ¡genial! Este es el mejor mundo. Puedes tener una documentación que está totalmente relacionada con tus componentes en absoluto. Entonces, ¿cómo migrar a MDX? Probablemente ya estés trabajando en la documentación en formato Markdown. Así que no tienes que adaptar nada. Solo tienes que organizar tu documentación desde el framework ADDXS para tus diferentes componentes. Así los tengo debidamente aislados cada documentación para cada componente al lado. Luego puedes elegir la herramienta adecuada o una plataforma de documentación en blanco o una herramienta de framework de documentación. Luego puedes comenzar a jugar con tus componentes. Y eso es todo. Porque MDX es solo el comienzo. Esta es solo la primera herramienta de una nueva era. Y estoy seguro de que tendremos muchos otros formatos y muchas otras herramientas para incrustar nuestra documentación y mejorar nuestros componentes y nuestra documentación. Pero escribir documentación fuera de escribir es simplemente absurdo. Tenemos que incrustar nuestro código en nuestra documentación. Y esta es la premisa del formato MDX. Esto es lo que estamos buscando. Ahora debes enfocarte en DevTools avanzados e integrados en lugar de reinventar la rueda en algún momento. Solo debes enfocarte en lo que estás buscando. Esto es exactamente lo que estamos haciendo con las herramientas en las que estamos trabajando en DevRiot, como backlight de webcomponents.dev. Si tienes alguna pregunta, nos veremos en una sesión de preguntas y respuestas en este momento. Para todo lo demás, muchas gracias. Soy Mats, un defensor del desarrollo participativo en DevRiot, donde estamos trabajando en soluciones orientadas a documentos y componentes como webcomponents.dev o backlight.dev, que son IDE orientados a sistemas de diseño en tu navegador, directamente en tu navegador con todo lo que necesitas en él, como el proceso de documentación, MDX, playgrounds, props, tablas, y más, échales un vistazo. Muchas 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
39 min
Don't Solve Problems, Eliminate Them
Top Content
Humans are natural problem solvers and we're good enough at it that we've survived over the centuries and become the dominant species of the planet. Because we're so good at it, we sometimes become problem seekers too–looking for problems we can solve. Those who most successfully accomplish their goals are the problem eliminators. Let's talk about the distinction between solving and eliminating problems with examples from inside and outside the coding world.
React Advanced Conference 2022React Advanced Conference 2022
30 min
Using useEffect Effectively
Top Content
Can useEffect affect your codebase negatively? From fetching data to fighting with imperative APIs, side effects are one of the biggest sources of frustration in web app development. And let’s be honest, putting everything in useEffect hooks doesn’t help much. In this talk, we'll demystify the useEffect hook and get a better understanding of when (and when not) to use it, as well as discover how declarative effects can make effect management more maintainable in even the most complex React apps.
JSNation 2022JSNation 2022
28 min
Full Stack Documentation
Top Content
Interactive web-based tutorials have become a staple of front end frameworks, and it's easy to see why — developers love being able to try out new tools without the hassle of installing packages or cloning repos.But in the age of full stack meta-frameworks like Next, Remix and SvelteKit, these tutorials only go so far. In this talk, we'll look at how we on the Svelte team are using cutting edge web technology to rethink how we teach each other the tools of our trade.
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.
React Summit 2023React Summit 2023
23 min
React Concurrency, Explained
React 18! Concurrent features! You might’ve already tried the new APIs like useTransition, or you might’ve just heard of them. But do you know how React 18 achieves the performance wins it brings with itself? In this talk, let’s peek under the hood of React 18’s performance features: - How React 18 lowers the time your page stays frozen (aka TBT) - What exactly happens in the main thread when you run useTransition() - What’s the catch with the improvements (there’s no free cake!), and why Vue.js and Preact straight refused to ship anything similar

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Top Content
Featured Workshop
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.
React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn
React Day Berlin 2022React Day Berlin 2022
53 min
Next.js 13: Data Fetching Strategies
Top Content
WorkshopFree
- Introduction- Prerequisites for the workshop- Fetching strategies: fundamentals- Fetching strategies – hands-on: fetch API, cache (static VS dynamic), revalidate, suspense (parallel data fetching)- Test your build and serve it on Vercel- Future: Server components VS Client components- Workshop easter egg (unrelated to the topic, calling out accessibility)- Wrapping up
React Summit 2022React Summit 2022
160 min
React at Scale with Nx
WorkshopFree
The larger a codebase grows, the more difficult it becomes to maintain. All the informal processes of a small team need to be systematized and supported with tooling as the team grows. Come learn how Nx allows developers to focus their attention more on application code and less on tooling.
We’ll build up a monorepo from scratch, creating a client app and server app that share an API type library. We’ll learn how Nx uses executors and generators to make the developer experience more consistent across projects. We’ll then make our own executors and generators for processes that are unique to our organization. We’ll also explore the growing ecosystem of plugins that allow for the smooth integration of frameworks and libraries.