Hola a todos, mi nombre es Adrian, estoy trabajando en Globo, estamos aquí, no sé si ustedes conocen Globo, estamos en el servicio de demand service.
Aquí estoy hoy, para hablar un poco de nuestro viaje, de que hemos aprendido a migrar a nuestro website de Angular2View.
Aquí en la primera ropa, hemos aprendido, sin duda, la mitad del equipo de Globo.
Si tienen preguntas, puedes también preguntar.
Pero, de alguna manera, vamos a empezar, ¿no?
Si, todos están aquí.
Ok, vamos a empezar mi historia desde el principio.
Digo que me gusta viajar, me gusta viajar mucho, me gusta viajar todo, pero lo que me gusta más sobre la experiencia de viaje es la preparación,
saber el plan, cuando haces una decisión, repites algunas revistas, procuras para viajar, y comparas a los precios.
Entonces, todos esos precios y emociones de preparar un viaje, eso es la mejor experiencia para mí.
Entonces, lo que quiero hablar hoy, como digo, desde el very beginning, es nuestro pequeño viaje,
el webteam es dos de nosotros, dos chicos con 2GabGlobo. Entonces, ahí estamos en el very beginning,
en nuestra casa, en nuestro país de sofá, a casa de disfrutar, el día es pasado,
la vida es maravillosa, en nuestro webteam departamento,
usamos Angular 1.6, siempre la versión más lenta, la versión más lenta, trabajamos un poco con CoffeeStrip,
programamos usando Puck, también conocido como Jade, usamos Stylus para portar todos nuestros CSS,
todo este tipo de cosas, usamos Cobb, Past, Manify, Clean, usamos buenas prácticas,
todo es muy bonito, pero casi todo, porque hay un caso especial, que no funciona,
pero ok, vamos a poner los CSS aquí, o ese lógico, en vez de ponerlo aquí,
por ahí, sería más fácil, pero no importa, todo funciona, así que vamos con eso.
Test, sí, test, ¿cuáles son esos? Sí, he escuchado sobre esos, pero es súper complicado
hacerlos en un webteam, no tenemos tiempo, así que todo funciona, vamos.
La vida era hermosa, disfrutamos de todo, pero tienes este tipo de sentimientos,
todo es tan frágil, todo es un tipo de mensaje, así que uno de esos días,
digamos a Glovo, ok, quizás debemos hacer algo sobre eso,
y decidimos ir un poco más adelante.
Entonces, después de leer y procurar un poco, ¿cómo puedo hacer nuestro app mejor?
He tomado una pausa de un hombre que sabe un poco de Angular,
es llamado Todd Motto, y él estaba hablando de Angular 1.5 componentes.
Entonces, esos componentes, si no saben lo que son,
pero deberían aprender más sobre esos,
pero esos componentes son un poco blackboxes, o quizás no tan black,
que encapsulate una parte de tu website,
para que puedas reducirlos en diferentes lugares.
Entonces, puedes pensar sobre, A, tengo este cartón de producto,
y pongo eso dentro del componente,
y luego puedo reducirlo en varios lugares en nuestro website.
Entonces, sí, eso parece bien,
leeré un poco sobre esos componentes en Angular 1.5,
sí, no parece tan difícil.
Entonces, vamos a probarlos. En el otro lado, componentes forman para que
sea más consistente, más estructural,
tener un arquitecto mejor.
Entonces, vamos, vamos a probar con un pequeño,
todo es genial, funciona super fácil,
parece bien, es limpio, es genial.
Entonces, vamos a probar algo un poco más complicado.
Los problemas comienzan a aparecer.
La navegación es más complicada.
Entonces, nos dice, ok, si hacemos eso,
ah, por favor, necesitas updates de tu librerón UI,
y luego todo el otro no funciona,
y todo el app crece,
y luego, para usar componentes en tu aplicación angular,
necesitas usar componentes en todos los lugares.
Entonces, sí, esa intención que tuvimos
de hacer cosas un poco mejor,
no se ha perdido, nos dice, ya, ya, let's take a look maybe later.
Entonces, aquí estamos de nuevo,
como en el very beginning,
estamos en nuestro comfi software,
pero no tan comfi anymore.
Estamos no tan disfrutando la vida,
porque, sí, todo está bien,
todo está trabajando en nuestro website,
pero sabemos que algo no es completamente correcto,
cuando nuestro team de marketing viene y dice,
ah, sí, hay algunos problemas con el CEO,
con tu web angular,
y tengo algunos artículos preparados,
dice, sí, hay ciertas dificultades con angular,
vamos a pensar en eso cuando agregamos todo,
ok, ok.
Entonces, eso es el sentido,
no estamos ofreciendo nuestra mejor experiencia
para nuestros usuarios,
y es algo que estamos construyendo,
y eso funciona bien,
no super, pero just ok.
Entonces, en el otro lado,
si queremos hacer nuestra aplicación mejor,
tenemos que hacer un full rewrite,
porque, sí, y eso toma un poco de tiempo
y un poco de recursos.
Entonces, aquí estamos pensando,
preguntando donde estamos,
donde queremos ir,
y en el final,
dice, ok, para eso,
vamos a escribir todo,
y vamos a hacer nuestra aplicación mejor.
Entonces,
interesante,
parece que hay muy pocos frameworks
alrededor de ellos,
para trabajar en los días,
pero, sí,
no,
vamos a ser realistas,
hay muchos de ellos,
pero cuando nos arrolla,
nos arrolla a tres,
imagínate,
sí,
esos tres en el fondo,
que son los principales candidatos,
porque queremos algo realista,
algo poderoso,
algo maturo,
que puede trabajar
en una gran aplicación.
Entonces, nuestros candidatos,
como saben,
son Angular,
Angular 2,
o Angular,
ahora mismo,
solo en Angular,
también tenemos React.js,
y luego tenemos este View
New Challenger.
Entonces, Angular es,
podemos decir,
fue el suceso lógico,
después de todo,
hemos estado usando Angular
en nuestra aplicación,
tal vez,
muchos de ustedes
están usando Angular 1.5,
o 1.x,
así que parece,
como el mismo movimiento,
como,
sería solo un upgrade.
Entonces,
tenemos React,
React,
no habrás escuchado sobre esto,
pero parece que es una opción
muy solidaria,
entonces,
sí, es un candidato.
Y luego tenemos View,
este nuevo Challenger,
que es el top trending,
en los últimos meses,
como,
es ganar más y más tracción.
Entonces,
sí,
debemos hacer algo correcto.
Entonces,
ahí estuvimos,
nos sentimos,
y empezamos
a ver a todos,
y decidimos
hacer la primera decisión.
Y la primera decisión,
fue,
me siento, Angular,
no podemos confiar en ti.
Eso sería,
la línea de línea,
sería la que no ha sido la línea,
o la línea de línea,
de lo que vamos a hablar,
en el próximo.
En el paper,
Angular miró
la solución de ideas,
como dije,
antes,
utilizábamos Angular 1.x,
se debería ser
un upgrade,
un par de tuits,
aquí y ahí,
y,
ya sabes,
se debería estar listos para ir.
Pero no.
Entonces,
si tienen que ver con el nivel,
de Angular 1.x,
a Angular 2.0,
no es tan fácil,
hay que usar libros,
puedes lograr eso,
pero antes,
hay que reivindicar
toda tu aplicación,
usando componentes,
y entonces,
incluso si logras,
hacer esta tipo de migración,
todo es un tipo de mensaje,
funciona,
pero,
nada,
necesitas un reivindico.
Entonces,
encima de eso,
tuvimos este tipo de
sentimiento,
que no era tan estable.
Es completamente arguable,
y podemos hablar de eso,
pero,
ya,
hay muchos cambios,
ya sabes,
entre las alfas,
las betas,
hay un gran cambio,
entre Angular 1.0,
y Angular 1.5,
y Angular 2.0,
que,
no nos encontramos,
no nos encontramos.
Y,
finalmente,
quiero hablar un poco
sobre la complejidad instrumental de Angular.
Entonces,
esta complejidad instrumental,
es un término,
que hablamos,
que podemos hablar de,
como,
tienes dos tipos de complejidad,
en tu aplicación.
Podemos decir,
que tienes la complejidad de la aplicación,
esa es la complejidad,
que lo requieres,
dependiendo de tu logística de negocio.
¿Es tu app,
justamente,
va a desplazar algunas imágenes,
o,
simplemente,
hacer alguna cosa básica,
o,
¿es tu app,
va a retirar una locación,
basado en eso,
retrasar ciertas,
y luego,
en tu posición,
tienes una complejidad,
que está implicada,
dentro de tu aplicación.
Y luego,
tienes la complejidad,
de tu framework,
del instrumento,
que trabajas con.
Entonces,
no es lo mismo,
que justices,
display un list en Angular,
que display un list en React,
que display un list en View.
Entonces,
tienes que,
encontrar una balance,
entre esos dos.
Si,
en tu aplicación,
ahora,
la complejidad de tu framework,
es,
es mucho más,
es mayor,
que la complejidad de tu aplicación,
estás desplazando.
Y,
si,
no es bueno,
puedes encontrar,
muchas dificultades,
para lograr ciertos resultados.
Entonces,
para nuestro sabor,
Angular 2.0,
tenía mucha complejidad de instrumento,
para lo que necesitamos.
Era,
muy complexo,
para empezar haciendo las cosas que necesitamos.
Entonces,
esa fue la primera decisión.
Me siento, Angular.
Estamos desplazando.
Entonces,
tenemos React vs. View.
Headline,
que nunca has visto,
o que nunca has read,
anywhere.
Y,
no voy a repetir,
todo el análisis,
hecho por,
más,
más,
cualificado de las personas,
menos,
hay tonos de comparaciones.
Pero,
digamos que,
sorpresamente,
o no,
sorpresamente,
esos dos frameworks,
son más similares,
que puedes pensar en.
Entonces,
ambos de ellos,
son poderosos,
y rápidos.
Tienes un montón de benchmarks,
de ahí,
y,
sí,
ambos de ellos,
son bastante similares.
Todos de ellos,
voy a skipar el próximo punto,
primero,
ambos de ellos,
son,
usan,
virtual DOM abstractiones.
Y,
se proporcionan,
los reactivos,
y composibles,
componentes.
Entonces,
con,
ellos usan,
ambos de ellos,
usan la misma arquitectura,
pero,
todos de ellos,
deciden que,
su opción,
es,
más,
mejor.
Fueron,
son,
reaccionan en cada aspecto.
Entonces,
es eso,
pero,
bueno,
ambos de ellos,
usan virtual DOM abstractiones,
y entonces,
tenemos estos frameworks progresivos.
Entonces,
ambos de ellos,
son progresivos.
¿Qué significa eso?
Inicialmente,
si te dices,
reacciones,
gs,
gs,
gs,
gs,
gs,
gs.
Entonces,
en el que,
ustedes usan,
que,
ustedes usan,
reacciones,
gs,
gs,
gs,
gs,
gs,
gs,
gs,
gs,
gs,
gs,
gs,
gs,
gs,
gs,
gs,
gs.
Y,
y,
Puedes añadir algunos ejemplos de estado usando libros de la tercera parte, puedes usar VX,
que es similar a los flujos, o puedes usar ReView, que es el equivalente a las opciones de reducción.
Así que eso es una cosa muy cool de ReAct y de View.
Angular, de acuerdo con todo eso, y si quieres o no, si necesitas o no,
puedes estar tirado con un router y algunos ejemplos de estado.
Así que, tal vez, no necesitas eso, así que eso es una cosa cool.
Con ReView y ReAct, puedes empezar small y escalar cosas como necesitas.
Y eso es diferente, pero no tan diferente.
El sistema de templación es diferente.
ReAct usa gsx, y View usa plain HTML.
Aunque no hay mucha gente que te gusta, por cualquier razón,
una razón extraña para encodernos en gsx, puedes hacer eso también en View.
Así que, sí, fue una decisión difícil en ese momento.
Y estamos discutiendo mucho.
Y, sí, puedes猜ar qué.
Puedemos elegir View.
Así que yo diría las tres razones principales de por qué elegimos View.
La primera es, sí, un poco mejor la performance.
No es muy importante, por supuesto, las dos son muy similares,
pero, sí, es mejor.
Así que, la segunda es Views Companion Libraries.
Estamos mirando a ellos.
Aunque ReAct tiene tonos y tonos de libros de la tercera parte,
los libros principales de View que están escribiendo,
el estado de manejo y la templación, son oficiales.
Es decir, son oficiales, es decir, que están encodidos y mantendidos por el mismo creador de gsx.
Entonces, tenemos una misma progresión entre esos libros principales
y el desarrollo de View.
Y, en ReAct, todas esas funcionalidades extrañas
están realizadas por tercer parte.
Así que, sí, eso puede ser una buena cosa,
pero también puede ser una mala cosa.
A veces, me lembro de algunos libros que refluxan el drama,
pero no es eso.
Pero la más importante es el sistema de templación
y la curva de aprendizaje.
Entonces, no me quedo cuando digo que
este último punto es la más importante.
Gsx es genial y muy poderoso.
No digo eso.
Pero aquí no sé si puedes verlo muy bien,
pero esas son dos formas de implementar una iteración
y un if, el otro en gsx
y un play en html en View.
Así que, sí, es súper genial, súper poderoso,
pero para mí y para nosotros, como equipo,
necesitar esos 20 líneos
para justificar un if y el otro
o 40 para justificar un loop
fue un poco... saints en la gente.
Esa era tan complicada con eso.
Con View, todo lo es parcejo html,
es muy fácil, tienes esos directores,
tienes los if, los if, los if, los if, los if, los if, los if
High click coding, estos tipos de cosas.
Aquella persona, y quiero decir esta persona
de nuestro equipo,
plan de tener, plan de comprar algunos desarrolladores juniores, es super fácil,
solo necesitas saber el JavaScript, solo necesitas saber el HTML.
El on-boarding en UGS es super rápido, la curva de aprendizaje es super suave y lenta,
confíe en mí, si no lo has intentado, no sé si muchos de ustedes lo han intentado,
pero lo intenta, lo hará bien, es super, super fácil.
Entonces, ahí estuvimos, decidimos el vio y decimos, ok,
vamos a empezar con la migración, ¿no?
Y vamos a empezar por el principio.
Si tienes una muy pequeña app, puedes empezar usando el vio,
como importar el script del vio y eso es todo, nada más.
Pero, si vas a hacer una gran aplicación que a lo largo de las cosas van a ser involucradas,
entonces las cosas van a ser malas.
Entonces, el vio le permite y recomienda una interfaz en la comanda, que se llama VOOT CLI,
VOOT VIEW CLI, así que, hazlo, si quieres desarrollar un vio,
en serio, hazlo. What does VOOT CLI provide you? It provides you right away a Webpack,
it uses Webpack under the hood, and it provides you a Webpack configuration,
out of the box, very simple and a very effective way to use view templates,
ES6 specifications with any kind of effort, everything, all the imports,
all the parsing templates, everything is already done and defined.
We have a hood reload that is completely amazing.
This hood reload that swaps components is kind of a live reload that,
you know, you make a change in your code and automatically you see the result.
So, another stuff that comes with ESLint, ESLint,
is a tool that checks how well you write your code, your JavaScript code.
Oh, JavaScript, yeah, JavaScript, CSS, HTML, if you want to basically JavaScript.
And the thing is that it forces you to write code in the right way, following some standards.
And what I mean that it forces you is like, if you don't write it the correct way,
it just crashes, you cannot continue.
Of course, you can disable that, but it's super recommended.
So, yeah, you will become crazy with all those alerts about extra spaces,
indentations, giving you the, you know, the urge to kill yourself,
every time that you forgot about, you know, a trailing a space at the very end of a line,
but, you know, after using ESLint, our code is super structured,
it follows the same pattern, the same standards, and, yeah, you get that.
And finally, also testing, I will come back a little bit later about that,
but it gives you testing out of the box, everything configured,
you don't have to worry about any kind of configuration,
you can start writing tests right away.
But, and there's always a bot, there's some cons with that.
The first one is that view, I view, Webpack is complex.
No, it's way more complex than God.
If you guys have tried both of them, like, out of the box, Webpack is great,
you start coaching some stuff, you say, hey, no, I want to also compile this kind of stuff,
I want to import some external JavaScript, I want to add some SAS to CSS,
transforming code, there's a bunch of stuff, I want to change the folders,
then things stop working, if you don't do things the right way,
but literally, you don't know what is going on.
So, there's that. Also, in the whole view application,
you can use ES6 imports and request, and it works super well with NPM.
But, if you want to use some kind of another repo,
another way of, I don't know, importing raw JS files,
or importing raw CSS, that's where the fun begins.
It starts working, there's some stuff that is not recognized,
so, there's that, the complexity that goes with Webpack.
So, but yeah, it's worth it, very, very, very worth it.
Second thing, first component.
So, we started and we said, okay, let's start with the first component,
and the first component is super easy, it's a few lines,
and yeah, that seems super great, but, in reality,
there's a bunch more things going on with you,
I don't know if you guys have touched that.
It seems, that's just the JS part,
but I'm going to go further on the next slide,
but here is quite a summary of what you can see.
You store all the properties,
all the reactive variables inside the data part over there.
So, everything that is inside here, it would be reactive,
and it would change on the HTML part,
if it's changed on the JS part.
There's some methods part over there
where you can just define your methods.
There's the computed part,
that is, if you don't know yet computed,
afterwards you will say,
okay, how could I live without those computed methods.
If you guys know Angular, and Angular 1.5,
actually, sometimes you need to display
the value returned by a function,
so you say, hey, I don't know, here, display,
or some condition that has, that is inside the function,
and that condition is evaluated in every digest cycle,
so if you want to be curious
and you just put a console log inside that condition,
you will see that it's launched hundreds and hundreds of times,
every time it's re-evaluated constantly in Angular.
In view, you put this condition inside the computed function,
and it will only be triggered once one of the variables
that are inside that function changes.
So, for example, if you have a computed function that says,
hey, my name is plus this dot name,
so that function will only be triggered
when the property this dot name is actually changed,
the rest of the time it will be not triggered,
so that for performance is super great.
Plus, you can import anything with, yes, six imports.
Those are the imports, so basically,
hey, I need that component,
so just import that from over there,
you need the load-, you will just say a import
that's a variable name that you give it from just load-.
And you don't need to actually say anything else,
because view will look into the npm folder
and will find the load-repo and will import load-
and you can start using it directly from there.
So, you can define helpers,
you can have some javascript file
or some root file set at any place of your code,
you just directly import that over there
and bam, you can use it.
And on top of that,
if you import that in different components,
Webpack will only import it once in your code,
that's a cool part.
But for the guys who didn't see that before,
so here you have your data bar,
here you have your methods,
you have some computer there,
and then those getters and setters,
we will come to that afterwards,
and here you can define some components
that you are actually using inside that component,
like nested components.
Apart from that,
we also do have this,
you can touch the lifecycle of a component,
so you can access to the before creation,
creation, before mounting,
mounting just before un-mounting
and un-mounted and before deleting
and deleting part of the component,
so you can do a bunch of stuff pre
and after rendering the component.
I want to go back there.
So you have that,
that was a component,
but the component,
that was just the JavaScript part.
Actually, Vue comes with its own template,
managed by Vueloader,
this little guide.
So you are not obliged to use them,
but it's highly highly recommended.
Basically,
what it does,
it adds in a single.vue file,
the HTML,
the JavaScript,
and the CSS part,
everything fun together.
That way you can define components,
you can define logic parts
of your application in a single file.
Everything is more salient,
more compact.
Plus,
on the plus side,
you can define specific languages
inside each one,
each part of those.
So here,
if we have our JavaScript,
or for example here you have,
so you say A,
that part will be the style,
but I want to use stylus,
so you can start using stylus,
but you can say A,
I want to use SCSS,
so you can start using that,
or you can say A,
I want to use SAS,
or I can just use CSS,
you could also work with that.
The same thing here,
JavaScript here,
we're using plain JavaScript,
but you could say A,
script,
and I'm using lang coffee script,
type script,
whatever you prefer.
HTML part,
you can use HTML,
you can use Puck,
you can use EGS,
whatever you need,
you just need to define here,
a tag saying lang equals that,
and then webpack,
you just need to import
the equivalent loader,
so you just need to do
npm install pack loader,
and that will do.
So,
that's super cool,
and that's a full view component,
so here is the.view file,
and the whole thing
would be a view component,
that you can move
and you can import
anywhere of your code,
in a very, very, very simple way.
So, that was the second stop,
so we created our first component,
everything went well,
very easy,
very,
very immediate,
you don't have to learn a lot,
you just put plain HTML,
plain JavaScript,
and plain CSS.
So then,
we said,
okay,
now we need some routing,
by the way,
if you want to interrupt me
at any point,
you have any question,
you want to see some code,
do anything,
so don't hesitate.
So, this is some routing,
we needed some routing.
So, the transition
from using the UI router
or just plain Angular routing
to view routing
was surprisingly easy.
You just need to be very organized
and do things in the correct way.
So,
basically,
as our whole application is
made of components
and nested components,
routing is so easy
that you just define a root
and what component will be rendered
in that root.
The good thing on top of that
is that you can define children.
So, basically,
if you define the root endpoint
inside one of those children,
you have,
I don't know,
the registration page
or the registration component.
It's inside your web app,
main component
or main content plus sidebar,
and here is the registration.
You just have to define
their child,
one inside the other,
and just in the final component
you'll say,
hey,
when I ping
slash register,
just load me that component
that is the children
of all of those components.
So, it will render all the components
in sequential order
and display yours.
If you want later on,
I will show you some real examples.
But super easy, super easy.
You can pass properties,
you can pass,
you can control the routing part,
so you can say,
hey, before changing each route,
do some logic
or before entering
or actually changing,
do some check
and redirect to some other place.
You could add a hook
and say, hey,
for any route check
if the user is authenticated
and if it's not just redirect you
to the login page,
this kind of stuff.
Super easy and super easy.
Networking.
So, we have HTTP,
direct to HTTP,
just in Angular.
And then, in view,
initially,
and when I'm saying,
I'm saying initially it was
with view 1.0,
the official library
for network calls
was called view resource.
In fact,
it was not developed
by the view team
but by a third party
that I don't remember the name.
And with the launch
of view 2,
the view team decided to remove it.
Not remove it,
but remove it from the list
of official libraries
because official core libraries
because it was not developed by them.
So, they say, hey, it's okay.
You can't continue using view resource
but we don't support it officially.
We will not be aligned with them
in terms of the development
of the view framework.
So, basically,
you have hundreds of options.
You can use whatever you want.
You can use view resource
in any call
and this is the way that you make
any call with view resource
but you can use browsers,
fetch API
or any library, in fact.
You can just, as we saw with ES6,
you just import the library
anywhere that you need that
and you just make the call.
Some libraries,
like Axios and fetch,
you can actually find some
wrappers around there.
So, they just wrap the library
with view so you can use it
anywhere,
like a normal view component
and you just,
you know, you put this dot, whatever
and you don't need to import it
every time.
But, basically,
now you can use whatever you want.
In the documentation,
View recommends you
to use Axios.
We are using Axios.
You can use whatever you want.
Axios is a very good library.
It has 15,000 stars
and it has anything that you would need.
Promises, whatever.
The only thing
Axios is fine with that.
So, the HTTP part,
the network calls super easy.
You can do whatever you need.
And then,
the important part,
root scope.
So, in Angular,
if something changes somewhere
and you want to,
if something changes,
you basically have
two options.
Well, of course, I'm talking about
something changes in some place
and you want to listen back
to somewhere else,
not like directly in the same
component, the same
controller, this kind of stuff.
So, in a very separate place.
So, Angular,
the normal way Angular 1.0
is the way to do that.
You could store the variable
as everyone says.
A, be careful with that.
Don't overpopulate your root scope.
And you could also
send events,
like broadcast, emit,
this kind of stuff.
And you could listen to those events
anywhere that you wanted.
In view,
inside the component,
there's
a very
defined
architecture and way to communicate
between components.
So, basically,
if you communicate,
you can only communicate
between parent and its file.
So, a nested component
inside that component.
So, imagine that you have your whole application,
you have the main content
and you have one thing here,
one thing there, so you can talk
between the child and the parent.
You put just this.enit
and the parent
will listen to that event
with an
on
parameter, on directive.
And then the parent
sends or passes
properties to the child with the props
part.
There's an example over there of a simple
content provided super easy.
Those properties
are reactive in one way.
Those are one way data bindings.
So, parent can
change values.
There will be a reactive inside the child.
But
if the child changes those properties,
it will not be affected in the parent.
It will be just rock out.
If you want to change something globally,
the child will send an event to the parent.
The parent will change that variable
and all the child will listen
to that change.
So, yeah.
What if
it's not parent and child communication?
So, as I said before
in Angular, without components,
events were global.
So, you could broadcast anywhere.
The root scope
was shared across everything.
Everything was wonderful.
You say, okay, let's use Angular 1.5
and fog everything.
Like, nothing was working.
There's a bunch of...
You can search and there's a bunch of articles.
Yeah, of course, there are many ways
to actually work
and actually make it work.
But, basically, Angular is 1.5.
This correction is good to say,
hey, I'm changing something here
and pass some events to listen
to those kind of stuff.
Because it's the correct way.
But that's been solved in Angular 2.0.
But for Angular 1.5,
they just say, okay, yeah, let's not do that.
With view, you have two options.
So, you have that component
over there
and you have that other component
on the other side.
For example, you are adding a product
to a cart
and you have a little cart
on the very top right
of your page.
So, you have two options
to actually
make the little cart reactive.
The first one,
it's using a global event bus.
Event buses.
In view, it's very simple.
You just define a new instance
of view and that view
instance will be shared
across all the components.
So, you just define a constant
bus equals new view
and then inside
that bus, you can attach
say, okay, bus.emit, bus
on and you will listen
to everything.
But that's not, you can do that,
but that's not the way
it's meant to be.
The way it's meant to be
is those states,
the motherfucking states
and we have a bunch of libraries
to use them, vx, review,
vstach, buffries
in a decreasing
way of complexity.
I would say that this list is
on maybe the last
we could swap them.
But this is where
things get serious.
Vx
We decided to start using vx.
Vx uses a
single tree state.
What is that state?
That state is,
if you don't know, it's a single object
that contains
all your application level properties,
you know, and serves
as the only source of truth.
So,
imagine that you have a tree,
that tree is private
and no one can change it.
No one, we're going to specify that.
But you know, you have a
big object with a bunch of properties
and no one can change them.
So,
what happens if you want to listen
to those properties?
So if you need to listen to those properties,
you will have getters
that are, yeah,
yeah.
Getters are not the final, but would be
in the purple circle.
So, those getters
very similar to a Java getter
it's just
a definition that you're saying,
hey, I want to get the value of that
property. Those getters
are reactive.
So, if at some point
in this state, that variable
changes its value, everyone
that is subscribed to a getter
will receive that notification.
Will go
in a deeper example
just after that
and will receive
the new value.
So, I've said that properties cannot be changed
that's not true, it cannot be changed
directly in the code
but they can be changed.
If not, there would be no sense
but the only way to do that
is through mutations,
that little red circle.
Those mutations are a very
small piece of code
that
make the little change.
So, you have
nothing else, like three lines of code.
The recommended thing is that
just make one change
inside a mutation.
So, you should have a bunch of mutations
each one for one small change.
So, for example, it's
I don't know, the mutation of
changing the name would be
the store
the state.name
equals new name, that's it
end of the mutation.
Those mutations can only
be called by the actions.
So, those actions
again, very simple
are just plain methods.
It will be the key element of a setter
in Java. So, in your code
you will say, hey, call
change the name
with that value.
So, that action is defined somewhere else
that will say, okay, you've called me
I will call the mutation
again with that property.
And that's it.
That's the cycle
the circle of life.
You are in your code, you call an action
that will change the value of a property
through a mutation
and everyone that has a getter
will listen to that change.
Let me show you
a little bit of code
so you see that.
So, we have here
this is
this is
not a part
but this is this little
this is this little thing.
So,
we have this component
and we say, yeah, great
we want to show
this hyperlotal address.
That's our address
that the user is currently
is the user
currently using.
The hyperlotal address
will change over time.
So,
how we are defining this
is we say, A
getter, getter, getter
here we have a get
that says A, I want to retrieve
hyperlotal.
Okay, and then
here we have
this
this
hyperlotal address.
So,
here we are saying, A,
print me what
hyperlotal address returns.
Actually, this is like a function
so we could save this but there's no need
to actually put the parentheses.
So, this will call
this hyperlotal address function
that is computed, as I said before.
And this defines
A, I have that
so when I have hyperlotal
and I do some sanity checks
but if I have that
just print me a pretty address
that I have inside
hyperlotal.
Say, okay, cool.
So, basically in this state
you have a state
you can decouple that state
in module so you have the logic
separated multiple parts
doesn't get messy.
So, I'm saying A, my state
by the way
has some city settings
and has an hyperlotal property.
That hyperlotal property has cool address
and it's okay, perfect.
And I'm defining some getters.
Those getters will be
you can do whatever you want here.
You're saying A, for example
I will have the getter hyperlotal
that what I'm doing is A
if you are asking me
hyperlotal, I will return you
from the state, the hyperlotal property.
But you can go deeper
and deeper, for example you say A, city
A, I just want the cities
so every time that I call cities
I will retrieve the state
city settings cities.
You could do a bunch of things
like filtering or reducing arrays
or
mapping some arrays.
You can came up with whatever you want.
So, basically we have this getter
that every time
that the state changes
it will return the state
hyperlotal.
A little bit down there
we have our actions.
We have the first one that we don't care about
and then we have, for example
this cool hyperlotal
action that says A
set hyperlotal, I'm passing you an
hyperlotal and I will
define a mutation
that I'm calling hyperlotal change
and the only thing that I do in that action
is commit the mutation.
It's actually calling that mutation.
Of course, this is a very simple action
you can have some actions
that iterate and filter some data
there's some actions that can
actually make call
this is a network call
to our backend
and then filtering the results
so you can do a bunch of stuff in the mutation.
So, here we are calling
commit our mutation
and our mutation is defined
here.
No, not here.
Here.
And the mutation as I said before
is just two lines of code
state.hyperlotal equals hyperlotal.
So, basically
when I'm calling
and the place where I call
that mutation
is
here.
In my pop-up
when I do some stuff
and in the end, I finish
and I retrieve a new
source
and I retrieve a new
address
I press
a wrong one.
So, in my address
when I finish setting the address
here you're saying
hey import
the actions and the getters
of my whole state
and in that little
small piece of code you say
hey from all the actions
I'm only interested in the set
current address and the retrieve categories
or
in the getters that are defined
there.
Here in the getters you say hey
I'm only interested in the current city
and hyperlotal.
So, what happens here is
this guy will say hey
there's a new address
then it will call
set the current address
that this is an action
that will call
our actions
where are the actions again
that will call
our action
that will set
that will call our action
of setting a city
that will call a mutation
that will change the hyperlotal value
and then in our front page
in our main page
as the hyperlotal value has changed
we will receive the new value
and without touching anything
the address from the very top will change
or of a state management
inside an application.
It seems difficult, it is not.
It is very powerful
and it feels right
after you start using this
it feels completely right.
That's the correct way
to handle those changes
and handle reactivity.
So, I'm nearly there
at the very end
during this trip
we've done of going from Angra
to Viu
we've battled
and we've learned Webpack
we've polished
our coding style
it was a completely mess
and adding ESLint made us polishing everything
we've implemented ES6 features
we are using imports
we are using classes
we are using new array bolting functions
we are
trying new HTTP libraries
we have redefined
our strategy, our plans
of routing how it should work
which component should be loaded
when you ping a certain road
but the most important thing
is that we've started
to think in terms of components
and state
and
the architecture of our app
has evolved in consequence
so it doesn't matter
actually
if tomorrow
I will use Viu or React
in fact, you can use Viu
or React, they are very similar
both share the same stuff
all that I've shown here
all these ViuX
the same thing in Flux
and Viu is very similar
and the same thing as Redux
so it's not about the tool
that you are using
but the concepts that you are going to learn
are starting to use Viu
and starting to use React
and those core concepts
that we've learned
are now ours
and we'll be able to use them everywhere
and now as I was saying
everything feels right
so yeah
it's not about the destination
it's what we've learned
during this whole month
more or less one month
we've been doing that
that's that
you have a promo code
that you can use in our app
you have a free delivery
but basically that was more or less
everything that I want to talk about
in our process of learning Viu
the image I did that
myself in Photoshop
so it's trademarked
I can pass it to you if you want
but yeah, questions
or anything that you want to discuss
everything is super subjective
and of course it's not
Viu is the best thing in the world
and don't use React, of course not
it's about what I wanted to say
learning those concepts
and using Viu instead of React
you learn those concepts
I think in a much
easy way
or a nicer way than less complex
let's say that than React
questions I'll say over there
viu.com