Construyendo aplicaciones web con señales en Grammarly

Hola, bienvenidos a todos. Mi nombre es Lesh Levzhinsky, y hoy voy a hablar sobre la construcción de aplicaciones web con señales en Grammarly. Ya fui presentado, pero de todos modos, me uní a Grammarly hace muchos años. Me uní como desarrollador web, y ahora estoy trabajando con un par de clientes de Grammarly, principalmente web. Además, soy mantenedor de nuestra biblioteca de código abierto de Grammarly que trata sobre la gestión de estado reactivo. Es Grammarly para Kal, y también soy miembro de la conferencia FW Days. Es la conferencia más grande sobre JavaScript en Ucrania.

Bueno, sobre mi charla. Hoy, me gustaría compartir nuestra experiencia en Grammarly, cómo estamos usando señales para construir nuestras aplicaciones, así como me gustaría tal vez animar a todos a pensar sobre el uso de enfoques similares, si aún no lo hacen.

Bueno, y antes de profundizar en los detalles, tengo un par de preguntas. Lo siento, tengo un par de preguntas. En primer lugar, ¿alguna vez has usado señales? ¿Podrías levantar la mano? Oh, bien. ¿Qué hay de FRP, programación reactiva funcional? ¿Tal vez algo? Oh, va a ser una charla fácil. Bien. Pero de todos modos, no voy a empezar con la definición técnica.

Me gustaría comenzar con el caso de uso. Grammarly es un asistente de escritura. En Grammarly, el usuario puede escribir un texto y proporcionaremos un refinamiento para este texto. Proporcionaremos sugerencias para que puedas seguir adelante, actualizarlo, reformularlo, etcétera. En esta diapositiva, hay un par de errores tipográficos, y las líneas rojas son algo de Grammarly. Bueno, también tenemos un editor de Grammarly. Es como un editor típico donde los usuarios pueden seguir adelante y crear documentos, así como obtener todo el poder de Grammarly para refinar, hacer una revisión de su texto. Bueno, en este editor, tenemos un par de características. En primer lugar, sí, tal vez no en primer lugar, pero también pasar a la función principal como escribir texto. Nos gustaría mostrar algunas estadísticas. Además, definitivamente necesitamos enviarlo a algún lugar al backend para almacenamiento permanente. Nos gustaría que nuestros usuarios pudieran editarlo desde diferentes dispositivos, tal vez. Y por supuesto, necesitamos proporcionar una verificación de Grammarly, por lo que necesitamos enviar este texto a tal vez otro servicio. Así como podría haber múltiples características diferentes que necesitan ser actualizadas, recalculadas tan pronto como el texto cambie.

Bueno, suena bastante para solo una pulsación de tecla. Y aquí las señales pueden ser útiles. Entonces, en este caso, ¿qué podría ser una señal? La señal podría ser en realidad texto. Es como un valor, valores estáticos, con los que podemos trabajar en cualquier momento, así como el hecho de que cambia con el tiempo. Y tal vez un poco de lo que se trata.

Es un diagrama clásico. Nada especial aquí. En el lado izquierdo, solo tenemos un valor. Bien, podemos, cuál es el valor, podemos acceder a él en cualquier momento de manera sincrónica. En el lado opuesto, tenemos una especie de observable, solo un flujo de eventos, como sin el tipo de valor estático, sino más bien necesitas escucharlo. Y la señal es algo intermedio, ante todo. Usualmente, aquí es como un cubo. Hay un valor al que puedes acceder en cualquier momento, así como puedes suscribirte a él, por lo que se comporta de ambas maneras.

Bueno, esta es otra presentación. Entonces, las señales en general, es un concepto de reactividad. No voy a profundizar en la reactividad, pero, sí, en general, necesitamos reaccionar ante algún cambio en el estado y actualizar de manera reactiva nuestra interfaz de usuario, o tal vez ejecutar alguna lógica de negocio. Bueno, aquí está solo la parte observable de nuestra señal, como si estuviéramos aplicando al flujo de eventos, estamos aplicando la función de enlaces en este caso, y obteniendo otro flujo. Bueno, ¿qué hay del uso? Hay bastantes bibliotecas, frameworks que contienen este concepto de señales. Seguro, hay señales en Angular, así como Angular usa ArigGS.

