Construyendo una Biblioteca de Componentes Personalizada - Rápido

Hola a todos. Soy TJ y hoy quiero hablarles sobre cómo construir bibliotecas de componentes personalizadas rápidamente. Y con bibliotecas de componentes me refiero básicamente a una serie de controles de interfaz de usuario que pueden ser desde botones y campos de entrada hasta cosas más complejas como selectores de fecha y autocompletados. Personalmente, he estado construyendo bibliotecas de componentes como esta durante mucho tiempo, tal vez demasiado. En el pasado, fui miembro del equipo de jQuery UI, si lo recuerdan. Todavía tengo este sombrero genial para mostrarlo. Y más recientemente, ahora soy miembro del equipo de KendoUI. Y debido a que he estado haciendo esto durante muchos años, he desarrollado una serie de opiniones o ideas interesantes sobre las bibliotecas de componentes que voy a comenzar a compartir, porque creo que les resultarán interesantes y útiles. Y luego pasaré a mostrar cómo pueden poner en práctica estas ideas y darles algunas recomendaciones sobre cómo pueden construir su propia component library. Para comenzar, mi primera opinión o idea interesante es que creo que cada empresa, creo que su empresa debería tener su propio conjunto estándar de controles de interfaz de usuario. Y la razón de esto es realmente la consistencia. Aplicar cierta consistencia visual para que en lugar de tener 30 diseños de botones diferentes, creen un botón en una component library que tenga la única forma correcta de construir botones para su organización. Pero también obtienen consistencia en términos de tecnología. Una component library es una forma de forzar a elegir un conjunto limitado de tecnologías que desean promover en toda su organización. También obtienen consistencia en términos de accesibilidad. La accesibilidad puede ser difícil, pero si pueden hacerlo bien dentro de los componentes de su biblioteca, pueden extender esos beneficios de accesibilidad a otras partes de su organización. Así que creo que cada empresa debería tener su propia biblioteca de componentes de interfaz de usuario. Y también creo que las empresas no deberían construir las partes más difíciles de esas bibliotecas por sí mismas. Y con componentes complejos aquí, no me refiero a cosas como campos de entrada y botones. Me refiero a las cosas más difíciles. Los selectores de fecha, las casillas de verificación, los autocompletados, las rejillas de datos, cosas así. Porque estos componentes son más difíciles de lo que pueden parecer al principio. Tomemos el selector de fecha, por ejemplo. Y no solo tienes que construir un calendario aquí. Cuando estás construyendo un componente reutilizable, debes tener en cuenta muchas otras cosas. ¿Cómo vas a hacer que esto sea accesible? ¿Cómo te asegurarás de que funcione como esperas en dispositivos móviles, que TypeScript funcione, que documentarás todo esto para que otras personas entiendan lo que hiciste y que sea extensible y todas estas cosas. Y estos son problemas solucionables. Tú, que estás viendo esto, puedo verlo a través de la cámara. Eres una persona inteligente. Estos son problemas

puedes resolver. Pero como desarrollador de software, también tu tiempo es muy valioso. Tu tiempo casi siempre se invierte mejor en cosas que son únicas para lo que tu negocio está haciendo, en lugar de reinventar la rueda y resolver algunos de estos problemas de componentes de UI que han sido resueltos por muchas bibliotecas durante mucho tiempo. Es simplemente un mejor uso de tu tiempo. Así que creo que las empresas deberían tener sus propias bibliotecas de componentes. Creo que no deberías construir las partes más difíciles de estas bibliotecas tú mismo. Y también creo que deberías inclinarte hacia el uso de componentes específicos de un framework que te guste usar, como un framework como Angular, Vue y React, en lugar de un framework que sea agnóstico al framework y que intente funcionar en todos los casos. Ahora, esta es una opinión controvertida que comparto con Brandon Dale, un ex miembro del equipo de React. Creo que él expresó su explicación de manera más elegante, así que solo tomé una cita de él. Él dice que la compatibilidad siempre tiene un costo, y ese costo siempre va a ser algo como el rendimiento o el tamaño del paquete o la ergonomía del framework. Y en la mayoría de los casos, esas cosas van a ser más importantes que la compatibilidad en sí misma. Ahora, esto es algo en lo que creemos firmemente en el equipo de Kendo UI, tan firmemente, de hecho, que hemos construido cuatro bibliotecas de componentes separadas para diferentes frameworks. Y hacemos esto porque, como puedes imaginar, es bastante trabajo porque nuestros usuarios nos dicen consistentemente que tienen más éxito, son más productivos cuando utilizan componentes que están construidos específicamente para su framework de elección.

