Migración Compleja de React: Nuevas Soluciones a los Problemas de una Base de Código Antigua

This ad is not shown to multipass and full ticket holders
JSNation US
JSNation US 2025
November 17 - 20, 2025
New York, US & Online
See JS stars in the US biggest planetarium
Learn More
In partnership with Focus Reactive
Upcoming event
JSNation US 2025
JSNation US 2025
November 17 - 20, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

En 2020, Rangle se asoció con el equipo de Survey Monkey para migrar una base de código antigua a React. Los productos digitales de primera clase de Survey Monkey estaban siendo frenados por la fragmentación y la complejidad, lo que generaba mucho retrabajo y esfuerzo desperdiciado para sus equipos de ingeniería. Trabajando juntos, implementamos una serie de cambios en los procesos y la arquitectura que redujeron la complejidad y mejoraron los flujos de trabajo, permitiendo que nuestro equipo combinado entregara resultados con rapidez y de manera consistente, incluso al comienzo de la colaboración. Estas no fueron soluciones de talla única, sino soluciones únicas y adaptadas a las necesidades de los equipos de ingeniería y producto. El éxito del proyecto se debió a los equipos motivados de Survey Monkey que estaban: 1) Listos para aceptar el cambio; 2) Capaces de mantener un enfoque firme en los resultados; y 3) Comprendieron fácilmente la complejidad del proyecto.


Esto nos permitió co-crear algunas soluciones no intuitivas que los ingenieros de empresas similares a nivel empresarial deberían conocer.

This talk has been presented at React Summit Remote Edition 2021, check out the latest edition of this React Conference.

FAQ

ServingMonkey es uno de los primeros ejemplos de software como servicio en el mercado. Es un pionero del Valle del Silicio que ha ayudado a dar forma a la industria del SaaS, cuenta con alrededor de 1,200 empleados y más de 17 millones de usuarios. Sus productos incluyen software líder en encuestas y todo tipo de investigación de mercado. Durante la pandemia de 2020, tuvo un impacto significativo al empoderar la comunicación y el compromiso empresarial.

El equipo de Silver Monkey enfrentó desafíos significativos debido al tamaño y la complejidad de las bases de código que estaban modernizando. Utilizaron la mejor tecnología disponible y desarrollaron prácticas de DevOps maduras para manejar la situación.

La solución fue la creación de una biblioteca de dominio que concentraba todo lo relacionado con uno de los dominios más importantes en SurveyMonkey, la pregunta. Esto ayudó a los equipos de características a ser más productivos y a crear una apariencia y sensación cohesivas en la aplicación.

La arquitectura de tres niveles consistía en separar la biblioteca de dominio en tres partes: los componentes visuales puros del dominio, la lógica de negocio específica del tipo de pregunta y la interfaz con las necesidades específicas de las características. Esto permitió a los equipos de características implementar interfaces de usuario relacionadas con las preguntas sin un profundo conocimiento de los detalles de cada tipo de pregunta.

La estrategia utilizada fue mantener una arquitectura evolutiva que soporte cambios y concilie dichos cambios sin perder cohesión. Esto permite adaptarse a nuevas exigencias y tecnologías sin necesidad de rehacer completamente el sistema cada cierto tiempo.

La migración del código en SurveyMonkey se manejó inicialmente por dominio para comprender y centralizar la complejidad existente, y posteriormente involucrando a los equipos de características en la nueva estructura usando la biblioteca de dominio para mejorar la cohesión y la eficiencia en el desarrollo de nuevas características.

Jason Santos
Jason Santos
32 min
14 May, 2021

Comments

Sign in or register to post your comment.
Video Summary and Transcription
Esta charla analiza los desafíos de lidiar con código heredado y los beneficios de las asociaciones en el desarrollo de software. Destaca el estudio de caso de ServingMonkey y Rango, mostrando las soluciones implementadas para modernizar sus bases de código. La charla enfatiza la importancia de la arquitectura de tres niveles y la propiedad colectiva para lograr cambios sostenibles. También aborda los desafíos de migrar a nuevas tecnologías y la necesidad de considerar el valor comercial al tomar decisiones tecnológicas. La charla concluye con ideas sobre cómo evitar que el código se convierta en heredado y los beneficios de la migración y colaboración de código.

1. Introducción a Legacy Code y Partnership

Short description:

Imagina tener código heredado que ya no cumple tus necesidades. Descubres nuevas tecnologías y tu equipo está ansioso por adoptarlas. A pesar de algunas discrepancias, sigues entregando y evolucionando. Avancemos rápidamente 10 años y tienes un nuevo código heredado. Mi nombre es Jason Santos y estoy aquí para hablar sobre nuestra asociación con ServingMonkey y el increíble trabajo realizado por nuestro equipo de ingenieros.

