Remixando Cómo Donamos

La llamada a la acción también está en el mismo archivo del formulario. Eso es un gran beneficio para poder saber qué está sucediendo en una ruta. Vamos a una ruta, entonces hay un formulario. Vamos a la acción. Sabemos qué está haciendo ese formulario. También podemos agregar validación con Solve. Los formularios de múltiples pasos pueden funcionar de manera mucho más sencilla con JavaScript y con el botón de retroceso, algo que no teníamos antes. Y podemos utilizar la transición del usuario para mejorar la experiencia de los usuarios. Y así, desde estados de carga hasta interfaces de usuario optimistas. Las convenciones y la separación de responsabilidades también es otra razón por la que elegimos Remix. Los archivos de rutas ayudan mucho con la refactorización. Podemos simplemente eliminar un archivo de ruta y con eso eliminar la acción, el cargador, el componente, los enlaces, todo. También las rutas anidadas ayudan a evitar la duplicación. No necesitamos mover código a otro archivo e importarlo en muchos archivos como encabezados, a través de las rutas. Simplemente creamos un patrón, una ruta de diseño, y colocamos dentro todo lo que necesita ese encabezado y listo. Y el componente luego vive en la ruta. Los cargadores y las acciones también utilizan estándares. Y pasamos menos tiempo en la documentación de Remix y más tiempo en la documentación de Mozilla Developer Network. También significa que contratar y enseñar la pila es más sencillo. Contratamos a alguien que no conocía Remix y ella aprendió Remix para la entrevista y pasó la entrevista y otros desarrolladores enfocados en el backend pudieron aprender Remix súper rápido, en un día o menos de un día, y comenzaron a usarlo. Ahora, cómo nos migramos a Remix. Sabíamos que queríamos usar Remix, pero aún teníamos esta gran aplicación de Next. Lo que hicimos, lo primero fue que no podíamos migrar todo de una vez, así que decidimos ejecutar Remix y Next juntos. Para hacer esto, aprovechamos que Remix se puede conectar a un servidor Express y Next también se puede conectar a un servidor Express.

Además, tenemos la idea de que un archivo raíz debe contener todo lo que necesitan, al menos tanto como sea posible. Solo movemos los componentes a la carpeta 'components' de las aplicaciones si son realmente compartidos, es decir, si los usamos en casi todas las raíces o al menos en más de tres. Por lo tanto, sabemos antes de mover un componente a esta carpeta que realmente se va a utilizar en muchas partes y no está vinculado a los datos. Esto permite una refactorización sencilla de las raíces porque si todo está en la raíz, simplemente podemos eliminar la raíz y eliminar todo el código relacionado. No hay forma de que eliminemos una raíz y dejemos el componente en la carpeta 'components' porque no estamos seguros si algo más lo está utilizando. También evitamos el acoplamiento de componentes con los datos. Debido a que todos nuestros componentes compartidos solo reciben datos de las props y no de los datos. Y encontrarán exactamente lo que necesitan. Y muchos componentes simples porque si son componentes complejos, generalmente están vinculados a lo que

También utilizamos muchas rutas de recursos para diferentes cosas. Por ejemplo, generamos PDF porque tenemos que proporcionar a los usuarios un informe sobre la donación con fines fiscales. Por lo tanto, utilizamos una biblioteca de PDF de React para renderizar un React dentro de una ruta de recurso y generar un PDF. Localizamos el PDF utilizando la biblioteca Y18-next y luego, después de renderizar el PDF, enviamos una respuesta utilizando el ayudante de PDF de RemixUtils y de esta manera podemos generar un PDF dinámico con React. También utilizamos rutas de recursos para imágenes de Open Graph. De la misma manera que obtenemos parámetros de los parámetros de búsqueda de la URL, utilizamos React para renderizar un SVG como una cadena. Si el usuario espera una respuesta SVG, simplemente la devolvemos. Si no, podemos transformar el SVG a otro formato como PNG, JPG, WebP, etc., y guardar el archivo con una cabecera de tipo de contenido. De esta manera, podemos optimizar las imágenes para OpenGraph según sea necesario. RemixAdafi ha contribuido a la comunidad de Remix porque se extrajeron muchas cosas de allí. RemixUtils existe. Gracias a RemixAdafi, utilizamos useHydrated solo en el cliente, useGlobalPendingState y más cosas provienen de funciones y componentes internos. Lo utilizamos en Adafi y luego lo extraemos a RemixUtils. RemixOut nació debido a la necesidad de implementar la autenticación de Auth0. En Dafi, publiqué el primer borrador con mi intención inicial y luego, a partir de la prueba de concepto que tenemos de Remix, creamos la versión 1 de RemixOut con la estrategia de Auth0 que luego se extrajo a otro paquete y la biblioteca creció con la comunidad. RemixY18next también existe gracias a Dafi que utiliza Remix porque necesitamos localizar la aplicación. La aplicación en realidad solo está en inglés pero ya admitimos la localización. Elegimos Y18next traducido por ellos. Mi implementación inicial se publicó como un artículo. Luego extraímos la biblioteca con el código de salida. Lo utilizamos como Y18next a partir de la prueba de concepto de Dafi. Así se creó la biblioteca y la comunidad comenzó a contribuir. Eso es todo. Gracias por acompañarme. Sergio, ¿cómo estás hoy? Estoy bien. Oh, bien. Bueno, esa fue una charla increíble. Muchas gracias. Queremos pasar a Slido.