Así que creo que las empresas deberían tener su propio conjunto estándar de componentes de UI. Creo que no deberían construir las partes más difíciles de eso por sí mismas. Y creo que, en la mayoría de los casos, deberías inclinarte hacia el uso de componentes que estén construidos para tu framework, para tu cadena de herramientas de elección. Entonces, ¿cómo llevas estas cosas a la práctica? Bueno, recomiendo comenzar configurando un entorno de desarrollo que puedas utilizar para construir componentes en un lugar que esté fuera de cualquiera de tus aplicaciones existentes. Lo que me gusta hacer es tener un entorno donde pueda desarrollar los componentes y también tener una aplicación de demostración donde pueda probar esos componentes en una aplicación en ejecución y ver cómo funcionan. Y también tener algunos scripts que me permitan tomar mis componentes cuando estén listos, empaquetarlos, agruparlos y distribuirlos para que se puedan utilizar en toda mi organización. Y proporcionaré un enlace, si estás interesado en esto, al final de esta charla, para que si quieres ver mi flujo de trabajo preferido en detalle, puedas seguirlo. Pero comienza por tener este entorno de desarrollo. Y a partir de ahí, recomendaría tener una biblioteca de referencia a la que recurrir para algunos de estos widgets más complejos o cualquier cosa que no quieras construir tú mismo. Y para eso, buscaría algunas cosas en esta biblioteca de terceros. Comenzaría buscando exhaustividad. No quieres estar tomando componentes de cinco lugares diferentes en Internet y tratando de unirlos. Por lo general, tendrías una biblioteca que proporcione la mayor cantidad posible de esto. Quieres buscar accesibilidad porque, nuevamente, quieres incorporar una buena accesibilidad a tus componentes por defecto. Quieres buscar componentes específicos del framework o, al menos, algo que funcione muy bien con la cadena de herramientas que te gusta usar. Y también quieres buscar extensibilidad. Lo bueno de una biblioteca de componentes es que las personas encontrarán formas de usar tus componentes de muchas maneras diferentes. Por lo tanto, quieres encontrar componentes de terceros que sean muy adaptables, que puedas ajustar y personalizar y cambiar cosas en cada pequeño

pieza de ellos. Así que recomendaría tener esta biblioteca de terceros, esta biblioteca de terceros de referencia. Y luego recomendaría crear envoltorios de cualquiera de los componentes que desees usar de estos componentes de terceros. Y la razón de esto, y solo mostraremos un ejemplo. Entonces, si quieres usar el selector de fechas de react de Kendo. Bueno, en lugar de animar a los desarrolladores a usar directamente la API del selector de fechas de react de Kendo, en su biblioteca de componentes, podrías crear un envoltorio de ese selector de fechas con tu propia API. Y la razón de esto es nuevamente, para mantener la consistencia, porque tienes este envoltorio, ahora tienes un lugar donde puedes implementar consistentemente cosas para los selectores de fechas en toda tu organización. Entonces, digamos que tus diseñadores vuelven y dicen, `Oye, necesitamos que todos nuestros selectores de fechas tengan un pequeño ajuste visual`, podemos decir, `Oh, hey, tengo este envoltorio. Puedo aplicar consistentemente este nombre de clase. Puedo hacer algunos ajustes de CSS. Y todavía tengo este control donde puedo realizar cambios consistentes en este componente en toda mi organización sin tener que construir la parte difícil de estos componentes ellos mismos. Entonces, para resumir nuevamente, recomendaría comenzar simplemente configurando un entorno de desarrollo, fuera de tus aplicaciones existentes. A partir de ahí, elige una biblioteca de referencia para construir o para traer componentes de terceros más complejos. Y luego crea envoltorios de estos componentes de terceros que traes. Y realmente, si solo sacas una cosa de esta charla, en general, diría que tu empresa debería tener un conjunto estándar de componentes de UI. Hay muchos beneficios, pero está totalmente bien, incluso preferible, construir gran parte de esa funcionalidad sobre una biblioteca existente. Espero que esto te haya parecido interesante. Si es así, si quieres aprender más, puedes ir a bitly/components-fast. Allí tengo el entorno de desarrollo completo del que hablé en una diapositiva anterior, así como algunos artículos que explican en detalle los argumentos que presenté aquí hoy. Así que mi nombre es TJ Ventol. Siéntete libre de contactarme en Twitter desk si tienes alguna pregunta o hacer preguntas a través de la conferencia también. Gracias.