Buenas tardes a todos, por supuesto, no a todos, solo a aquellos que están donde realmente es tarde, para todos los demás, sea cual sea la hora del día. Avísenme si han visto esto antes, ¿verdad? Imagina que tienes tu código heredado y no te está brindando toda la velocidad que necesitas, ¿verdad? El mundo ha cambiado, puedes sentirlo en tu estilo, puedes sentirlo en tu compilación, puedes olerlo en el código. Luego encuentras nuevas tecnologías y tu equipo está ansioso por adoptar eso. Todo es bastante sorprendente, puedes hacer cosas que antes no podías hacer y sí, excepto que no te resultan muy familiares. Dejas que tus equipos decidan qué usar. En algún momento, la mejor tecnología gana, todos están contentos y al menos puedes comenzar a entregar tus características. El negocio siempre lo hace, entregas, el negocio quiere cosas nuevas, cosas más brillantes, y en algún momento hay una pequeña discrepancia. Algunas tecnologías son diferentes aquí y allá, han aparecido diferentes formas de hacer las cosas, tu equipo crece, las características crecen y comienzas a ver discrepancias aquí y allá, pero al menos estás entregando y las cosas están evolucionando y creciendo. Avancemos rápidamente 10 años y tienes un nuevo código heredado. Mi nombre es Jason Santos y así solía vestir para impresionar a los clientes, quiero decir cuando realmente podías conocerlos cara a cara y trabajaba en Rainbow. Probablemente sepas quiénes somos y estoy aquí para hablarles un poco sobre las cosas increíbles que hicimos en asociación con ServingMonkey. Pero no te hagas la ilusión de que he hecho todas estas cosas yo solo, ¿verdad? Hay un grupo increíble, increíble de personas que me ayudaron mucho y que hicieron la mayor parte del trabajo en realidad, mientras solo te mantenían y se llevaban el crédito. Y en serio, son algunos de los ingenieros más fantásticos y más inteligentes con los que he trabajado.

2. Introducción a ServingMonkey y Rango

Short description:

Vamos a hablar sobre ServingMonkey y Rango, los problemas que enfrentamos, las soluciones que encontramos y mostrarles algo de código. ServingMonkey es un pionero en software como servicio, con 1,200 empleados y 17 millones de usuarios. Work4Rainbow es conocido por crear nuevos productos y ayudar a las empresas a modernizarse. En asociación con Wrangell, Silver Monkey buscó modernizar sus bases de código utilizando la última tecnología y prácticas de DevOps. Los desafíos incluyeron el tamaño y la complejidad de los productos. La solución involucró el desarrollo de una biblioteca de dominio para simplificar el código de las características y garantizar una apariencia y sensación cohesivas.

Bueno, pero primero permítanme contarles un poco de qué trata esta presentación. Vamos a hablarles sobre qué es exactamente ServingMonkey, qué es Rango exactamente, y cuáles son los problemas a los que nos enfrentamos. Vamos a hablarles un poco sobre qué tipo de soluciones encontramos para resolver esos problemas. Y, por supuesto, les mostraré algo del código. Bien, ¿qué es exactamente este producto que estamos modernizando? ServingMonkey tiene uno de los primeros ejemplos de software como servicio en el mercado. Es un pionero del Valle del Silicio que ayudó a dar forma a esa industria. Tiene alrededor de 1,200 empleados y más de 17 millones de usuarios. Tienen líneas de productos que incluyen software líder en encuestas y todo tipo de investigación de mercado, como encuestas rápidas, análisis competitivo, retroalimentación de clientes, lo que sea. Tienen una gran presencia en empresas enterprise de todo el mundo y tuvieron un impacto masivo durante la pandemia de 2020. Empoderaron la comunicación entre empresas, el compromiso, todas esas cosas buenas que ahora nos vemos obligados a hacer desde nuestras cocinas. Sí, es genial tener un gran software para hacer eso. Ahora, para la autopromoción, Work4Rainbow, ¿verdad? Somos bastante conocidos en la escena del desarrollo de software. Fuimos pioneros en la web moderna y tenemos una presencia constante en cumbres como esta. Nuestro equipo se destaca en la creación de nuevos productos y en ayudar a las empresas a modernizarse y volverse más digitales. Probablemente nos conozcan. Hemos estado patrocinando y presentando en muchos eventos tecnológicos desde 2013, y somos una consultoría con sede en Toronto, Canadá, pero ahora tenemos presencia en varios países. En el último trimestre de 2020, Silver Monkey se asoció con Wrangell en un esfuerzo por modernizar algunas de sus bases de código en esta nueva plataforma tecnológica que estaban desarrollando. El equipo de Silver Monkey se enfrentaba a muchos desafíos para llevar a todos sus equipos de características a esa nueva plataforma web, y el mayor desafío podría ser el tamaño mismo de ella, y utilizaron la mejor tecnología que estaba disponible, y la estaban construyendo con algunas de las mejores y más maduras prácticas de DevOps que hemos encontrado. Parecía que estaban preparados para el éxito. Además, habían desarrollado este increíble sistema de design, muy cohesivo y completo, basado en sólidos principios de design, e implementado como una biblioteca de componentes de React con todo incluido, y la guinda del pastel. Sin embargo, ahora que necesitaban migrar, tenían grandes expectativas sobre lo que esa migración iba a lograr. Y juntos, Rangel y Sarumaki idearon algunos ajustes finos y parte de la planificación en torno a cómo se iban a lograr estos objetivos. Todo comenzó con la declaración del problema, ¿verdad? ¿Cómo podemos asegurarnos de que esta migración sea exitosa y de que podamos aprovechar todos estos beneficios al final? Comenzamos con los desafíos, ¿verdad? El tamaño mismo de sus productos, la alta sofisticación de los mismos, dificultaba realmente asegurarnos de que todo encajaría perfectamente. La complejidad local era el elemento clave, ¿verdad? Se trataba realmente de tratar de averiguar cómo cada una de estas piezas altamente sofisticadas se uniría como una sola plataforma. La solución fue la biblioteca de dominio. Madurar y lanzar una llave inglesa que era el sistema de design de SurveyMonkey fue una buena estrategia para ayudar a los equipos de características a ser más productivos y crear una apariencia y sensación cohesivas en la aplicación. Pero eso fue solo el comienzo. Simplificar el código de las características solo era posible si parte de la lógica de negocio y presentación en las propias características se compartían. Cuando se usaban los mismos conceptos en diferentes lugares, el código específico del dominio se encargaría de esa sección. El concepto está inspirado en el diseño orientado al dominio y ayudó a dar forma a una biblioteca que podría concentrar todo lo relacionado con uno de los