Probablemente, el término señal se hizo popular después de que solid.js lo introdujera. Y seguro, hay una biblioteca independiente, ArigGS. No se trata solo de las señales, sino que hay un concepto llamado sujetos de comportamiento que pueden contener el valor que se puede acceder de manera sincrónica. Hay una propuesta estándar, seguro. En Grammarly, tenemos nuestra propia biblioteca que fue desarrollada hace bastante tiempo. Proporciona un código llamado GrammarlyFocal, y también básicamente proporciona o comparte el mismo concepto de señales, y hay muchos más ejemplos.

Bueno, suficiente con la especie de introducción. Veamos cómo estamos aprovechando la idea de señales en nuestro editor de Grammarly. Es como la misma pantalla, nada especial. No voy a profundizar en los detalles, pero veamos cómo podría ser, en teoría, implementado con React. Esto es muy simple, solo para el propósito de la demostración.

Es un componente de React bastante simple. Hay un área de texto. En la vida real, definitivamente no es un área de texto. Y aquí necesitamos rastrear el estado, el cambio del texto. Aquí hay un simple use state. Y por supuesto, tan pronto como el usuario escriba algo, necesitamos enviar este valor a algún lugar, al servicio de check-in, para obtener alguna sugerencia, para obtener algunas mejoras. Y vamos a profundizar un poco en esta comunicación tipo cliente-servidor y procesamiento de texto.

Entonces, en este caso, tenemos un editor. Tan pronto como el usuario escriba algo, tan pronto como el texto se actualice, necesitamos enviarlo a algún lugar. Así que se siente como una especie de flujo de eventos. Necesitamos, por supuesto, obtener las sugerencias, pero casi de inmediato necesitamos responder un par de preguntas. Bueno, ¿con qué frecuencia necesitamos enviar este texto? ¿Necesitamos usar un búfer? ¿Qué pasa si falla? ¿Necesitamos enviar un texto completo? Hay casos cuando el usuario trabaja con documentos muy largos, como documentos de 10 páginas, 100 páginas, podría ser una carga útil bastante grande. Bueno, y necesitamos recordar que nos gustaría mostrar estos subrayados en vivo, no esperar un par de, incluso un par de segundos o un minuto para un check-in.

Y eso es solo una parte. Otra parte es que tenemos una interfaz de usuario bastante dinámica. Y tan pronto como algo cambie con el texto, necesitamos actualizar todas estas piezas casi de inmediato. Aún así, suena como demasiado para solo un componente de React y tal vez para un par de casos de uso. Es por eso que, para el propósito de la demostración, introduzcamos una capa adicional. La llamaremos una especie de modelo de vista. Podría llamarse de diferentes maneras, pero toda la lógica será, todo el estado para nuestro componente visual, así como la lógica de negocio que pasará datos a, digamos, la API al backend estará aquí. ¿Y qué es el modelo de vista en nuestro caso? Es solo una clase, una clase simple de esta manera.

Pero aquí tenemos un par de señales. Así que aquí vamos. Ahora, la línea número dos y la línea número tres introducen dos tipos de señales. En nuestro caso, estamos usando el término átomo porque nuestra biblioteca fue inventada antes de que el término señal se hiciera popular. Y por supuesto, todos ellos contienen algunos valores predeterminados, como el inicial, y se actualizarán más tarde. Pero luego la siguiente pregunta es cómo conectarlos a React y cómo hacer que React funcione con estos valores cambiantes, dado que React ya proporciona los hooks. Y hay una manera bastante simple de implementar un hook propio. No voy a mostrar la implementación, pero en general, bajo el hook, es solo un use state y use effect que escucha y se suscribe a la señal. Bueno, y lo mismo necesitamos para las sugerencias también, porque van a ser dinámicas y necesitamos que React y las renderice tan pronto como lleguen del servidor.

