5 Años de Construir React Table

Muy bien. Estoy emocionado de estar aquí. Tengo mucho que cubrir. Estoy con jet lag y cansado, pero tengo que traer la energía, así que ayúdame. Tenemos que traer la energía, ¿de acuerdo? Tengo algunas camisetas que tengo que lanzar rápidamente y algunas personas que van a ayudarme. Así que vamos a ello. Aquí, toma esa también. ¿Alguien quiere una camiseta? ¡Por aquí! Bueno, el que más grite se lleva la camiseta. ¡Sí! ¡Era exactamente la persona! ¡Perfecto! Me voy. Lo siento.

Bien, espero que te guste Jurassic Park. Puede que no te guste al final de mi charla porque, no sé, ya verás. Mi nombre es Tanner Lindsley y estoy aquí porque amo a React y amo el código abierto y estoy un poco adicto a él. Es una mala adicción pero es muy divertida. Normalmente estaría hablando de React Query hoy. No voy a hacer eso. Prefiero hablar de Take It Back Old School, la primera biblioteca que construí de ese tipo y despegó y ahora es React Table. Quiero hablar de los últimos cinco años de React Table y algunas cosas que he aprendido a través de este loco proceso de construir una biblioteca de código abierto y quizás puedas aplicar algo de ello a lo que haces, o quizás no. Es solo una charla divertida. Pero tenemos que volver aún más atrás, hasta 2015.

Fui invitado a cofundar una startup llamada Nozzle con algunos amigos. Y Nozzle es básicamente Google pero contra Google. Estamos rastreando inversamente los resultados de búsqueda de Google a scale. Estamos hablando de miles de millones de resultados al día. Los estamos midiendo y extrayendo todos los data y simplemente metiéndolos en BigQuery, créelo o no, y devolviéndolos a los SEOs y a los especialistas en marketing que quieren esos data. Es bastante genial. Parte de ese producto es que tenemos que hacer mucha data visualization, muchas consultas, y por supuesto muchas tablas. Está empezando a unirse ahora. Ojalá nuestras tablas en 2015 se parecieran a esto. No lo hicieron.

Estábamos trabajando con una tecnología un poco menor aquí. No exactamente como esto, pero aquí es donde todo comienza. Todos comienzan con la tabla HTML5 porque es increíble. Realmente es un gran elemento. Intenta construir una tabla con divs y lo apreciarás.

Necesitábamos enviar y vender y, con suerte, como Sweizek Teller pudo enseñarnos, tener la oportunidad de mejorar. Así que era como ir, ir, ir tan rápido como pudiéramos. Estábamos usando Angular en ese momento. Booo. Y estábamos usando herramientas como ngGrid y uigrid, que honestamente eran fantásticas. Fueron construidas en Angular, como para Angular, gran integración, y finalmente llegamos a usar aggrid, que también es una herramienta increíble. Ahí vamos, tenemos algunos fans de aggrid.

Entonces sucedió algo que no esperábamos. Este framework aparece de la nada, y es como, esto es todo. Aquí es donde necesitas estar. Y nosotros estábamos como, OK, hagámoslo. Tiempo de inversión. Pasamos todo a React. Estoy hablando de todo, en unas tres semanas. Y luego llegamos allí y estamos como, mierda. No tenemos una biblioteca de datagrid. Y yo estaba como, espera, espera, espera, espera. aggrid tiene un adaptador de React. Estábamos como, estamos salvados. ¿Y adivina qué? Lo estábamos. Pudimos migrar y seguir usando aggrid, y honestamente fue súper genial. Pero nos encontramos con algunos pequeños problemas aquí y allá. Estábamos trabajando con un componente de React. Es solo React. Todo son solo componentes.

Pero algo era interesante. Bajo el capó, notamos que aggrid no se estaba renderizando usando React. Estaba enviando su propio motor de manipulación de DOM personalizado, lo que explicaba por qué era tan increíblemente rápido. Pero en el proceso de enviar ese motor increíblemente rápido, React se vio un poco afectado. No había el nivel de integración que estábamos buscando. Estoy realmente contento de que a día de hoy, aggrid tenga un renderizado de React integrado. Es asombroso. Niall de aggrid hablará de ello en unos minutos. Quédate si quieres escuchar sobre eso.

Esto fue en 2017. Eso aún no existía y necesitábamos una biblioteca de tablas de inmediato. Obviamente, comencé a trabajar en la tabla de React. Era un solo componente. Era 100% React. Pude descargar muchas cosas a React. Tuvimos que hacer toda la renderización, la gestión de estado. Todavía estábamos usando this.set state, pero aún era bastante bueno. Incluso teníamos paquetes más pequeños porque React estaba haciendo mucho por nosotros.