3. Ejecución y Arquitectura de Tres Niveles

Short description:

Ahora, en cuanto a la ejecución, dividimos el equipo en dos grupos: desarrolladores de React y alineación con los equipos de características. Refinamos el modelo de gobierno y eliminamos los silos de conocimiento. La arquitectura de tres niveles separó la biblioteca de dominio en componentes visuales, lógica de negocio e interfaz de características. La solución se implementó como tres paquetes internos de NPM. La visualización personalizada y el tema se lograron a través de archivos separados. Las visualizaciones son componentes no visuales que mapean el uso a componentes visuales reales.

uno de los dominios más importantes en SurveyMonkey, la pregunta. Ahora, pasemos a la parte más concreta, la ejecución. Primero, el proceso. Dividimos al equipo en dos grupos diferentes, permitiendo que los desarrolladores de React comenzaran a entregar rápidamente, y al mismo tiempo, otro grupo comenzó a crear las relaciones y la alineación con los equipos de características dentro de SurveyMonkey para ayudar a diseñar las APIs y los puntos de integración. Las dos pistas se ejecutaron de forma independiente, lideradas por diferentes arquitectos de soluciones que mantuvieron un contacto constante, un equipo, un objetivo, pero con la capacidad de concentrar el enfoque en las dos dimensiones. En el lado del sistema de diseño, hemos podido refinar y validar la mayor parte del modelo de gobierno que empoderó a los equipos de características y al equipo de la biblioteca de dominio para seguir contribuyendo a ese sistema de diseño y mantenerlo cohesivo. Al mismo tiempo, al contactar a los propios equipos de características, pudimos eliminar algunos de los silos de conocimiento y crear una comprensión común de la estructura y de los problemas. Los nombres no eran muy importantes, pero necesitaban estar alineados. Lo importante era que, con las abstracciones en su lugar, no solo podemos comunicarnos de manera más eficiente, sino que ahora podemos remodelar esas mismas abstracciones como un solo equipo. Surgió un patrón como una buena manera de dar a todo este sistema de integración la flexibilidad que necesitaba y asegurar la separación de responsabilidades que permitiría a todos los equipos avanzar con la biblioteca de dominio, la arquitectura de tres niveles. Inspirada en el patrón de capacidad, consistía en separar la biblioteca de dominio en tres partes. Los componentes visuales puros del dominio, la lógica de negocio específica del tipo de pregunta y la interfaz con las necesidades específicas de las características. La mayoría de los mecanismos se implementaron utilizando contextos de React y TypeScript y el objetivo era asegurarse de que los equipos de características pudieran implementar interfaces de usuario relacionadas con las preguntas sin un profundo conocimiento de los detalles de cada tipo de pregunta. Así es como implementamos la solución. Se entregaron tres paquetes diferentes como paquetes internos de NPM y uno de ellos, los internos de la pregunta, contenía solo los componentes visuales específicos del dominio. Otra biblioteca, la de definiciones de preguntas, contenía la lógica de negocio y las tarjetas de tipo específicas de cada uno de los más de 23 tipos de preguntas admitidos por las aplicaciones de SurveyMonkey. El tercero, los paquetes de preguntas, incluía los proveedores de capacidad y las visualizaciones que eran en realidad la conexión entre esos dos. Eran fachadas específicas de características que permitían a los equipos de características inyectar comportamientos y visualizaciones personalizadas en las visualizaciones del dominio.

Bien, suficiente charla, veamos algo de código. Este es uno de los componentes más pequeños, es muy pequeño pero puede mostrarte el patrón. Es una de las cosas clave que tuvimos que admitir aquí y una de las razones por las que algunos de estos componentes eran muy específicos del dominio fue la visualización personalizada, como la capacidad de tematizarla de manera diferente en tiempo de ejecución. Logramos eso al tener este archivo separado junto a cada componente que le daba un estilo específico pero que también cambiaba la forma en que funcionaba el estilo en función del tema que era inyectado por el usuario final. Este es un componente ligeramente diferente pero sí, todavía muy básico. Es diferente de la versión del sistema de diseño del mismo componente debido a la capacidad del usuario final de tematizarlo. Esto es el resto. Es una entrada básica y también una de las primeras iteraciones. Los componentes visuales son de nivel 3 y esto es de nivel 1. Este es un ejemplo de una visualización. Las visualizaciones son componentes no visuales a pesar de su nombre. Están diseñadas para ser una de las cosas más fáciles de escribir porque tienes muchas de ellas. Su estructura está diseñada para mapear realmente el uso al actual

4. Arquitectura Evolutiva y Propiedad Colectiva

Short description:

La estrategia se centró en hacer que el código que se escribiría muchas veces fuera extremadamente fácil de escribir. Esto se logra a través de un proveedor de capacidades y una lista de visualizaciones. La arquitectura evolutiva permite cambios sostenibles sin perder cohesión. El feedback positivo de los equipos de ingeniería y la propiedad colectiva de la arquitectura han sido clave para el éxito del enfoque.

