Qué es reactividad

Dale 💚 si quieres un Curso de Patrones Arquitectura de Software para Frontend

Dale 💚 si quieres un Curso de Programación Reactiva en JavaScript

Caso práctico de manejo del Estado:
.
1️⃣ Requerimiento general del producto (lo que el usuario debe ver)

• La aplicación tiene una lista de elementos y un input de búsqueda

• El usuario escribe su filtro / búsqueda

• La aplicación muestra solo los elementos que cumplen con el filtro
  .
  2️⃣ Requerimiento detallado del producto (lo que en realidad debemos construir)

• La aplicación tiene un estado / store global para guardar elementos

• Diferentes elementos de la UI se suscriben al estado global para enviar o recibir actualizaciones
  – El input de búsqueda envía actualizaciones
  – La lista de elementos recibe actualizaciones

• El usuario escribe su filtro / búsqueda en el input, el input envía el mensaje al estado, el estado cambia y se lo notifica a la lista de elementos, la lista de elementos cambia y el usuario obtiene su respuesta

Reactividad: Es un paradigma, una forma de pensar nuestras aplicaciociones. Deben seguir 2 reglas:

1. Responsive, es decir, deben ser resilientes (siempre sabe qué hacer) y escalables (no importa con cuánta información debemos trabajar o cuántos usuarios entran a la aplicación, la aplicación debe poder seguir funcionando sin problemas).
2. Message Driven (Arquitectura basada en mensajes). Deben de haber emisores y receptores de mensajes. Los mensajes se entregan de manera asíncrona.

Recuerda: La arquitectura no es ajena a la programación.

Estado: Es el lugar donde vamos a guardar la información reactiva de nuestros componentes. Son variables a las que nos suscribimos para recibir una notificación cada vez que cambian sus valores.

Render: o renderizado, es el proceso por el cual nuestro HTML, pasan a ser información visual en el DOM.

Estrategias de render: Virtual DOM y No Virtual DOM. Ninguna es mejor, depende del caso en particular.

Componente -> Estado -> Render -> Usuario (y vuelve a “Estado”)

Algo curioso que comentó un profesor de Vue de Platzi alguna vez es que Vue SÍ es completamente reactivo, React no lo es 👀.
.
Solo para dar contexto, en JavaScript podemos manejar la reactividad de una forma muy fácil usando proxy’s. Los proxy’s nos permiten interceptar el cambio de valores de algunos objetos y realizar ciertas acciones. Si quieren conocer más sobre los proxy’s, en el Curso Profesional de JavaScript se toca este tema, y of course, yo los incitaré a probar Vue, el Curso de Introducción a Vue.js 3 explica más a fondo cómo funciona el paradigma de reactividad, e incluso el profesor hace un mini framework reactivo usando proxy’s de JavaScript, es un curso increíble! 💚

Que es la reactividad en el software y porque es importante?

La reactividad nacio en el 2014 con “The Reactive Manifesto”, en donde explican como es que las aplicaciones web de hoy en día no pueden ser iguales a las aplicaciones web de hace 10 años. Esto debido principalmente a la cantidad de usuarios del internet que hay hoy en día. Por lo tanto, se dijo que para que una aplicación pueda ser competitiva, necesita 4 características principales:

• Ser Responsivo (que responda a los requerimientos del usuario en tiempo y forma, generando una buena experiencia)
• Resiliente (que funciona incluso cuando se haya caído una base de datos o cualquier otra tragedia)
• Elástica (que puede ser usada tanto por 8 usuarios, como por 8 millones de la misma manera)
• Basada en mensajes (permite delegar errores a manera de mensajes)

Reactividad

Es un paradigma de programación y sigue dos reglas:
1. Responsive: Saber reaccionar ante cualquier situación
2. Message Driven: Arquitectura basada en mensajes.

Es un paradigma, una forma de pensar nuestras aplicaciones de forma que sigan dos reglas o lineamientos.

• Responsive: Que sabe reaccionar, las apps responsive saben que hacer sin importar lo que pase, cumplen dos condiciones:
  • Ser resilientes: Que nuestra app siempre sabe que hacer incluso en situaciones malas
  • Ser escalables: o elásticos, es decir, que no importa con cuanta información tenemos que trabajar o cuantos usuarios entren a la app al mismo tiempo la aplicación debe poder crecer y funcionar sin problemas
• Message Driven: Arquitectura basa en mensajes, consiste en programar nuestras apps con emisores y receptores de mensajes, pero los emisores no entregan directamente los mensajes a los receptores; los mensajes no se entregan sincrónicamente, lo hacen asincrónicamente, se guardan en una cola a la que los receptores se deben suscribir para recibir los mensajes. Para esto se usan observers, una librería muy usada es rx.js, la implementación de reactivex.

Otros dos conceptos para trabajar la reactividad son:

