Entonces, el problema del glitch es si implementas señales de manera ingenua, donde cuando tienes un estado y lo cambias, eso vuelve a ejecutar el computado, ya sabes, así es como funcionaba mucha de la generación anterior de frameworks. Cuando React salió, su innovación, bueno, una gran parte de su valor fue que no hacía esto. Solo evaluaba las cosas cuando eran necesarias. Pero anteriormente, ya sabes, AngularJS y Ember, cuando algo cambiaba, determinaba, ok, tengo las cosas que dependen de ello, así que actualizaré esas, y eso se convierte en un lío.
En particular, si estableces una señal, y luego tienes algún efecto que se basa en reaccionar a ese cambio de señal, podrías observar estados intermedios de la computación. Entonces, en este caso, t.get siempre debería ser mayor que seconds.get, porque es uno más que él. Pero si hay una búsqueda que va a la izquierda antes de ir a la derecha, al visitar las actualizaciones, podría registrar falso porque podría ver uno de ellos actualizado y el otro no actualizado. Y esta imagen es del gran artículo de Wikipedia sobre reactividad.
Entonces, la solución es un poco complicada, pero históricamente, los frameworks intentaron, ya sabes, implementar partes de esto, y en este punto, todos se dan cuenta, no, solo tenemos que hacer la solución correcta, que es ordenar topológicamente las dependencias y evaluarlas en un orden coherente. Entonces, este es un gráfico acíclico dirigido, si hay un ciclo, eso puede causar un error cuando se crea el ciclo. Así que, eso se puede detectar. Pero puedes ordenar los nodos para que nunca estés ejecutando un computado antes de que todas sus cosas que vinieron antes ya hayan sido ejecutadas. Y la evaluación basada en extracción también es crucial para esto. Porque haces este orden cuando ocurre un get. Hay múltiples algoritmos para evaluar esto. Este es un post de blog de Kristen, anteriormente del equipo de EmberJS, sobre el uso de números de revisión. Otro algoritmo, esta es una explicación de Milo del equipo de Solid, es usar este tipo de empuje hacia adelante de la suciedad y luego reevaluar nodos basados en eso. De todos modos, no tengo tiempo hoy para entrar en los algoritmos. Pero aunque hay múltiples algoritmos, tienen el mismo comportamiento observable. Hacen lo mismo, ejecutan el computado en el mismo orden.
Y en última instancia, lo que ha sucedido con los frameworks, se puede comparar con la carnicización. Entonces, el fenómeno donde un montón de diferentes animales todos tuvieron evolución convergente hacia el plan corporal de un cangrejo. Porque para ciertos estilos de vida, es muy efectivo. Y creo que hemos visto eso dentro de los frameworks de JavaScript. No es como si Solid inventara señales y todos las copiaran. Históricamente, otros frameworks estaban un poco acercándose desde otros lados y viendo diferentes piezas del problema y todos han influenciado entre sí directamente y también han resuelto el mismo problema y llegado al mismo lugar.
Entonces, cuando en Bloomberg estamos pensando en cómo queremos construir nuestro front end, qué tipo de framework usar, bueno, hasta ahora, nuestro desarrollo de software se ha basado en gran medida en estándares. Como dije, el terminal principal se basa en Chromium. Así que, HTML, CSS, JavaScript.
Comments