componentes visuales y mapean las propiedades y, si es necesario, mantienen algún estado. También fue uno de los más difíciles de nombrar. Puedes ver el resto aquí. El campo de pregunta de caja de texto único es un componente visual de nivel tres y puedes ver que la visualización mapea algunas de las propiedades externas que son la forma en que la característica las va a llamar a las internas en el componente visual. La última parte es la declaración de visualización que ayuda al motor general a seleccionar qué visualización es adecuada para cada capacidad y tipo de pregunta.

Entonces, uno de los aspectos más importantes de la estrategia fue asegurarse de que el código que se iba a escribir muchas veces fuera extremadamente fácil de escribir. Para ello, creamos un proveedor de capacidades. Nos aseguramos de que el usuario final no tuviera que pasar mucho tiempo preparando los tipos y configurando parámetros y cosas así. Para eso creamos un montón de ayudantes, como un montón de ayudantes que permitían a alguien simplemente usar esta fábrica aquí con una lista de visualizaciones y luego TypeScript inferiría los tipos para el proveedor de capacidades externas basado en las visualizaciones seleccionadas. Ahora veamos un uso típico aquí. Así es como lo usarías en el código de la aplicación. Obtendrías el proveedor de capacidades en algún lugar de tu código y dentro de él, entre todos tus otros componentes visuales, tendrías un único controlador de pregunta. El controlador de pregunta única sería reemplazado por la visualización apropiada dependiendo de cómo se configurara la pregunta en tiempo de ejecución. Por ejemplo, en este caso, tienes una caja de texto única que se renderizará como una caja de texto única y si cambias a una caja de comentarios, cambiará todo lo que se pueda cambiar en función de los datos que están dentro del tipo de pregunta. El propio tipo de pregunta está en el nivel dos y determina qué se puede cambiar en cada una de estas cosas. La idea aquí es que este es un ejemplo de una arquitectura evolutiva, ese es el concepto principal de esta solución, ¿qué es una arquitectura evolutiva? Es una arquitectura que puede soportar cambios y conciliar esos cambios sin perder cohesión. Es el antídoto para tener que hacerlo de nuevo en 10 años. ¿Verdad? Esta migración aún está en curso, pero podemos ver algunos resultados muy importantes del enfoque. El principal puede ser la respuesta de los equipos de ingeniería. Recibimos muchos comentarios positivos y algunos de los ingenieros realmente se involucraron en la oportunidad de entender lo que estaba sucediendo allí. Entonces, una de las cosas que realmente intentamos impulsar fue crear esta propiedad colectiva de la arquitectura, asegurarnos de que todos pudieran contribuir a ella y plantear sus problemas para que pudiéramos acomodarlos. Es muy importante tener esa flexibilidad, de lo contrario, terminas resolviendo problemas pero no los problemas correctos. Bueno, ahora lo único que falta son los bonos de mono. ¿Cómo llamas a un grupo de monos muy jóvenes que son hermanos y te gritan una advertencia todo el tiempo? ¡Monjes! Bueno, gracias a todos. Espero que les haya gustado la presentación. Si quieren saber más, únanse a mí para la sesión de preguntas y respuestas. Parece que en cuanto a la pregunta de cuánto tiempo tiene el código más antiguo que tienen que mantener en su día a día, parece que el ganador es de cinco años con un 38 por ciento, y el siguiente, el segundo lugar, es de menos de tres años. Así que entre tres y cinco años, supongo. ¿Qué opinan al respecto? Sí, eso es bastante interesante porque, como cinco años en JavaScript, es mucho tiempo. Significa que probablemente temes tener que hacer ciertas cosas porque probablemente serán más difíciles en ciertas partes de tu código que en otras partes de tu código.

5. Desafíos del Código Heredado

Short description:

Tener código heredado que ya no cumple con tus necesidades puede ser un gran desafío. Es posible que te veas obligado a reconstruirlo para adaptarlo a los requisitos modernos. El proceso de migrar a nuevas tecnologías y prácticas puede ser difícil, especialmente cuando se trata de una base de código que ha estado en uso durante mucho tiempo.

Y te estás perdiendo oportunidades. La gente te pide que hagas cosas y tú te quedas pensando. Eso es difícil. Y es un gran desafío, ¿verdad? Cuando tienes este código en el que dependes para generar valor para el negocio, no quieres pasar todo el tiempo reconstruyéndolo. Pero en algún momento te verás obligado a hacerlo porque hay otras cosas que quieres hacer que dependen de que ese código sea más moderno. Sí, eso es seguro. Te lo puedo decir porque en el pasado solía trabajar en una startup y en realidad fuimos uno de los primeros en adoptar React, diría que hace casi ocho años. Y comenzamos con Create Class. Usamos mixins y todo, ¿verdad? Como el azúcar, y de repente tuvimos que pasar a usar clases, y también teníamos pruebas unitarias, y todo era un desastre. También queríamos pasar a TypeScript. Y fue, ¿cómo puedes hacer todo al mismo tiempo? Y fue realmente, realmente difícil. O tenías que reescribir todo o, no sé, hacer algo como modos de código y todo eso. Y solo tenía tres años. Así que cinco años todavía parece mucho también. Pero veo que incluso 10 años, se vuelve cada vez más difícil de mantener después de un tiempo, especialmente para JavaScript, como tú

6. Aproximación a las Decisiones Tecnológicas y la Modernización