Pasando al siguiente punto. Entonces, ¿cuál es el punto? Bien, hemos introducido un par de señales, así que las hemos conectado a React. Pero, ¿qué beneficios nos trae esto? ¿Qué posibilidades tenemos ahora mismo? Y hay dos cosas principales. La primera es básicamente la señal. En nuestro caso, puede comportarse como un observable. Nos permite usar toda la belleza de la programación funcional reactiva y la programación declarativa, por lo que podemos definir lo que realmente necesitamos hacer. Y en la línea número ocho y nueve, por ejemplo, decidimos que no queremos enviar el texto completo al servidor, sino que necesitamos calcular la diferencia. Pero tampoco tiene sentido calcularlo para cada frase clave. Sino que tal vez necesitemos introducir algo de lógica, tal vez para limitar. En este caso, es limitar, pero en la vida real es mucho más complejo. Estamos esperando, digamos, una pausa entre palabras y tal vez cuando el usuario termine la oración, porque no tiene sentido mostrar una sugerencia para una palabra no completada, por ejemplo.

Y otro ejemplo, tal vez simple también es, bien, el mismo valor de texto. Es nuestra señal que emite tan pronto como el usuario cambia el texto. Necesitamos recalcular las estadísticas. Y somos bastante flexibles aquí. Es como el mismo flujo, pero podemos usar una técnica diferente. En este caso, decidimos por alguna razón, no sé, decidimos usar los bonos y esperar hasta que el usuario se detenga para recalcular las estadísticas. Tal vez no haya muchos usuarios que escriban y verifiquen la estadística al mismo tiempo. De todos modos, es solo un ejemplo.

Y la segunda cosa genial sobre nuestras señales es que se comportan como un valor clásico. Se puede acceder a ellas y podemos obtenerlas de manera sincrónica en cualquier momento. Este es un ejemplo bastante simple de implementación. Copiando al portapapeles. Básicamente, el usuario puede querer copiar el texto seleccionado, o tal vez el texto completo. Y en la línea número seis, hay un método, básicamente getters, que nos permite obtenerlo inmediatamente. Bueno, ¿cuál es el resultado? Logramos un par de cosas aquí. En primer lugar, hemos desacoplado nuestro estado de la capa de vista. Toda la lógica de negocio se puede conectar fácilmente a nuestros flujos, porque es un flujo. Podemos usar programación declarativa para describir lo que está sucediendo. Además, todas estas piezas pueden hacerse en un estado bastante aislado, porque nada depende de cada uno. Eso es básicamente todo.

Cuando hablamos de los flujos, una pregunta bastante frecuente es, bueno, pero ¿cómo probar eso? Y aún así, con las señales, hay un par de técnicas. La primera es simplemente, bien, esta es una prueba unitaria clásica. Estamos tratando de probar nuestra lógica que copia al portapapeles. En la línea número siete, estamos creando nuestro modelo de vista. En la siguiente línea, lo estamos copiando al portapapeles, y luego estamos afirmando que, bien, nuestro servicio que probablemente debería hacerlo, dependiendo de la plataforma, puede, lo que se llama, con el valor adecuado. Nada especial aquí. Es solo una prueba unitaria clásica. Esto se debe a que la señal puede comportarse como un valor clásico, como un valor estático que existe siempre. Pero aquí vamos. Otra pieza de nuestra señal es el hecho de que es un valor a lo largo del tiempo.

Entonces, también necesitamos probarlo de alguna manera. Veamos el ejemplo. Tenemos un texto. El usuario decidió escribir hello. Luego el usuario decidió cambiarlo a hello world. Y nos gustaría asegurarnos de que nuestras diferentes funciones, diferentes funciones funcionen correctamente. Entonces, para el primer caso A, no hay nada antes, así que va a ser hello. Para el segundo caso, va a ser solo world, como una pieza que se agregó. Y más tarde, enviaremos esto tal vez al back end para verificar.

Bueno, ¿cómo se puede implementar? Hubo un adelanto en la pantalla. Vamos a usar una prueba de mármol. Prueba de mármol, mármoles, tenemos un flujo y mármoles en él. Este es un ejemplo bastante simple. Aún así, estamos usando para definir nuestro comportamiento, para definir el comportamiento de nuestra señal a medida que cambia con el tiempo. Vamos a usar solo los caracteres, un par de ellos, los guiones y los valores. Además, podemos definirlo en la línea número dos y línea número tres. Estamos definiendo los valores. Esto debería ser, que corresponde a este valor A y B. Además, en la línea número cinco, estamos definiendo lo que se espera.