Lo lanzamos pensando que iba a ser lo que fuera. La tabla de React comenzó a crecer. La gente quería tablas y que React trabajara en conjunto. Mientras estábamos disfrutando del éxito que teníamos en el gráfico de descargas de NPM, una tormenta se estaba gestando en el repositorio de GitHub en forma de problemas. Toneladas de problemas. Nos estaban inundando con problemas, y todos se veían así. ¿Puedo mover la paginación? ¿Me das props personalizadas? ¿Puedo usar mi propio componente de fila? ¿Puedo usar cualquier biblioteca de CSS y JS que salga esta semana? ¿Puedo hacer algo con el marcado? La realidad es que no podía responder ninguna de esas preguntas. No tenía las opciones para hacer eso. Honestamente, era solo un enorme montón de basura. Era terrible. Hice lo único que sabía hacer, y eso es agregar más props. ¿Alguna suposición de cuántas props agregué a la versión 6 de la tabla de React? Cinco.

¡Vamos! 130. 137 props. Para hacer todo. Están todos ahí. Para personalizar cada pequeño detalle sobre React Table porque era solo un componente.

Me estaba ahogando. Honestamente, me estaba ahogando. Afortunadamente, no morí. Pero, afortunadamente, mientras me estaba ahogando en mi miseria, mi amigo Kent estaba construyendo una nueva biblioteca llamada Downshift.

Downshift era una biblioteca para construir desplegables y autocompletados. Pero era realmente interesante. No renderizaba ningún marcado para ti. Solo te daba el estado, te daba la API, y tú tenías que conectarlo tú mismo. Vi esto y pensé, esta es la respuesta. Así es como voy a resolver este problema. Inmediatamente, me sumergí en el código fuente de React Table. Pensé, arranca todo esto, vamos a ir con este enfoque de API, invertir el control al usuario para renderizar todo ellos mismos.

Algunas personas decían, ¿vas a hacer que yo renderice mi propia tabla? Y yo decía, sí, lo haré. Porque va a ayudar. Solo confía en mí. Lo prometo. Estoy casi terminando de escribir esta nueva versión. El equipo central de React dijo, boom, enganchado. En serio, simplemente mató todo, funciones como hijos, render props. Yo decía, sí. Validó exactamente el enfoque que estaba tratando de tomar. Así que pude tomar este componente dinky como función de hijos y convertirlo en este impresionante hook de use table donde podrías devolver cualquier marcado que quisieras. Fue fantástico. Y lo lanzamos. Lo lancé lo antes posible, tan pronto como estuvo terminado.

Y la versión 7 de React Table fue increíble. Pero debido a esta inversión de control, pude cerrar, como, el 95% de los problemas de GitHub que teníamos, básicamente respondiendo a todos con la misma cosa exacta. ¿Quieres mover la paginación? Hazlo tú mismo, te desafío. Y más tarde aprendí que este patrón tiene un nombre. Se llama Headless UI.

Y Headless UI no es el producto tailwind que estás pensando. Pero conceptualmente, es, sabes, es un proceso de tomar toda tu lógica y todo lo que compone las partes lógicas de tu aplicación y separarlas de tu marcado y tus estilos. Creo que esto fomenta, como, mucha más capacidad, inversión de control, reutilización. Creo que resulta en un code de mayor calidad. Da como resultado de la misma manera que mover tu estado a una máquina de estado. Así que, lanzamos la Versión 7, y fue genial. Tomó un poco de tiempo para convencer a la gente de que tenían que escribir sus propias tablas. Pero una vez que lo probaron, les encantó el poder.

Vale. Eso duró dos años. E incluso comencé a ver algunos proyectos como los problemas de GitHub, la nueva beta está usando React table bajo el capó para renderizar todas sus tablas. Pero están usando sus propios componentes. Todo es Headless. Así que, pueden seguir usando su component library y todos sus estilos, y todo a lo que están acostumbrados a usar. Vi esto, y solo pensé, lo logré. React table está terminado. Me voy. Voy a construir React query. Básicamente hice eso. El código abierto tiene una forma, sin embargo, de jugarte una mala pasada. Nunca terminas con el código abierto, y tampoco tus usuarios. Realmente desearía tener sonido para la próxima diapositiva, pero estoy bastante seguro de que Paramount Pictures cerraría la transmisión. De todos modos, estoy aquí disfrutando de mi código abierto, y de la nada es como, boom, los usuarios de TypeScript aparecen de la nada. Están como, danos TypeScript, vamos, vamos, y yo estoy como, ¡aléjate! No tenía idea de qué hacer. Es una historia real.