Short description:

Aproximarse a las decisiones tecnológicas únicamente desde una perspectiva técnica puede que no siempre sea el enfoque correcto. Es importante considerar el valor que se agrega al negocio en general e identificar oportunidades de mejora. Esto puede dar lugar a conversaciones sobre la modernización de la base de código.

dijo. Sí, sí. Y eso es lo que pasa, ¿verdad? Si intentas abordarlo desde una perspectiva tecnológica, como mirar estas tecnologías completamente nuevas y querer usarlas, a veces no es la decisión correcta, ¿verdad? Necesitas realmente pensar en el valor que estás agregando al flujo de valor general del negocio. ¿Y cuáles son esas oportunidades para hacerlo, que están faltando? Porque así es como obtienes tu presupuesto de migración, por así decirlo, ¿verdad? Como llegar allí. Podríamos simplemente hacer eso. Sería genial para este producto y para nuestros usuarios. Y ahí es donde comienza la conversación para modernizar realmente la base de código.

QnA

Preguntas y Arquitectura de Tres Niveles

Short description:

Exactamente. Hablando de preguntas, tenemos bastantes preguntas. Comenzaré con una de Popling. ¿Se puede considerar el desplazamiento como una primera entrada? Tomemos otra de Tom HD. ¿Cómo llegaron a los tres niveles de arquitectura? Los tres niveles, comenzamos con lo más simple posible que pudiera funcionar. Construyamos los componentes visuales y las personas los usarían como quisieran. Luego comenzamos a pensar en las restricciones que siempre deberían cumplirse. Hay una oportunidad perdida allí. De acuerdo, ustedes dijeron que querían esto, que querían que las características de estas aplicaciones se expandieran fácilmente. ¿Cómo podemos reducir el costo para estos desarrolladores? Podríamos eliminar algo de ellos, pero ahora les damos la capacidad de hacer algo realmente rápido. Y al final, descubrimos que esta complejidad que se acumulaba dentro de la biblioteca de dominio debía ser dividida.

Exactamente. Hablando de preguntas, tenemos bastantes preguntas. Comenzaré con una de Popling. ¿Se puede considerar el desplazamiento como una primera entrada? ¿Considerarse qué? ¿Se puede considerar el desplazamiento como una primera entrada? Eres el experto. No entiendo exactamente la pregunta, pero tal vez, Popling, si puedes agregar más información, lo abordaremos.

Tomemos otra de Tom HD. ¿Cómo llegaron a los tres niveles de arquitectura? Sí, está bien. Podemos abordar el desplazamiento después. Creo que lo entendí, pero los tres niveles, comenzamos con lo más simple posible que pudiera funcionar. Construyamos los componentes visuales y las personas los usarían como quisieran. Esa es la primera idea. Luego comenzamos a pensar en las restricciones que siempre deberían cumplirse. Si eso sucede, algunas cosas podremos hacerlas y otras no. Y lo que no podrías hacer si todos pudieran consumir solo componentes visuales en todas partes. No podrías estandarizar la forma en que abordan la recopilación, obtención de datos del backend de GraphQL y la estructura de estos datos. ¿Cómo harían las validaciones, cómo harían las transformaciones, todas estas cosas? Hay una oportunidad perdida allí. La pregunta siempre debe ser: ¿De acuerdo, qué estás dispuesto a sacrificar a cambio de la capacidad de centralizar estas cosas? Ahora vas a construir un poco más de complejidad, pero vas a obtener algo. Así que comenzamos a tener esas conversaciones. De acuerdo, ustedes dijeron que querían esto, que querían que las características de estas aplicaciones se expandieran fácilmente. ¿Cómo podemos reducir el costo para estos desarrolladores? Podríamos eliminar algo de ellos, pero ahora les damos la capacidad de hacer algo realmente rápido. Esto será como reducir su complejidad y darles un poco menos de opciones de personalización. Y en algún momento comenzamos a tener problemas. Como, de acuerdo, ahora en esta situación aquí, a medida que comenzamos a crear un inventario de todas las cosas que debían hacerse. En algún punto de la aplicación, como, de acuerdo, estas personas realmente necesitan personalizar esta parte aquí. Así que ahora les damos un mecanismo. Pero si les damos un mecanismo, estamos agregando complejidad nuevamente. Y ese intercambio, de acuerdo. Y la conversación continúa. Y al final, descubrimos que esta complejidad que se acumulaba dentro de la biblioteca de dominio

Shaping Three-Tier Architecture and Scrolling

Short description:

Diseñamos el código en una arquitectura de tres niveles, separando los componentes visuales, la lógica empresarial y la integración. El desplazamiento puede ser manejado por la biblioteca o la aplicación, dependiendo del contexto. No tenemos un repositorio Git público con un ejemplo de arquitectura jugable.

necesitaba ser dividido. Como, porque eran diferentes tipos de cosas que nacieron allí. Como, está bien, tenemos los componentes visuales, pero deben estar libres de lógica empresarial. De lo contrario, es un poco loco. Dependiendo de la escala, por supuesto. Como, ¿dónde va esta lógica empresarial? ¿Pertenece esta lógica empresarial a react? Probablemente no. Entonces, en este punto, comenzamos a dar forma a esto como una cosa de tres niveles. Como, tenemos la parte de integración, tenemos la lógica empresarial aislada y ahora tenemos los componentes visuales y organismos orientados a los negocios que las personas podrían usar vinculados a estas otras cosas.