• Estado o State: Aquí se guarda la información reactiva de nuestros componentes, no todos los frameworks lo llaman así pero en esencia son lo mismo, son variables a las que nos suscribimos para recibir una actualización cada vez que cambian sus valores. Podemos manejar un campo de búsqueda o filtrado en una lista de elementos. Con el estado estamos preparados para cuando el usuario solicite la búsqueda nosotros podamos reaccionar.

• Render: Es el proceso por el cuál nuestro HTML pasan a ser información visual en el navegador (el DOM), con JS podemos manipular el HTML que ya está en el navegador y cambiarlo dependiendo de las interacciones de nuestros usuarios.

  Estrategias de render:

  • Virtual DOM: Puede decirse que es la más popular, es una copia del DOM en JS. Leer, comparar y modificar el DOM directamente es muy costoso. Cada vez que hay un render creamos una copia del DOM en JS, así cuando evaluemos en un futuro que componentes debemos volver a renderizar, no tenemos que ir al DOM, lo hacemos con el virtual DOM que es mucho más rápido y cuando ya sabemos cuales debemos de renderizar le volvemos a hacer render directo al DOM, haciendo la app más rápida.
  • No Virtual DOM: El virtual DOM es un “paso extra” y es innecesario según este approach. Lo que proponen es crear un mini virtual DOM específicamente para el componente que se quiere modificar.

  Estas son las que usan los frameworks así que debemos elegir el que más se adapte a nuestro proyecto.

ser responsive significa ser recilientes(a prueba de todo) y elasticas (escalables)

Explica super bien !!! Gracias

Siento que los puntos que repasamos en esta clase son super importantes para lo que se viene. Gracias Juan 💚 por explicarlos así, se me hizo super fácil entender los conceptos.

La verdad sí se agradecería un curso sobre patrones de diseño y arquitecturas para frontend.

De una , que se haga ese Curso de Patrones Arquitectura de Software para Frontend

El estado es una variable donde guardamos la información reactiva y a la que nos suscribimos para recibir una actualización cada vez que esta cambie.

💚

MUCHA TEORIAAAAA
Cada Framework usa una sitnaxis diferente para crear componentes, al igual que diferentes estrategias de rendering, esto es la forma que convierten los componentes en HTML.

No existe una unica forma para programar para que construyamos la misma aplicacion. Dependiendo del problema que tengamos que resolver habra caminos mas faciles que otros, esto son paradigmas, como la POO, la programacion funcional, etc. Pero hay paradigmas mas pequenos como el paradigma descriptivo siempre hay que mostrar el como. Pero en el hiperativo nos esforzamos por esconder el como hicimos las cosas. La Reactividad tambien es un paradigma pero este tiene que seguir dos lineamientos:

• Responsive

  No de Responsive Design, pero de saber reaccionar, saben que hacer sin importar lo que pase, estas tienen que ser Resilientes y Escalables.

  Resiliente que siempre sabe que hacer, incluso en situaciones malas o de panico. Sabremos como responder a los usuarios y darles una solucion para que puedan seguir usando la aplicacion.

  Elastico o Escalable quiere decir que no debe importar la informacion que vamos a trabajar o cuantos usuarios entren al mismo tiempo.

• Arquitectura Basada En Mensajes (Message Driven)

  Conciste en programar aplicaciones con emisores y receptores de mensajes, pero esto no llega directamente los mensajes. Esto no se entregan sincronicamente si no Asincronicamente, se guardan en cola a la que los receptores se deben suscribir para recibir sus mensajes.

  Para este patron usamos Observadores, RXJS es una buena libreria para esto.

  Esta es la forma en la que internamente funcionan muchos de los framework en JS para ser reactivos. Y hay que implementarla de forma conciente. TODOS DEBEMOS APRENDER ARQUITECTURA

El estado es donde vamos a guardar la informacion reactiva de nuestro componentes, son variables a las que nos suscribimos para recibir una actualizacion cada que cambian sus valores. Como un campo de busqueda o presione un boton, debemos buscar un estado para buscar las palabras clave para nuestra lista de elementos. COMO NO SABEMOS CUANDO SUCEDERA con el estado estamos listos para reaccionar cuando el usuario haga esto.

El renderizado es el proceso en el que nuestro HTML pasa a ser informacion visual o el DOM. Con JS podemos escribir el HTML en parte de los sitios, al igual podemos manipular el HTML que ya esta escrito, por eso hay estrategias para hacer esto.

• Virtual DOM

  Una reprensetacion del DOM en JS. Leer, hacer comparaciones y modificarlo directamente es muy costoso y a veces no necesitamos actualziar toda la aplicacion cuando a veces nada mas tenemos que actualizar N numero de componentes. Cuando trabajamos con esto creamos una copia del DOM que sera el cual compararemos y cuando sabremos que mofiicarlo haremos esto con el directo.