¿Cuáles son algunos de los procesos que utilizaste para realizar esos cambios incrementales? Porque te moviste de Next.js a Remix, que tienen dos APIs muy diferentes. ¿Cómo lograste mezclarlos? Bueno, lo que hicimos fue utilizar Express para ejecutar ambas aplicaciones en el mismo servidor utilizando un solo proceso, y luego tuvimos que compartir el estado de autenticación después de descubrir que mover las cosas básicamente revelaba todo desde cero en Remix, tal vez reutilizando parte de la interfaz de usuario. Afortunadamente para nosotros, porque realmente me gustan muchos de los patrones de Remix, no hicimos demasiadas cosas en el lado del cliente, como la obtención de datos, así que utilizamos GetServerSideProps. Mover de GetServerSideProps a Loader no es tan difícil como si hubiéramos utilizado otra biblioteca para consultar datos en el lado del cliente. De hecho, es interesante que casi podrías buscar y reemplazar tus GetServerSideProps con Loader y obtener los datos que necesitas para tu ruta. Me gusta eso. Sí, gran parte del código es el mismo. Solo necesitas cambiar cómo leer las cosas de la solicitud y cómo enviar las cosas en la respuesta. Pero el resto del código, la lógica real que utilizas allí, es la misma. Genial. Supongo que eso lo haría un poco más fácil.

Entonces, ¿cuáles son algunos de los beneficios que has visto al migrar de React o de Remix en tu aplicación? Tenemos archivos JavaScript mucho más pequeños en el cliente. Por lo tanto, nuestra aplicación se siente más rápida cuando navegas con esta función de precarga de enlaces. Remix puede precargar no solo el código, sino también los datos y otros activos. Entonces, si tenemos imágenes que hemos precargado, puede obtenerlas, y si tenemos un cargador en la siguiente ruta, también podemos comenzar a precargar antes de que el usuario realmente haga clic en un enlace y navegar más rápido a la otra página, incluso si estamos haciendo representación en el servidor todo el tiempo.

Sí. Entonces, tal vez tenga que ver con la forma en que el enrutador de Remix está configurado y es capaz de cargar incrementalmente algunas de esas cosas que necesitas. Sí. Sí, genial. Bien, al hacer el cambio de Next.js a Remix, mencionaste que el mejoramiento progresivo también es una de las razones. ¿Puedes explicar más sobre eso y cómo Remix maneja el mejoramiento progresivo? Sí. Para aquellos que no lo saben, el mejoramiento progresivo es esta idea de que tu aplicación funciona sin JavaScript y luego lo mejoras para que funcione mejor para las personas con JavaScript, que suele ser la mayoría de los usuarios. En nuestro caso, trabajamos con dinero y si la aplicación no funciona, es preocupante para los usuarios, ¿verdad? Tienes mi dinero ahí. Incluso si ya donaste, cuando nos das el dinero, realmente es tu dinero. Y utilizar el mejoramiento progresivo significa que si hay un error en nuestro JavaScript del lado del cliente, aún puedes verlo y usarlo. Muchas cosas, no todo, pero muchas cosas siguen funcionando con el JavaScript, como los formularios y cosas así. Por lo tanto, la mayoría de la aplicación se puede utilizar incluso sin JavaScript. Y eso es cómo el Mejoramiento Progresivo nos está ayudando. Y esto se puede hacer en Remix porque, ya sabes, Remix utiliza enlaces para navegar y el enlace es un ancla y utiliza el componente de formulario, que es una aplicación. Y todo sigue funcionando de esa manera.