Y la segunda parte de nuestro código es básicamente para definir la lógica. En este caso, es solo un ejemplo de demostración. No es uno real. En el mundo real, probablemente será la creación del modelo de vista. Que expone el observable o expone las señales en este caso. Y también, en la última parte, estamos haciendo un ordenamiento. Y la prueba de mármol, hay un framework, hay una biblioteca que te permite ejecutarla. Definitivamente, habrá un envoltorio que crea una especie de planificador que necesita ser usado porque no es, su valor cambia, que cambia con el tiempo. Entonces, habrá un poco de código repetitivo, pero el núcleo de esta prueba es bastante legible, seguro, si conoces la sintaxis sobre cómo definir los eventos. Bueno, básicamente, la prueba está hecha. Y resumamos lo que tenemos.

Para Grammarly, en nuestro caso, la idea de señales y la idea de trabajar con los flujos y al mismo tiempo con un valor único encaja perfectamente en nuestro dominio porque la función principal es trabajar con el texto que el usuario está escribiendo en cualquier lugar. Tenemos una extensión de navegador. Tenemos un editor donde necesitamos observar el texto y proporcionar muchas cosas sobre, no sé, la longitud del texto, sobre lo que se cambió. Nuestra extensión de Grammarly, el editor de Grammarly que acabo de mencionar, impulsado por React y señales, en nuestro caso, solo estamos usando Atoms, por nuestra propia biblioteca de código abierto. La ventaja de la idea de señales es que se pueden conectar fácilmente, hay un montón de bibliotecas que proporcionan este concepto. No necesitas tenerlas integradas en el framework. Se pueden agrupar fácilmente junto con React o incluso React Hooks. Entonces, en este caso, eres libre de probar y no necesitas cambiar tu framework o reescribir todo. Y tal vez como un efecto secundario, pero te permiten fortalecer el aislamiento de tu código. Básicamente, la naturaleza de los flujos es que puedes conectar y desconectar en cualquier momento, pero con este poder viene que necesitas pensar en las pruebas de integración dos veces. Porque el aislamiento puede llevar a algunos casos bastante inesperados y difíciles cuando necesitas pensar en las pruebas. Bueno, y tal vez para resumir en general, sí, las señales son independientes del framework. Puedes usarlas para bastantes casos. Tal vez tenga sentido hablar de un par de ellos. Así que, como en mis ejemplos, tienes un solo dato y la aplicación que necesita reaccionar en múltiples partes a este dato. Podría ser en otro caso, podría estar bien, estás haciendo algo, necesitas escuchar un desplazamiento y mostrar en algún momento algunos banners. También es como en un solo dato, pero no en múltiples lugares, sino en uno. Y seguro, es como procesar la tarea, las tareas largas a las que necesitas reaccionar y necesitas mostrar un par de estados, escuchar algunos eventos. Así que también tiene sentido usar señales así como reactividad. Y un poco sobre recursos. Hay bastantes útiles. Sugeriría seguir adelante y leer al menos sobre la propuesta, la última en esta lista. Hay una comunidad tratando de estandarizar cómo deberían verse las señales en diferentes frameworks. Hay muchas ideas interesantes. Tal vez se convierta, eventualmente se convierta en el núcleo de JavaScript, pero al menos mencionan que no sucederá este año ni el próximo. Es un camino bastante largo para estandarizarlo. Y eso es todo. Muchas gracias. Muy bien. Así que vamos a empezar con el que está justo en la parte superior.

¿Cómo manejas la limpieza o la cancelación de suscripción a señales dentro de tus modelos de vista? Esta es una gran pregunta. Primero que todo, gracias por preguntar. Y esto probablemente no se trata realmente de las señales. No solo sobre las señales, sino probablemente sobre la arquitectura en sí. Así que en este caso, definitivamente está en los modelos de vista que se pueden crear en algún momento. Y desafortunadamente, en JavaScript, no tienes una forma clara de definir cómo destruirlo. Pero hay dos opciones y hay dos maneras de hacerlo.