• No Virtual DOM

  A pesar de ser bueno hay personas que piensan que esto es un paso extra y esto es innecesario, que agregar este paso o actualizar un elemeneto en el navegador no vale la pena. Proponen que en vez de crear una copia del DOM, en vez creeemos un mini VIRTUAL DOM del puro componente y no de TODO EL DOM o no hacer copia.

Recordemos que cada componente tendra un ESTADO, de ahi estara en RENDER y los USUARIOS Podran interactual con la pagina y esto cambiara el ESTADO y el ciclo se repite.

Hola Platzi! ¿Cómo va? Estoy armando una carpeta de Google Docs con la toma de notas de todos los cursos que voy realizando para que entre todos podamos aportar!

Los invito a participar!
https://drive.google.com/drive/folders/1SWGMgTMPbwgasbzcivcpcnIudc2vk_v0?usp=sharing

El paradigma reactivo debe de seguir dos lineamientos:

1. Responsive, esto quiere decir que debe de ser resiliente y escalable la aplicación
2. Arquitectura basada en mensajes, esta arquitectura consiste en programar nuestras aplicación con emisores y receptores de mensajes de manera asincrona, en la que os receptores se deben de suscribirse para recibir sus mensaje.

Muy buena explicación!! Gracias

La reactividad es una manera de pensar(es un paradigma de programacion)
Para que sea Reactivo tiene que cumplirse 2 cosas

1° Que sea Responsive(Responsivo)
Debe saber reaccionar. Saben que hacer sin importar lo que pase

Para decir que se es responsive debe cumplir 2 condiciones:Resiliente y escalable

Resiliente: La pagina siempre sabe como responder. Siempre darle una solucion ante un error de sea conexion o lo que fuese.
Es decir, que pueda continuar con su navegacion

Escalable: no importa con cuanta informacion o cuantos usuarios deban entrar debe poder adaptarse

2°Arquitectura basada en mesajes

Los mensajes se guardan de forma asincronica
Emisores - Receptores
Se guardan en una cola( queue ) a la cual los receptores se deben suscribir para recibir su mensaje.
A la hora de que el emisor envie el mensaje, el “queue aggregator” identifica en que queue debe guardar ese mensaje.
Esa cola en particular se encargara de avisar a todos los suscritos que recibio un mensaje.
Para utilizar este patron se usa observer (rx.js) => reactivex

No dejarnos llevar por la corriente y aprender de lo que estamos trabajando

============
=Estado=

===================================
Los estados son variables a las que no suscribimos
para recibir una actualizacion cada vez que cambian sus valores
Cada vez que el usuario aprete un boton o use una lista de busqueda
tenemos que poder reaccionar

============
=Render=

===================================
Con JS podemos escribir el html de una parte de la pagina o toda una aplicacion completa.
Tambien podemos acceder al html ya dibujado en el navegador

=Estrategias de render=

Virtual DOM
es una representacion del DOM en JS
Modificar directamente el DOM es muy costoso. Porque no necesitamos actualizar toda la aplicacion
Solo ciertos lugares
Como saber cuales lugares?
Cada vez que vemos que hay un render se hace un copia de js.
Entonces cada vez que vamos a modificar el js lo hacemos en el virtual DOM
Una vez identificamos los componentes en especificos recien ahi le enviamos los cambios al DOM

No Virtual DOM
No usar el virtual DOM

Responsive, no es igual al responsive design.

.
Resiliente: Cuando nuestra aplicación siempre sabe que hacer, en cualquier momento
.
Escalable: Siempre va ir creciendo sin importar la cantidad de usuarios que se sumen

Términos de reactividad.
Responsive:

1. Resiliente - Escalable:
   Nuestra aplicación siempre sabe qué hacer
   No importa con cuanta información deba trabajar
   la aplicación debe seguir creciendo y escalar
   Arquitectura basada en mensajes
2. Message Driven:
   Emisores y receptores de mensajes.
   Los emisores no entregan directamente los mensajes a
   los receptores; es decir, los mensajes no se entregan
   sincrónicamente sino asincrónicamente.

¿Qué es el estado?
Lugar donde guardamos la información reactiva de nuestros
componentes. Son variables a las que nos suscribimos para recibir una actualización cada vez que cambian los valores del
estado.

Paradigmas:

• Reactividad: Es un paradigma, forma de pensar para que el codigo funcione y siga ya sea (Descriptivo o Imperativo)
• Descriptivo: Siempre mostramos el como , que nuestro codigo se muestre claramente, paso a paso para resolver la tarea
• Imperativo: esforzamos en esconder el como y dejar el que del problema.
• Resiliente: si hay algún error por parte del usuario o del sistema, la app puede darle una solución para que pueda usarlo sin problemas.
• Escalable: no importa que tanta info proceses o las peticiones de lo usuarios, la aplicación pueda crecer sin problema o, sin tantos problemas.