De acuerdo. Muy bien. Sigamos adelante, porque tenemos muchas preguntas. Permíteme tomar la otra. ¿También puedes hacer lo mismo con el desplazamiento, además de lo que dijiste? Permíteme leer de nuevo. Creo que está preguntando si el desplazamiento es una entrada que va a la infraestructura. Eso depende, por supuesto. El límite real de esto es el dominio vertical, el contexto acotado al que pertenece. Entonces, si te desplazas dentro de un componente, esa es la responsabilidad de la biblioteca proporcionar como un organismo, y esta cosa es un poco opaca para el exterior. Este componente debe encargarse del desplazamiento en sí. Pero si el desplazamiento es responsabilidad de algo que incluye eso, entonces la aplicación debe hacerlo y la comunicación entre la aplicación y la biblioteca debe tener algún significado que sea realmente representativo de lo que eso significa. Si es algo como, oh, ahora estás en vista, muéstrate. Ese es un mensaje que quieres enviar a la biblioteca en lugar de, oh, el usuario se desplazó 10 píxeles. Esa es la clave. Tiene sentido. Urbon está preguntando, Jason, ¿tienes un repositorio Git con un ejemplo simple y jugable de arquitectura? No, en realidad no. Probablemente debería hacer eso. Soy un mal usuario de repositorios Git públicos. Debería hacer eso con más frecuencia. Creo que el código público más antiguo que escribí tiene como dos años o algo así. En años de JavaScript, eso es una eternidad.

Code Migration and Preventing Legacy

Short description:

Recomiendo poner tu código en GitHub para que otros lo exploren y contribuyan. La migración del código de SurveyMonkey se realizó centrándose en dominios y equipos de características. El objetivo era crear entidades de dominio cohesivas y orientadas a los negocios. Los equipos de características se incorporaron a la nueva estructura, utilizando la biblioteca y reconstruyendo partes o agregando nuevas características. Para evitar que las aplicaciones se conviertan en legado, enfócate en entregar valor a los usuarios y modernizar continuamente tu código.

Sí, muy bien. Sí, definitivamente. Te recomiendo totalmente que lo pongas en GitHub para que la gente pueda echar un vistazo, jugar un poco. Tal vez tengan algunos tips y trucos aquí y allá que implementen o apliquen a su propia aplicación o a toda la estructura de la empresa. Otra pregunta de Chris Shim es cómo migraste el código de SurveyMonkey, ¿característica por característica o más por dominio? Eso depende. Comenzamos con el dominio porque lo que tenía SurveyMonkey eran equipos de características muy independientes. Tenían mucha complejidad local, como dije, en su código porque cada uno de estos equipos de características tenía mucho poder para impulsar realmente características y sofisticación en su parte del producto. Ahora, lo que necesitas hacer es comprender esa complejidad y ver cuáles son esas características para no privar a los usuarios finales de nada y hacer que sean cohesivas en el dominio centralizado, un contexto acotado, como un grupo de entidades de dominio orientadas a los negocios. Una vez que tengas eso funcionando correctamente desde tu perspectiva y desde la perspectiva de los equipos de características que tienen ese dominio como parte de sus características, puedes incorporar a este equipo de características en esta nueva estructura, utilizando esta biblioteca y comenzar a obtener su aporte en la evolución de eso. Puede suceder con varios equipos de características a la vez porque se ejecutarán en paralelo y probablemente deban migrar sus propias características porque en última instancia, son quienes mejor entienden qué hace esa característica y también puedes comenzar a ayudarles a reconstruir ciertas partes o construir nuevas características utilizando esa biblioteca porque ahora crea la oportunidad para que construyan cosas súper rápido porque se eliminan algunas de las complejidades de su carga y contiene todo lo que desearían contener.

Genial. Sí, eso es realmente una buena respuesta, para ser honesto. La última pregunta es de Arek. Tenemos tiempo para una pregunta más. Entonces, ¿cómo se evita que las aplicaciones enterprise se conviertan en legado después de dos años? ¿Tienes algún consejo o truco para hacerlo? ¿Cómo evitar ser legado después de dos años? Sí, no hay una solución mágica, ¿verdad? Y es algo que es realmente importante que entendamos, que como tecnólogos consideramos algo legado una vez que deja de ser un juguete brillante, ¿verdad? Miramos las cosas y decimos: no puedo creer que todavía estés usando componentes de clase, ¿verdad? Eso no es realmente cierto. El código que está ahí, entregando un gran valor a los usuarios, es un gran código, ¿verdad? El enfoque está en cuando estás perdiendo oportunidades para brindar una gran experiencia a los usuarios, entonces comienzas a pensar: ¿puedo justificar reconstruir esto o debemos invertir este tiempo en construir algo nuevo, ¿verdad? Dependiendo de la respuesta, es posible que desees agregar cada pocos meses o incluso todos los días una pequeña pieza moderna a tu código. Sí, solo para mejorar todo, ¿verdad? Solo para mejorar la experiencia del usuario y luego publicarlo para el usuario, ¿verdad? porque el usuario final importa, sí, desafortunadamente se acabó el tiempo, pero Jason estará disponible en Spatial Chat, ¿verdad? Así que la gente puede discutir más contigo allí, ¿verdad? ¿Es eso correcto? ¿Vas a estar allí o sí, voy a ser increíble, sí increíble, muchas gracias, muchas gracias y el tiempo pasó tan rápido, disculpa por eso, pero fue una charla genial, muchas gracias por tomarte el tiempo y disfruta el resto del día y no te olvides de Spatial Chat con Jason, gracias Jason, muy bien gracias a todos, adiós

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