La primera de todas, en algunos casos cuando nos damos cuenta de que necesitamos reinstanciarlo, tal vez o como disponer explícitamente, hay un método dispose. Y estamos conectando esto al ciclo de vida de React. Tan pronto como los componentes de React se están renderizando por primera vez, estamos comenzando una suscripción. Y en esta fase de desmontaje, estamos haciendo eso, como cancelar la suscripción. Otra opción, también depende mucho de, como de la arquitectura. Por ejemplo, si es una especie de SPA, aplicación de una sola página. En este caso, si te mueves de una ruta a otra, no... En la mayoría de los casos, no necesitas pensar en ello a menos que estés manteniendo tus suscripciones en el espacio de nombres global. En este caso, la recolección de basura lo manejará.

Genial. Andreas, gracias por la gran pregunta. La siguiente pregunta es anónima, pero está preguntando sobre cuál es la principal diferencia entre dos MobX con observables. Creo que ModX es el framework basado en señales, creo. Sí, también. Tal vez, diría que la mayor diferencia de lo que estamos usando, estamos usando bajo el capó es un Rigs-JS para impulsar nuestras señales. Como mencioné, estamos usando BehaviorSubject y GrammarlyFocal es solo un envoltorio que te permite... Que proporciona un par de métodos agradables para trabajar con una señal. Básicamente, limita la interfaz de Rigs-JS porque con Rigs-JS, puedes hacer casi lo que quieras. Y la interfaz principal en Rigs-JS es observable. Pero observable es algo que no contiene un valor. Pero sí, lo hemos envuelto. Y básicamente asegura que siempre haya un valor, como estamos usando BehaviorSubject y tipos adicionales. Con respecto a la diferencia principal, diría que porque todavía estamos usando Rigs-JS, tenemos una biblioteca bastante grande de ayudantes que nos permiten trabajar fácilmente con los flujos, para combinarlos.

De alguna manera, los vínculos cambian de uno a otro, se pasan a otros observables, y así sucesivamente. Así que probablemente esta es una diferencia principal en nuestro caso.

Genial. Tenemos otra pregunta de una persona anónima. Y sé que incluso solo de algunas de las charlas de hoy, y puedo ver algunas caras familiares en la multitud, a las que llamaré evangelistas de señales, ¿verdad? Hay muchos de estos sistemas impulsados por señales.

¿Y cuáles son algunos de los principales desafíos que los afectan? Otra gran pregunta. Gracias por preguntar. Esto podría ser una charla bastante grande. Podría ser una sala de discusión en el próximo React Dig Berlin. Sí, creo que sí. Bueno, el principal desafío, como mencioné probablemente al menos desde mi entendimiento, es cómo probarlo. Porque en caso de que tengas muchos flujos y todo es dinámico, en este caso, definitivamente la parte de integración será bastante grande. Necesitarás asegurarte de que, no sé, estás usando las funciones adecuadas como, no sé, diferenciación, rebote, y que funciona correctamente.

Las pruebas de mármol son bastante útiles aquí, pero aún hay mucho código repetitivo y realmente necesitas entender cómo funciona. Además, la gran idea de esta propuesta que mencioné para llevarla al núcleo es simplificar la depuración de flujos. Porque todavía, si algo está sucediendo, tendrás una gran traza de pila con algunas funciones internas sobre quién lo llamó, cómo fue llamado, cómo llegó a este lugar. Así que, sí, tal vez estos sean dos desafíos. Siento que podrías seguir con esa pregunta.

Así que, si quieres hablar con él después, siéntete libre de hacerlo. Y hablaste sobre las pruebas de mármol y esta persona ha preguntado sobre la sintaxis de las pruebas de mármol.