Estaba como, cerrando problemas, y escondiéndome, bloqueando cosas, como, aléjate, ¿verdad? Si alguien ha hecho código abierto, como, tienes TypeScript viniendo hacia ti, da miedo. Si no conoces TypeScript, simplemente estás como, no sé de qué estás hablando. Lo siento, alguien más puede hacer los tipos. Solo voy a seguir jugueteando por aquí. No tenía idea de lo que estaba haciendo. Pero era aún más aterrador porque sabía que TypeScript era casi inevitable. Venía por mí, y en algún momento, iba a tener que tener un ajuste de cuentas.

Me resistí mucho, incluso lo criticaba en Twitter. Todos lo hacemos. Todos, levanten la mano. Todos lo hacemos. Pero comencé a notar que las bibliotecas que usaban TypeScript generalmente eran de mayor calidad, más que las mías. Tenían menos problemas, y honestamente, los desarrolladores que trabajaban en ellas y usaban TypeScript, era síndrome del impostor. Eran simplemente estrellas de rock. No sé cómo lo hacían. Eventualmente, tuve que aceptarlo. Era hora de subir de nivel. Fue una decisión difícil porque significaba reducir la velocidad para aprender algo nuevo y aterrador. Pero lo adopté, a gran escala.

TypeScript realmente es increíble. Y prometo que esta no es una charla sobre TypeScript, pero quizás un poco de mensaje literal. Comencé a reescribir la versión 8 de React Table hace dos años con TypeScript y pensé, tendré una nueva versión en dos semanas. Será como una alfa, dos semanas, será fácil. De ninguna manera. No sabía lo que estaba haciendo. Me había lanzado al extremo y había aprendido que escribir bibliotecas y TypeScript, esto es algo súper avanzado. Ni siquiera sabía cómo usar TypeScript como desarrollador de aplicaciones aún, y estaba tratando de escribir una biblioteca. Estaba en sobre mi cabeza.

Así que lancé la señal de batman en Twitter, y tuve a algunas personas increíbles que vinieron a mi rescate, ofrecieron su tiempo y toda su energía para ayudarme a aprender TypeScript en todas las formas posibles, como mirar sus patrones, llamadas en vivo con todos, soporte a través del mantenimiento. Este es mi equipo de TypeScript, y solo quería agradecerles públicamente porque son increíbles. Pero todos básicamente dijeron esto, sí, gracias. Gracias. Todos básicamente dijeron lo mismo. Agárrate fuerte. Porque TypeScript de biblioteca es una locura. Oh, también, los genéricos, van a hacer volar tu mundo. Como, te harán llorar, y luego te harán muy feliz. Son geniales.

De hecho, hablemos de los genéricos realmente rápido. Es básicamente el proceso de tomar algo que sería tipado estáticamente, como una cadena, y darle variables a tus tipos para que puedas canalizar esos tipos en tu sistema y devolverlos a tus usuarios. Esta es una función realmente simple, pero también puedes usar múltiples genéricos para extraer información de los tipos, y proporcionarla de vuelta al usuario en forma de autocompletado. A todos les encanta eso de VS Code, seas usuario de TypeScript o no. en otro nivel, ¿verdad? Mira la función de crear columna para React Table. Son diez genéricos. Pasémoslo por Prettier. Eso es realmente lo que vamos a ver. Está bien, tenemos algunas opciones y una columna y no sé si alguien se dio cuenta, pero aún no estamos devolviendo, aún no estamos haciendo la implementación. Este es el volumen de código que tenemos. Hay al menos 36 funciones en React Table y todas consumen aproximadamente la misma cantidad de genéricos. ¿Alguien sabe cuántas líneas de código son? Son como 5,000 líneas de código. En algunas líneas de código, son líneas de tipos. Esto fue algo que tuve dificultades para entender con los tipos, donde me preguntaba, ¿por qué estoy haciendo esto, verdad? Sí, la implementación ni siquiera estaba terminada. Así que estaba bastante triste, pero tuve esta idea. ¿Alguien más se ha encontrado con esta situación con JavaScript? Como vaya, eso es un montón de argumentos. ¿Qué hacemos? Lo metes en una bolsa de opciones. Boom. Bolsa de opciones. Empaquetándolo.

Por lo tanto, podemos hacer lo mismo con los genéricos. Podemos tomar todos estos genéricos, extraerlos en un tipo genérico y reutilizarlo como una variable. Esto es algo muy nuevo, y no lo he visto mucho en la práctica. Espero que funcione, porque es increíble.