Una Guía del Comportamiento de Renderizado de React
React Advanced 2022React Advanced 2022
25 min
Una Guía del Comportamiento de Renderizado de React
Top Content
This transcription provides a brief guide to React rendering behavior. It explains the process of rendering, comparing new and old elements, and the importance of pure rendering without side effects. It also covers topics such as batching and double rendering, optimizing rendering and using context and Redux in React. Overall, it offers valuable insights for developers looking to understand and optimize React rendering.
Construyendo Mejores Sitios Web con Remix
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Construyendo Mejores Sitios Web con Remix
Top Content
Remix is a web framework built on React Router that focuses on web fundamentals, accessibility, performance, and flexibility. It delivers real HTML and SEO benefits, and allows for automatic updating of meta tags and styles. It provides features like login functionality, session management, and error handling. Remix is a server-rendered framework that can enhance sites with JavaScript but doesn't require it for basic functionality. It aims to create quality HTML-driven documents and is flexible for use with different web technologies and stacks.
Compilador React Forget - Entendiendo React Idiomático
React Advanced 2023React Advanced 2023
33 min
Compilador React Forget - Entendiendo React Idiomático
Top Content
Joe Savona
Mofei Zhang
2 authors
The Talk discusses React Forget, a compiler built at Meta that aims to optimize client-side React development. It explores the use of memoization to improve performance and the vision of Forget to automatically determine dependencies at build time. Forget is named with an F-word pun and has the potential to optimize server builds and enable dead code elimination. The team plans to make Forget open-source and is focused on ensuring its quality before release.
Uso efectivo de useEffect
React Advanced 2022React Advanced 2022
30 min
Uso efectivo de useEffect
Top Content
Today's Talk explores the use of the useEffect hook in React development, covering topics such as fetching data, handling race conditions and cleanup, and optimizing performance. It also discusses the correct use of useEffect in React 18, the distinction between Activity Effects and Action Effects, and the potential misuse of useEffect. The Talk highlights the benefits of using useQuery or SWR for data fetching, the problems with using useEffect for initializing global singletons, and the use of state machines for handling effects. The speaker also recommends exploring the beta React docs and using tools like the stately.ai editor for visualizing state machines.
Enrutamiento en React 18 y más allá
React Summit 2022React Summit 2022
20 min
Enrutamiento en React 18 y más allá
Top Content
Routing in React 18 brings a native app-like user experience and allows applications to transition between different environments. React Router and Next.js have different approaches to routing, with React Router using component-based routing and Next.js using file system-based routing. React server components provide the primitives to address the disadvantages of multipage applications while maintaining the same user experience. Improving navigation and routing in React involves including loading UI, pre-rendering parts of the screen, and using server components for more performant experiences. Next.js and Remix are moving towards a converging solution by combining component-based routing with file system routing.
Concurrencia en React, Explicada
React Summit 2023React Summit 2023
23 min
Concurrencia en React, Explicada
Top Content
React 18's concurrent rendering, specifically the useTransition hook, optimizes app performance by allowing non-urgent updates to be processed without freezing the UI. However, there are drawbacks such as longer processing time for non-urgent updates and increased CPU usage. The useTransition hook works similarly to throttling or bouncing, making it useful for addressing performance issues caused by multiple small components. Libraries like React Query may require the use of alternative APIs to handle urgent and non-urgent updates effectively.

Workshops on related topic

Masterclass de Depuración de Rendimiento de React
React Summit 2023React Summit 2023
170 min
Masterclass de Depuración de Rendimiento de React
Top Content
Featured Workshop
Ivan Akulov
Ivan Akulov
Los primeros intentos de Ivan en la depuración de rendimiento fueron caóticos. Vería una interacción lenta, intentaría una optimización aleatoria, vería que no ayudaba, y seguiría intentando otras optimizaciones hasta que encontraba la correcta (o se rendía).
En aquel entonces, Ivan no sabía cómo usar bien las herramientas de rendimiento. Haría una grabación en Chrome DevTools o React Profiler, la examinaría, intentaría hacer clic en cosas aleatorias, y luego la cerraría frustrado unos minutos después. Ahora, Ivan sabe exactamente dónde y qué buscar. Y en esta masterclass, Ivan te enseñará eso también.
Así es como va a funcionar. Tomaremos una aplicación lenta → la depuraremos (usando herramientas como Chrome DevTools, React Profiler, y why-did-you-render) → identificaremos el cuello de botella → y luego repetiremos, varias veces más. No hablaremos de las soluciones (en el 90% de los casos, es simplemente el viejo y regular useMemo() o memo()). Pero hablaremos de todo lo que viene antes - y aprenderemos a analizar cualquier problema de rendimiento de React, paso a paso.
(Nota: Esta masterclass es más adecuada para ingenieros que ya están familiarizados con cómo funcionan useMemo() y memo() - pero quieren mejorar en el uso de las herramientas de rendimiento alrededor de React. Además, estaremos cubriendo el rendimiento de la interacción, no la velocidad de carga, por lo que no escucharás una palabra sobre Lighthouse 🤐)
Next.js para Desarrolladores de React.js
React Day Berlin 2023React Day Berlin 2023
157 min
Next.js para Desarrolladores de React.js
Top Content
Featured WorkshopFree
Adrian Hajdin
Adrian Hajdin
En esta avanzada masterclass de Next.js, profundizaremos en conceptos clave y técnicas que permiten a los desarrolladores de React.js aprovechar al máximo Next.js. Exploraremos temas avanzados y prácticas prácticas, equipándote con las habilidades necesarias para construir aplicaciones web de alto rendimiento y tomar decisiones arquitectónicas informadas.
Al final de esta masterclass, serás capaz de:1. Comprender los beneficios de los Componentes del Servidor React y su papel en la construcción de aplicaciones React interactivas, renderizadas por el servidor.2. Diferenciar entre el tiempo de ejecución de Edge y Node.js en Next.js y saber cuándo usar cada uno en función de los requisitos de tu proyecto.3. Explorar técnicas avanzadas de Renderizado del Lado del Servidor (SSR), incluyendo streaming, fetching paralelo vs. secuencial, y sincronización de datos.4. Implementar estrategias de caché para mejorar el rendimiento y reducir la carga del servidor en las aplicaciones Next.js.5. Utilizar Acciones React para manejar la mutación compleja del servidor.6. Optimizar tus aplicaciones Next.js para SEO, compartir en redes sociales, y rendimiento general para mejorar la descubrabilidad y la participación del usuario.
Aventuras de Renderizado Concurrente en React 18
React Advanced 2021React Advanced 2021
132 min
Aventuras de Renderizado Concurrente en React 18
Top Content
Featured Workshop
Maurice de Beijer
Maurice de Beijer
Con el lanzamiento de React 18 finalmente obtenemos el tan esperado renderizado concurrente. Pero, ¿cómo va a afectar eso a tu aplicación? ¿Cuáles son los beneficios del renderizado concurrente en React? ¿Qué necesitas hacer para cambiar al renderizado concurrente cuando actualices a React 18? ¿Y qué pasa si no quieres o no puedes usar el renderizado concurrente todavía?