¿Cuál es el beneficio de usarlo en lugar de usar como un array con valores a lo largo del tiempo? Esa es una gran pregunta. La idea de las pruebas de mármol y básicamente las bibliotecas que estamos usando es que no es solo un array. Te proporciona flexibilidad sobre el tipo de tiempo de ejecución. Así que, con guiones en la pantalla, puedes definir en qué punto del tiempo se disparó el evento. Es como si es un guion, es un tick, tres guiones, tres ticks. Y también, tienes control, aún, con casos bastante complejos, se vuelve ilegible. Pero necesitas ser un poco significativo aquí. Otra gran ayuda de esta biblioteca es que también controla el ciclo de vida. Puedes suscribirte, cancelar la suscripción, y con toda la sintaxis, puedes hacer eso.

Así que, no se trata solo de array. Con array, tiene sentido, pero para el caso simple, como si solo necesitas emitir en cualquier momento un par de eventos. Pero con las pruebas de mármol, y básicamente impulsadas por la biblioteca, puedes controlar eso, por ejemplo, este tipo de señal emitió un par de valores y luego se detuvo, como desuscribirse, la función se completó. Genial.

La siguiente pregunta es de Alexey. Yo estaba como, ¿qué? ¿Alexey? Pero es una ortografía ligeramente diferente. Hay muchas variaciones diferentes del mismo nombre, seguro. Y esto es sobre estados combinados. Entonces, ¿cómo se ve un estado combinado cuando necesitas calcular una señal a partir de otras señales? ¿Y pueden los OVMs tener una dependencia de señales? Es difícil de explicar, probablemente en palabras. Sugeriría a alguien que preguntó eso que abra el repositorio de Grammarly Focal en GitLab. Se llama Grammarly slash Focal. Y hay un par de ejemplos de cómo puede verse. En general, hay una función, estamos usando la función view en nuestras bibliotecas que te permite de alguna manera depender del valor anterior y calcularlo. Si se trata de combinar, puedes combinar, hay un helper combine que combina un par de estados. Y también hay una especie de callback, llamémoslo callback, que te permite de alguna manera crear un valor calculado. Genial.

Tenemos una pregunta de vuelta a las pruebas de Jacob. Él dice, ¿has considerado algo como pruebas basadas en propiedades para expandir más allá de las pruebas de mármol y verificar invariantes cuando el espacio de combinación es grande? Pruebas basadas en propiedades. Esto es algo genial. Recientemente, en Grammarly, tuvimos una charla sobre las pruebas basadas en propiedades. Sugeriría a todos buscar esta charla, o simplemente venir aquí. Tenemos un presentador, Nastya Zelenka está aquí también, y hablar sobre pruebas basadas en propiedades. Mi sugerencia sería tal vez intentar limitar la superposición entre la prueba de mármol y las pruebas basadas en propiedades, porque definitivamente se volverá complejo. Pero por sí mismo, es algo muy poderoso en caso de que no sepas el resultado. Y estamos usando intensamente pruebas basadas en propiedades para nuestros divs. Necesitamos asegurarnos de que los divs que estamos produciendo sean lo suficientemente estables. Así como no solo divs, también estamos haciendo algunos tipos de fechas optimistas para estos divs en los clientes, para las sugerencias, y así sucesivamente. Otro tema. Eso tiene sentido. Y de nuevo, recuerda, puedes encontrarlo en la sesión de preguntas y respuestas del orador cerca de la entrada después de esta charla.

Y el último. Solo tienes un minuto para responder, así que tiene que ser rápido. ¿Qué opinas sobre la propuesta de signals? ¿Estás pensando que Grammarly podría migrar del código específico de Grammarly eventualmente? Puede suceder. Hasta ahora, tal vez la mayor limitación de esta propuesta es que no proporciona la solución para trabajar con signal como un stream. Básicamente, se trata más de cómo integrar la idea de signals en los frameworks existentes, en las actualizaciones de UI. Pero falta la parte de stream. En nuestro caso, es definitivamente importante, pero aún así hay una manera, creo que Angular hizo algo similar. Así que introdujeron los signals, pero también añadieron un par de helpers que te permiten convertir de signal a RxJS, por ejemplo. Así que veremos. Aun así, en esta propuesta, se menciona que va a ser un camino bastante largo para llegar al núcleo de JS y también para adaptarlo. Así que tal vez en un par de años, consideraremos eso. Estaremos atentos. Estaremos atentos. Muchas gracias, Alexey. ¿Podemos darle un aplauso?