En la clase pasada hablamos un poco de cómo funcionan los extremos pero qué es eso del patrón Blok.
Lo he escuchado un par de lugares y el manejo del Estado de mi aplicación.
A qué se refiere esto.
Bueno empezamos hablando un poco sobre el patrón Blok el cual es una forma para manejar el estado de
la data de nuestra aplicación pero no es el único.
Hay otras maneras de poder separar lo que es la construcción de los widgets de el estado de la data
de mi aplicación o por ejemplo el scoop model.
Tenemos el patrón Billups injerir widgets y tenemos también los providers entre otros.
Pero la pregunta del millón sería pero qué es y por qué usar realmente el por qué usarlo.
Se aplica a cualquiera de esos patrones no necesariamente al blog.
Pero qué es y por qué usarlo.
Primero que nada el patrón Bloc significa bisnes lo componen o lógica de negocio de un componente o
de componente el cual trata de que esté centralizada la información de nuestra aplicación.
Por ejemplo tener información de los usuarios de los productos de las películas de formularios entre
otras cosas suponiendo que nosotros tenemos un árbol de widgets parecido a éste.
Obviamente en la vida real son mucho más grandes pero eso es solo un caso ilustrativo.
Pero si nosotros quisiéramos comunicar unos widgets con otros entonces cómo lo podríamos hacer.
Miremos el caso en el que yo quiero comunicar este widget amarillo con este otro widget como lo haríamos
normalmente si no utilizáramos alguna forma de manejo de Estado de mi aplicación.
Entonces el widget amarillo tendría que hablar con su padre el padre con el abuelo y el abuelo con el
bisabuelo para que después se empiecen a redibujar cada uno de los otros widgets hasta llegar al widget
que a mi me interesa mandarle la información.
El problema es que cargamos innecesariamente a otros widgets con información que no necesitan y probablemente
nunca usarán.
Sin contar que añadimos complejidad adicional en cada uno de sus Willians.
La idea del patrón blog es que nosotros podamos extraer lo que es la lógica del manejo de la información
y centralizará en este blog en el cual si nosotros quisiéramos comunicar ese Willet amarillo le mandaremos
la petición al blog y el blog se encargaría de notificar al otro widget de manera directa.
Inclusive esa notificación del Willett amarillo podría afectar otros widgets y todos recibirían la información
en el mismo momento.
Un blog trabaja en base a streams y si se acuerdan del video anterior pues básicamente es como una tubería
o un río en el cual fluye información puede entrar cualquier tipo de data y sale cualquier tipo de data
también para la gente que ha trabajado con reactive Extensions como registrar Erec y JS Reckitt punto
net entre otros.
El stream es muy parecido a observable y el control es muy parecido a el swap y Vijay también de extensiones.
Recordemos de la presentación anterior que si nosotros queremos introducir información al string usaremos
el zinc y si nosotros queremos escuchar la salida de información lo vamos a hacer mediante un Extrem.
Yo sé que más de uno de ustedes dirá pucha cifrando como habla del cine como habla del stream pero necesito
que ustedes se familiaricen con esos términos por qué se van a usar bastante a lo largo del curso.
También hay tres puntos importantes que nosotros tenemos que considerar en un patrón Blok el primero
que debe trabajar únicamente con entradas y salidas de información para poder introducir información.
Usaremos lo que es el cine y para la salida usaremos el stream nuevamente y por último es importante
cerrar el estrecho cuando ya no lo estamos necesitando hablando más con flores.
Nosotros podríamos tener estos dos widgets tenemos un botón y tenemos un texto a presionar ese botón
que puede ser un widget que se encuentra inclusive en otra página o en otra parte como decir un modo
algo superficial que puede ser que no se encuentra directamente en ese widget rosado.
Entonces para comunicar estos dos elementos nosotros con nuestro widget potón evitaríamos lo que es
un Cink al blog.
El blog puede procesar la información y puede comunicarse con otros objetos como por ejemplo providers
los cuales se podrían encargar de realizar peticiones HTTP leer data estática realizar cualquier llamada
a algún API y eventualmente después de haber realizado cierta acción.
El blog se encargará de emitir información que fluye a través del Extrem el cual nuestro widget que
tiene ese texto debería de estar escuchando.
La idea principal de todo esto es que los widgets se encarguen únicamente de dibujarse y no controlar
el estado de la información.
Hay dos tipos de stream controlé tenemos los que son de suscripción y también tenemos los que son del
broadcast usualmente un string controlar por defecto es de 5 suscripcion y qué quiere decir eso.
Pues que cuando nosotros tenemos un widget y ese widget está escuchando ese stream entonces solo ese
widget va a poder escuchar si otros widget quisieran también la información de ese stream controles
no van a poder hasta que ese widget cierre esa conexión.
Es decir hasta que diga ok ya no me interesa más que lo que tenga que decir esté sin controles y ahí
otra persona podría escuchar Podrían mentalizarse como un confesionario en una capilla que solo está
el sacerdote y está una persona que está confesando entonces hasta que sale esa persona otro podría
entrar más o menos eso sería el concepto pero nosotros a lo largo del curso usaremos el brocas porque
puede ser que muchos widgets también les interese la información que emita y se controle.
Adicionalmente nosotros vamos a ocupar dos cosas un Zink y un Street.
El código más o menos se miraría así nosotros tendríamos una propiedad Goeth que se llama imput Zink
que se va a encargar de hacer la referencia a nuestro string controller .5 a esa propiedad para añadir
información a la corriente ok al inicio y también ocuparemos otra propiedad Jer en la cual nosotros
vamos a poder escuchar cualquier cosa que sea emitida mediante el estreno.
Tal vez este código se mira un poco raro la primera vez pero conforme lo vayan practicando y a lo largo
del curso usaremos bastante.
Espero que ustedes se familiaricen con estos conceptos.
Noten que en color verde tenemos la palabra string Extrem el string como una cadena de caracteres.
Eso significa que a través de ese string controle lo que fluye son cadenas de caracteres.
Eso es básicamente todo lo que quiere decir pero no necesariamente pueden ser string pueden ser números
pueden ser objetos pueden ser mapas pueden ser listas puede ser cualquier cosa.
Ahora si nosotros quisiéramos transformar la información que sale del stream podríamos utilizar lo que
se conoce como un string Transformer que básicamente solo sería añadir un pedacito más a el stream como
lo que yo estoy resaltando en este momento llamaríamos el Transform y colocamos una función que yo les
voy a enseñar un poco más adelante todavía no la vamos a utilizar pero ya la vamos a ver un poquito
más adelante en el cual eso podría aplicarse como un tipo de filtro o básicamente una transformación
de la información que fluye a través de mi stream.
Por último es importante que cuando ustedes ya no están utilizando el stream lo cerremos y para eso
lo llamaríamos de esta manera.
Y para eso nosotros crearíamos en nuestro blog un método llamado discours.
El nombre no necesariamente se llama así pero es una convención de que tenga ese nombre.
Ustedes van a poder notar ahí que hay un signo de interrogación.
Eso es simplemente como para preguntar si existe o si tiene algún valor el string controle y si lo tiene
lo cierre si no lo tiene.
Entonces no hacer nada.
Básicamente esa sería una construcción básica de un patrón block pero cómo se integra esto en Flores.
Existe un Willett muy interesante llamado el string Wílder el cual se va a encargar de dibujar un widget
cada vez que recibe información el tren.
Esa información no necesariamente tiene que ser información válida.
Puede ser que el Extrem vio un error y ustedes pueden reaccionar en base a ese error o si todo lo hace
correctamente entonces reaccionar en base a eso también el streaming.
Adicionalmente también puedes saber cuando la información todavía no es recibida como por ejemplo cuando
se está haciendo una petición HTTP que no sabemos cuánto tiempo va a durar pero el streaming vas a ver
que todavía no recibe información y puede dibujar.
Inclusive hay otro tipo de wiki es muy poderoso y bien interesante.
Ahora cómo funcionaría esto.
En la realidad.
Nosotros tendríamos algún widget.
Le voy a poner Willet a él el cual tiene un floriãn Action Boron el cual tiene un método hombres que
lo que hace es mandar al imput Zink y añadir al mensaje en cadena de caracteres que dice Hola mundo
y ahora tendríamos otro widget en otro lugar de mi aplicación el cual tiene un string Bildu.
La sintaxis se mira un poco extraño al principio pero conforme lo usemos ustedes se van a sentir más
familiares con esto.
El stream Builder tiene una propiedad llamada Extrem la cual tiene que estar escuchando de antemano
qué va a escuchar información de dicho string.
Entonces cada vez que el umpires suceda nuestro stream se va a redibujar por cada información que sea
emitida.
De ese output Stream.
Cuando eso sucede tenemos nuestra función Builder que ustedes deberían asociar cualquier video cualquier
palabra Bill en flores como la construcción de un widget en este caso se va a construir nuestro container
cada vez que tengamos información pero ese container puede ser cualquier cosa podría ser una tarjeta
podría ser un widget personalizado puede ser cualquier cosa.
Las propiedades que tiene ese Builder son el contexto y un snapshot el contexto es de tipo big context
el cual tiene la información del árbol de widgets temas y muchas cosas más y luego tenemos el Ising
Snapshot que eso sonará un poco extraño pero no es más que la información referente al estado del estrés
y la información que sale del mismo.
En pocas palabras el Snapshot va a tener la información que ya viene producto del estrés que va a tener
el estado del sim por ejemplo si está cargando si ya tiene información si hay un error entre otras cosas
entonces en base al Snapshot nosotros podremos hacer condiciones.
Y por último el lugar típico para cancelar o para hacer el disputase del blog es el dispones de un widget
que es una parte del ciclo de vida de un widget el cual se dispara cuando ya no usaremos más este widget
iba a ser destruido.
Entonces básicamente esa es una a lo que es el patrón Blok recuerden que el blog no es la única manera
de manejar el estado de mi aplicación al inicio de esa presentación les hablé de varios yo los invito
a que con ustedes terminen el curso.
Investiguen sobre los otros unos pueden ser más sencillos de otros y puede ser que ese sea el que ustedes
estén queriendo usar para implementarlo.
Como les dije a lo largo del curso yo voy a usar el patrón blog y antes de terminar el video solo déjenme
decirles que en la aplicación de películas que nosotros estamos construyendo en este momento implementaremos
parcialmente el blog.
Conforme vayamos avanzando en el curso vamos a ir creciendo en complejidad del mismo para que ustedes
sean introducidos de una manera sencilla al blog porque es un concepto un poquito difícil de comprender
al principio pero no es nada que ustedes no puedan aprender.
Así que los veo en el siguiente video.