Arquitectura basada en mensajes: Programar nuestras apps con emisores y receptores, los mensajes se entregan de manera asincrona, en una cola, en la cual los receptores se suscriben para que los emisores puedan enviarle los mensajes.

Patron de suscriptores, usa el patrón Observer y el ejemplo más conocido es RxJS de Angular.

Estado o State: Guardar la info reactiva de nuestros componentes. Variables a las que nos suscribimos a para recibir los estados de los datos. No siempre sabemos en que momento ejecutar nuestro código. Lo importante es con el estado, estamos suscritos y podemos reaccionar para cuando el usuario lo necesite

Render: Proceso por el cual nuestro código pasa a ser visual en el navegador.

Yo quiero el curso de reactividad!!!

• Resumen!

Paradigmas: Se puede programar de diferentes formas, pero hay caminos que son más cortos y fáciles. Ej. De paradigma: POO, Programación funcional.

Características de aplicaciones reactivas:
-Responsive: Resiliente (Muy buen diseño estructurado, saben reaccionar) y Escalable (Buen funcionamiento bajo un número masivo de usuarios e información)
Arquitectura Message Driven: Emisores y receptores de mensajes asincrónicamente se establece la comunicación.

Conceptos importantes de los Frameworks de JS:
Estado: Es el lugar donde vamos a guardar la información reactiva de nuestros componentes. Variables a las que nos suscribimos para recibir una actualización cada vez que cambian sus valores. Es un tipo de suscripción entre variables.
Render: Es el proceso por el cual las líneas de código pasan a ser información visual en el navegador.

Virutal Dom: Esto nace de la necesidad de NO recargar toda la aplicación, solamente ciertos lugares. Cada vez que hay un render se crea una copia del DOM en Js. Si deseas cargar una sección de comentarios, la pagina no se va a recargar completamente, solamente lo va a hacer la parte de la sección de comentarios.

Resumen de la clase1:
Conceptos básicos:

• Renderizar: Es convertir nuestro componentes en JavaScript en HTML.
• Paradigma: forma de pensar y traducir nuestras ideas a código.
• POO: convertir nuestros elementos del proyecto en clases para luego hacer objetos. Podemos extender las clases para generar variaciones.
• Funcional: no modificamos elementos, con cada cambio creamos una copia de ese elemento con las modificaciones necesaria.

Reactividad

• La reactividad es un paradigma, una forma de pensar en nuestro proyecto siguiendo 2 lineamientos: ser responsive y la arquitectura basada en mensajes.

Responsive: se divide en 2 puntos: resiliente y escalable.

• Resiliente: debe saber que hacer ante una mala situación como un error del usuario, un formulario que no responde, etc. y darle solución.
• Escalable: elástico, sin importar la cantidad de información o usuarios, la app debe ser capaz de crecer y seguir trabajando.

Message driven

• Arquitectura basada en mensaje es programar nuestra app con emisores y receptores de mensajes.
• Los mensajes se entregan asincrónicamente y se guardan en una cola a las cuales los receptores se deben suscribir para recibir el mensaje. EL gestionador de colas avisa la llegada del mensaje a los receptores suscriptos a esa cola.
• Internamente para implementar este patrón de suscripción utilizamos observadores. Una librería usada para reactividad es RXS, implementación en JS de reactive.
• Esta arquitectura es cómo funcionan internamente muchos Frameworks de JS para ser reactivo.

Resumen de clase3:
Como funciona la App:

• Dividimos nuestra app en componentes.
• Cada componente va a tener un estado y con esto se va a renderizar (HTML pintado).
• El usuario interactúa con nuestra página y van a modificar ese estado,
• Cuando haya una modificación en el estado volvemos hace render.

Juan, estás volando. Gracias por este curso, realmente viene a explicar muchas cosas para las personas nuevas en este tema

Una verdadera maravilla de explicación de reactividad y de el flujo entre componente, render, estado y usuario. Entre al curso, pensando que quizá debí saltarlo y termine repasando muchas cosas interesantes. ¡Lo voy a terminar! 😄

Aqui me parece que el profe se confundio un poquis. El paradigma imperativo muestra el como, mientras que el paradigma declarativo se esfuerza en mostrar el que…
https://en.wikipedia.org/wiki/Declarative_programming

Tengo entendido que los conceptos de Programación Descriptiva (o Declarativa) y Programación Imperativa están al revés. La programación imperativa es la que muestra el paso a paso de un programa, es una de las más antiguas y la que más conocemos cuando nos introducimos al mundo de la programación. La programación declarativa muestra el QUÉ pero no el CÓMO. Un lenguaje interesante declarativo ( y lógico) es Prolog.

!