Después de hacer este cambio, pude acceder a todos mis genéricos como una lata de JavaScript objetos. Se llama mapas genéricos, y no sé por qué se llama mapas genéricos. Creo que debería llamarse bolsas genéricas. Pude reducir el code fuente de React Table en un 70 por ciento implementando este patrón. Probablemente tendré que hablar más sobre esto en una charla de TypeScript. Pero este fue el punto en el que comencé a sentirme seguro. Estaba como, está bien. Soy peligroso, y sé un poco de genéricos. Me siento bien.

Todas las grandes cosas sobre TypeScript comenzaron a salir. Toda la refactorización, menos errores, mejor design. Es capaz de tomar todas las cosas que normalmente solo están atrapadas en tu cerebro que van a desvanecerse si te alejas de tu proyecto durante dos semanas, meterlas en TypeScript, y simplemente dormir por la noche porque no estoy recordando los árboles de dependencia de mi code. Creo que es una necesidad. Hay mucho más que necesitamos hablar sobre TypeScript. Simplemente no puedo hacerlo. Es una tecnología ganadora. Tómalo de alguien que fue un completo 180 desde el año pasado. Necesitas probarlo. Necesitas usarlo.

No queda mucho tiempo, pero hay una cosa más de la que quiero hablar que es un poco de una historia de batalla con React Table, pero también es el futuro. Solo quiero tranquilizar a todos ahora mismo. Lo prometo, amo a React. Estoy aquí para quedarme. Pero seríamos muy ingenuos al pensar que React es una especie superior y es lo único capaz de producir aplicaciones y UI increíbles, ¿verdad? Sé que lo amamos, pero necesitamos bajarlo del pedestal de vez en cuando. Hay otros marcos por ahí. Solid, Vue, Svelte. Está bien. Adelante. Sabes, creo que ellos también merecen tablas. Creo que merecen una tabla mayor que la que puedo construir en React.

Y, en la tradición de empujar el límite en el último momento, decidí tomar React Table y volverse agnóstico. Así que, React Table ahora se llama TanSeqTable, y se enviará con todos los adaptadores para todos los marcos. ¿Angular, quieres trabajar en el adaptador de Angular? Ven a hablar conmigo. ¿Vale? Pero es agnóstico al marco. Y esto normalmente sería muy difícil, pero aparentemente, estar de pie sobre los hombros de headless UI lo hace mucho más fácil. Ya estamos separando el marcado y los estilos, y eso compensa muchas de las diferencias entre muchos de nuestros marcos de entrada. Y resulta que solo necesitábamos unos pocos adaptadores para sentarnos en el medio, como para conectar los internos de la reactividad y el contexto. Este es el adaptador de tabla sólida. Eso es. Y todos los demás adaptadores básicamente se ven exactamente igual, incluso React.

Por lo tanto, los últimos cinco años han sido realmente interesantes con Tansac Table. Dos años se han dedicado solo a implementar y aprender TypeScript. Fue una locura. Realmente solo queda una cosa por hacer. ¿Deberíamos hacerlo? Está bien. Hagámoslo. Espera. Espera. Ni siquiera estamos conectados al Wi-Fi.

Lo haré después de la charla. Está bien. También hay algunas otras cosas de las que quiero hablar rápidamente.

Entonces, durante los próximos 30 días, nos convertiremos a TANStack Query, virtual, y Ranger, y el resto de las bibliotecas llegarán pronto.

Quería agradecer realmente a todos los que han ayudado con estos proyectos, a cualquiera virtual. Hay muchos mantenedores y contribuyentes trabajando, especialmente en otros frameworks, y creo que eso es realmente impresionante. También, a todos mis patrocinadores de GitHub. No habría podido hacerlo sin ellos.

Quería hablar de un patrocinador, es completamente nuevo en particular, que no esperarías pero AG Grid. Normalmente, TANStack Table, es un poco raro decir eso ahora, y AG Grid han sido vistos como competidores. Sabes, resulta que eso no es realmente el caso. Son muy diferentes. Resuelven problemas únicamente diferentes con paradigmas muy diferentes. Dependiendo de tu caso de uso, podrías querer usar cualquiera de ellos. Al igual que yo en un momento usé AG Grid y me encantó. Llegamos a esta realización y supimos que era hora de trabajar juntos. Así que hoy, estoy anunciando que AG Grid es el primer socio OSS de TANStack con TANStack Table y juntos, vamos a trabajar tan duro como podamos para educar a todos en el ecosystem, independientemente del framework, sobre cómo construir mejores tablas, cuándo usar cada herramienta, y vamos a compartir tanto conocimiento como podamos a través de este abismo y asegurarnos de que todos podemos ser amigos. Entonces, puedes leer más al respecto en TANStack.com. Eso es todo. ¡Woo! ¡Woo! Sí.