¡Hay algunos cambios de comportamiento de los que debes estar al tanto! En esta masterclass cubriremos todos esos temas y más.

Acompáñame con tu portátil en esta masterclass interactiva. Verás lo fácil que es cambiar al renderizado concurrente en tu aplicación React. Aprenderás todo sobre el renderizado concurrente, SuspenseList, la API startTransition y más.
Consejos sobre React Hooks que solo los profesionales conocen
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
Consejos sobre React Hooks que solo los profesionales conocen
Top Content
Featured Workshop
Maurice de Beijer
Maurice de Beijer
La adición de la API de hooks a React fue un cambio bastante importante. Antes de los hooks, la mayoría de los componentos tenían que ser basados en clases. Ahora, con los hooks, estos son a menudo componentes funcionales mucho más simples. Los hooks pueden ser realmente simples de usar. Casi engañosamente simples. Porque todavía hay muchas formas en las que puedes equivocarte con los hooks. Y a menudo resulta que hay muchas formas en las que puedes mejorar tus componentes con una mejor comprensión de cómo se puede usar cada hook de React.Aprenderás todo sobre los pros y los contras de los diversos hooks. Aprenderás cuándo usar useState() versus useReducer(). Veremos cómo usar useContext() de manera eficiente. Verás cuándo usar useLayoutEffect() y cuándo useEffect() es mejor.
Presentando FlashList: Construyamos juntos una lista performante en React Native
React Advanced 2022React Advanced 2022
81 min
Presentando FlashList: Construyamos juntos una lista performante en React Native
Top Content
Featured Workshop
David Cortés Fulla
Marek Fořt
Talha Naqvi
3 authors
En esta masterclass aprenderás por qué creamos FlashList en Shopify y cómo puedes usarlo en tu código hoy. Te mostraremos cómo tomar una lista que no es performante en FlatList y hacerla performante usando FlashList con mínimo esfuerzo. Usaremos herramientas como Flipper, nuestro propio código de benchmarking, y te enseñaremos cómo la API de FlashList puede cubrir casos de uso más complejos y aún así mantener un rendimiento de primera categoría.Sabrás:- Breve presentación sobre qué es FlashList, por qué lo construimos, etc.- Migrando de FlatList a FlashList- Enseñando cómo escribir una lista performante- Utilizando las herramientas proporcionadas por la biblioteca FlashList (principalmente el hook useBenchmark)- Usando los plugins de Flipper (gráfico de llamas, nuestro perfilador de listas, perfilador de UI & JS FPS, etc.)- Optimizando el rendimiento de FlashList utilizando props más avanzados como `getType`- 5-6 tareas de muestra donde descubriremos y solucionaremos problemas juntos- Preguntas y respuestas con el equipo de Shopify
React, TypeScript y TDD
React Advanced 2021React Advanced 2021
174 min
React, TypeScript y TDD
Top Content
Featured Workshop
Paul Everitt
Paul Everitt
ReactJS es extremadamente popular y, por lo tanto, ampliamente soportado. TypeScript está ganando popularidad y, por lo tanto, cada vez más soportado.

¿Los dos juntos? No tanto. Dado que ambos cambian rápidamente, es difícil encontrar materiales de aprendizaje precisos.

¿React+TypeScript, con los IDEs de JetBrains? Esa combinación de tres partes es el tema de esta serie. Mostraremos un poco sobre mucho. Es decir, los pasos clave para ser productivo, en el IDE, para proyectos de React utilizando TypeScript. En el camino, mostraremos el desarrollo guiado por pruebas y enfatizaremos consejos y trucos en el IDE.