En realidad, eso también tiene mucho sentido, porque estás trabajando con ese dinero. Quieres darle al usuario comentarios sobre lo que están haciendo en tu aplicación. Entonces necesitas tener ese Mejoramiento Progresivo. Es como si esto estuviera funcionando en segundo plano, pero no puedes verlo hasta que se haya terminado. Pero vamos a mostrarte progresivamente una actualización optimista con la esperanza de que esos datos regresen, ¿verdad? Sí. Genial. Ahora tenemos un par de preguntas de la audiencia. Chris dijo, ¿tuviste algún problema para convencer a tu equipo de migrar a Remix? Creo que dijiste de Next.js, y ¿cómo lo haces al principio? Comencé a pensar en convencer al equipo de usar Remix. Recién estábamos comenzando el front-end.

Construimos una prueba de concepto original con enrutadores de React configurados por Rails en tu ruta, y luego necesitábamos pasar a algo mejor. En ese momento, Remix todavía era de pago. Mi CTO no estaba convencido de usarlo porque era de pago, lo que significa que no todos lo conocerían. Sería más difícil contratar a alguien que conozca el framework. Comenzamos a usar Next por eso. Contribuí, uno de mis compañeros de trabajo es uno de los autores originales de NextJS. Comenzamos con Next, luego decidimos migrar a Remix porque comenzamos a tener problemas con el rendimiento de la aplicación. Las páginas de inicio del frontend eran geniales, pero lo que estás en la parte de la aplicación no es tan bueno, especialmente si no usas la mayoría de las cosas del lado del cliente, y eso fue lo que convenció al CTO de probar Remix. Lo probó en la semana entre Navidad y Año Nuevo. Después de eso, regresó de Año Nuevo y básicamente me dijo, sí, Remix es genial. Esta es mi lista de cosas. Aunque me gusta, vamos a migrar a nuestro código, para hacerlo. Es como si no quisieran cambiar a Remix, solo muéstraselo, haz que lo prueben, ¿verdad? Sí, creo que esa es la mejor manera de convencer a alguien de usarlo. Solo pruébalo, muéstralo. Genial, ¿tu aplicación es un monorepo? No es un monorepo, bueno, tenemos un monorepo, pero mi aplicación tiene el frontend en una carpeta que tiene todo del frontend. No se comparte con otros.

De acuerdo, hagamos una última pregunta de Adrian. ¿Cuántas personas están trabajando en la base de código que migraron? Déjame contar. Tenemos 1, 2, 3, 4, 5, 6, 7, 8 personas. Genial. Es un equipo bastante pequeño, ¿verdad? Es bastante fácil convencer a las personas. Y creo que eso es algo que siempre he dicho, como, si estás hablando con un interesado o alguien que no es desarrollador sobre la migración, algo así, quieres asegurarte de usar sus términos y expresarlo de diferentes maneras a como lo harías si estuvieras hablando con un desarrollador. Así que creo que eso es otra cosa a tener en cuenta si estás tratando de convencer a tu empresa de migrar. Sí, además, cuando comenzamos, éramos cuatro personas. Contratamos al resto después de que comenzamos la migración. Y luego Remix, súper rápido. Uno de ellos lo aprendió para la entrevista en una semana, como una semana y dos días, algo así. Ese es otro gran punto, que Remix no tiene muchas cosas específicas de Remix, y utiliza la plataforma web. Así que realmente solo estás aprendiendo JavaScript en su mayor parte. Y React. Creo que eso hace que sea más fácil contratar a alguien para trabajar en Remix que contratar a alguien para trabajar en cualquier otra cosa. No necesitas aprender demasiado, solo aprendes sobre la web en sí misma. Sí, genial. Bueno, creo que eso es todo el tiempo que tenemos para preguntas. Muchas gracias por responder, Sergio, y gracias por unirte hoy. Gracias. Muy bien. Nos vemos.