Bueno, muchas gracias Tanner. Como usuario de React Table, lo usé en un proyecto anterior. Tengo que decir que fue realmente, lo que dijiste, ese cambio al paradigma headless, fue una cosa extraña al principio, pero tan pronto como empiezas con ello, te das cuenta de que, sí, así es como debería ser, ¿verdad? Sí. Entonces, puedo, sí, puedo decirle a todos los que piensan que es raro. Fue básicamente lo mismo para mí cuando vi React por primera vez. Se siente raro, ¿verdad?, escribir tu marcado en JavaScript. Se siente raro, pero se siente tan bien cuando empiezas a usarlo. Correcto. Sí.

Entonces, si tienes alguna pregunta para Tanner, puedes hacerlo en Slido.com.

Hay una pregunta de Metin Persinski, parece un buen tipo. Entonces, cuando comenzaste a aprender TypeScript, ¿cuánto tiempo te llevó aceptarlo y no sentirte ralentizado por él? Para mí, fueron como seis meses antes de que sintiera, oh, entiendo esto. Sí, honestamente, es como una cápsula de liberación retardada que tomas, ¿verdad? Al principio, estás como, ah, no estoy realmente sintiendo los beneficios. Siento que alrededor de dos semanas empiezas a ver la luz y solo sigue acelerando hasta el marcador de seis meses, ¿sabes? Todavía estoy apreciando cosas que estoy aprendiendo sobre TypeScript. Oh, por supuesto. Y todos los días hay nuevas frustraciones también. No overload matches this call. ¿Quién ha estado allí, verdad? Sí, doloroso, ¿verdad? No tengo idea de cómo resolverlo, todavía son como tres años después.

Siguiente pregunta de Golub. ¿Cuál fue el mejor momento de iluminación en tu viaje con React Table? Headless UI. Es fácil. Genial, cubierto.

Siguiente pregunta de GN. ¿Cómo convencerías a tu equipo para cambiar a TypeScript? No lo sé. Realiza una sesión de programación en pareja para refactorizar algo en varios archivos. Esa experiencia es cien veces mejor con TypeScript. Puedes cambiar una cosa y literalmente te indica en todas partes de tu aplicación que necesitas actualizar. No puedes mantener todo eso en tu cabeza. Incluso el autocompletado mejora mucho. Hay tantos beneficios. Muy bien. Pero no somos una conferencia de TypeScript. No, y esta no fue una charla de TypeScript. Quizás un poco. Así que, siguiente pregunta.

¿Cómo te mantuviste cuerdo haciendo trabajo de código abierto? Eso no es todo lo que hago. Tengo una startup. Ocupa mucho de mi tiempo también. Hago muchas cosas a la vez. Si puedo hacer una cosa que beneficie a ambas, eso es lo que hago. Tengo una familia que me distrae lo suficiente para que no me sumerja demasiado en cosas como el doom scrolling de problemas y todo eso. Sí, solo encuentra distracciones. Así que es para las preguntas que tenemos. Así que cualquier pregunta que tengas, tienes que hacerla ahora mismo. Una entrante. Imagino que fue fácil para ti encontrar ayuda con TypeScript. Dada tu red de contactos e imagen pública, pero ¿cómo podrían otras personas que no tienen tu red obtener ese beneficio? Primero, solo lee todos los docs como la TypeScript documentation es increíble. Y sabes, me di cuenta más tarde que todo lo que mis amigos me estaban ayudando a aprender, probablemente podría haberlo aprendido por mi cuenta si hubiera profundizado en el código fuente de las bibliotecas de código abierto y simplemente hubiera empezado a juntarlo.

Concédete que no creo que mucha gente necesite aprender tanto advanced TypeScript a menos que escribas una especie de biblioteca. La mayor parte del tiempo, la documentation en el manual te llevará básicamente todo el camino.

Lo que me gusta a mí, que para mí fue una revelación al empezar con React, TypeScript, es que cuando hay un error, obtienes un código de error y puedes copiarlo y pegarlo en Google y boom. Eso fue realmente fácil para mí. Solo TS y algún número y encontrarás una publicación en Stack Overflow explicando el mismo problema. A menos que sea algún tipo que no se puede asignar a otro tipo. Sí, eso es doloroso.

Bueno, eso es todo el tiempo que tenemos para preguntas y respuestas. Si quieres continuar la conversación con Tanner, puedes hacerlo en el stand de los oradores o en spatialjet. Tanner, muchas gracias. Sí. Lamento haber arruinado Jurassic Park. Nunca lo verás de la misma manera.