Secondly, how do you discuss methods?
No, first of all, in the panel, I'm amazed.
I dla pleno.
So yeah, the idea was basically
and he wanted us to talk about dez and redox.
And you all kind of
Así que decidimos darlo a diferentes acciones,
y en vez de decir que tenemos uno defendiendo cada otro y tal,
decidimos, tal vez, comenzar a hablar sobre el manejo del estado,
tal vez, hablar sobre el reaccionamiento,
y por qué estas soluciones existen en el primer lugar,
y luego intentando explicar cada una de las soluciones,
y tal vez, podemos hacerla un poco más interactiva,
y si tienes algunas preguntas,
podemos también responder algunas de las preguntas.
Tal vez podamos comenzar con una pregunta clásica,
por favor, cuándo te cuente, quién es usando el reaccionamiento aquí.
Perfecto, perfecto.
Un audienzo apropiado.
Y luego, un reaccionamiento clásico, quién es usando el reaccionamiento,
y Mobics.
Ok.
Puedo ver las legendas.
Muy genial.
Entonces, creo...
Puedes comenzar con esto.
Como puedes decir, aquí están los slides perfectos,
porque cuando hablamos sobre el manejo del estado en general,
intentamos pensar qué estado es.
Obviamente es como un ejemplo perfecto.
Aquí puedes decir component.
Cuando preparamos con PowerDIS Talk,
pensamos, ok, el reaccionamiento es un tipo de fuerza
para todos pensar en una forma funcional,
y todos piensan,
hey, el reaccionamiento es popularizante en ideas funcionales,
y luego PowerDIS Talk me dice, no, es OP.
Fully, fully, fully.
¿Puedes elaborar por eso?
¿Por qué es OP?
De tu perspectiva.
Sí.
Hemos tenido esta conversación antes.
O sea, puede ser ambos,
pero a partir del box,
básicamente reaccionando lo que se promueve,
es tener el estado cerca de tu funcionalidad.
El reaccionamiento ya viene con el manejo del estado.
Entonces, para comenzar con algunas de las preguntas,
no necesitas reducir o reducir, porque el reaccionamiento
ya viene con ese estado.
Y lo que hacen es, básicamente,
es un principle muy básico, que viene de Small Talk,
que fue cuando la gente intentaba
figurear cómo construir programas,
como alguien muy inteligente, no sé el nombre,
decidió que sería conveniente
si el estado estaría cerca de la funcionalidad,
y luego podrías encapsular la funcionalidad con el estado.
El reaccionamiento funciona exactamente the same.
Entonces, mucha gente dice que el reaccionamiento es muy funcional.
Es conveniente.
Veamos esto cuando hablamos de Redax.
Pero al lado del box,
también tiene una interfaz muy objetiva,
que significa que cada componente encapsula la funcionalidad
y encapsula el estado.
No sé si eso es más o menos claro.
Exactamente.
No me recuerda.
Puedo decirlo.
Sí.
Puedes explicarlo.
Sí.
Si tienes esta interfaz,
la única manera de mutar el estado interno
y cualquier componente de reaccionamiento,
lo sabrás, es solo pasar propias a este componente.
Porque no hay manera de que cualquier componente,
como el parent, el niño,
o cualquier función,
si estás al lado del componente,
obviamente, si no haces cualquier extra hacke,
o cualquier cosa extra,
no hay manera de mutar el estado de este componente.
La única manera en la que puedes hacer eso,
es como, hey, tienes propias nuevas,
y depende de estas propias,
vas a hacer algo con tu estado.
Es la única manera de hablar con un componente como eso.
Y eso es genial, porque tienes un black box.
Tu pasas propias como un dato a tu componente,
y luego algo pasa internamente,
y el estado está informado.
Sí.
Es por eso que es un objeto completamente reaccionado aquí.
No hay manera de ir
y directamente mutar el estado de cualquier otra entidad aquí,
que es genial.
Pero el problema empieza.
No es un problema, es obviamente,
una cosa clásica cuando tienes dos componentes.
Wow.
Tienes dos componentes,
y quieres ver estados entre ellos.
Imagínate que tienes...
Hay un buen ejemplo dentro de la documentación.
Tienes dos ingresas,
y una de estas ingresas,
y una de estas ingresas,
que es el temperature calculator.
Tienes una ingresa que puede meter data en Fahrenheit,
y la segunda ingresa cuando puedes meter data en Celsius,
y están en sync.
Si colocas una, la segunda es subida, y vice versa.
Tienes dos componentes,
y tienes que ver entre ellos.
Si no tienes
una manera directa para mutar el estado,
la única manera que puedes hacer es para elevar el estado.
Hay animaciones, Dandan.
Así que necesitas mover este estado a tu parent,
a tu parent de la componente,
y luego este parent va a decir a tus niños,
¡Hey!
Se va a manejar el estado,
porque no necesita toda esta componente
para tener estado,
y luego va a pasar la data
para los niños.
Es un ejemplo clásico,
y creo que hay una buena descripción
dentro del Doc itself,
pero cuando empiezas a construir
no tan complexas aplicaciones,
sino más que dos componentes,
este problema se realiza
y empiezas a pensar
en donde debería mover mi estado.
Normalmente, el estado se arregla
hasta que tengas en tu componente.
Pero el problema aquí,
es que puedes ver que estoy muy cansado
de poner en el espacio
para mover componentes alrededor,
y eso es,
tienes más y más componentes
dentro de tu aplicación,
y te necesitas,
a veces,
mover los estados,
en y en y en y en.
¿Por qué es tan difícil?
Perdón, ¿puedes preguntarte?
Si tienes un gran truco de componentes,
como cualquier aplicación normalmente,
y si estás en el estado,
en y en y en y en,
¿por qué es tan difícil?
Bueno,
estás cumpliendo el estado de manejo,
con la forma de tus componentes.
Así que,
de repente,
quieres duplicar un componente,
o quieres mover algo alrededor,
y te end up
adaptando todo el truco
hacia allá.
Entonces,
te realizas
que quieres hacer un poco de cambio aquí,
y te end up
adaptando un cambio
hacia la ruta.
Y eso no es lo que quieres.
Tienes en realidad una encapsulación.
Entonces,
te empezas a violar
estos tipos de conceptos
que estaban bien,
que quieres date
y todo esto.
Esa es una de las buenas cosas
que React ha,
es que básicamente,
el componente representa
una unidad,
y se siente muy bien en React
cuando puedes only update
ese componente
y todo eso funciona,
y solo tienes que
composar
los componentes
y todo eso funciona.
Eso puede ser problemático.
La isolación es excelente.
Y la segunda cosa
es también por eso
es como problemático,
como de cualquier
perspectiva de desarrollador
que te necesitas
mantener todos los propios
que quieres pasar
hasta la ruta,
al final del truco,
te necesitas
comenzar a pasar
a ellos
por encima de tu aplicación,
y es como un dolor.
No quieres
tener cualquier componente
que pase
en 50, 60, 100 propios,
porque imagino
que va a ser
como una ruta.
Y la segunda cosa
de los problemas
que tienes que hacer
de eso
es como
cualquier update
a tu estado
o como
totalmente reconciliar
tu aplicación
que es un problema
de performance aquí.
Incluso si React
es tan cool
y sale virtual DOM
y todo eso,
virtual DOM
no es un problema normal.
Un problema
cuando tienes
tu propio
single thread
en el browser
totalmente bloqueado
por reconciliación
y solo
chequean
este componente
o no
o quizás
o quizás
tener una pequeña interacción
con tu aplicación
podría ser problemático.
Sí.
Me olvidé de esa.
Entonces,
podemos introducir
el continuo del estado.
Tenemos
el estado
en algún lugar,
y luego
tenemos
las compañías
que llegan
de este estado
directamente
la data que quieren
y eso.
Es genial
porque puedes
mutar
y mover las compañías
alrededor de la ruta
sin problemas
y no tienes
también problemas con eso
porque estás rendiendo
solo lo que necesitas.
Sí.
Entonces,
cuando hablamos de MobX y Redux,
hablaremos
básicamente
de este patrón,
aunque verán
que MobX
de hecho
puede ser
un suplemento
de estado
pero básicamente
vamos a hablar
de tener
un estado global.
Así que básicamente
de repente
no tienes
ninguna encapsulación
y empezas
a tener estados
separados
de tus componentes
y
cada uno de ellos
tendrá una manera
de intercambiar
con ese estado
que es bastante radically diferente.
Entonces,
lo interesante para nosotros
es cómo
nuestros contenidos,
nuestros componentes,
básicamente
nuestros tres componentes
se suscriban
a este estado
y ellos
pueden revender
y pueden comunicar
con el estado
para hacer cambios
y así.
Pero
MobX
y Redux
están basados
en el mismo
problema
que es
un estado
con componentes
y no
quiero todo el tiempo
pasar propias,
no quiero
cada vez
reconciliar
la toda la tierra.
Si
hay un estado
usado aquí
y aquí
y cambia,
solo quiero
estas componentes
para ser updados.
Entonces,
¿cómo suscribí
clavemente
en vez de
reconciliar
la toda la tierra?
Y así.
Así que
creo que
podremos empezar.
Tadam,
tadam.
Creo que sí.
Tadam,
tengo que decir.
Así que,
creo que
terminamos con la teoría.
¿Pero que tienen
preguntas, por favor?
No,
preguntas.
Comenzamos.
Así que,
como pueden ver,
la fiesta de hoy
será de tres jugadores.
Hay
un estado
dentro de la reacción,
un nativo.
Entonces,
vamos a
hablar de MobX
y Redux.
Obviamente,
si te preguntas
por qué
debería elegir algo
sobre
nada,
es como
decirlo.
Y
la primera
que tenemos que empezar es la localización.
¿Puedes hablar
sobre la localización?
La localización.
La localización.
Ok.
Sí,
no puedo hacer eso.
Así que,
básicamente,
como hablamos inicialmente,
el estado puede ser
localmente en las componentes
o puede ser
externo en las componentes.
Entonces,
el estado,
como decimos ya,
es completamente local.
Cada componente
tiene un estado
y solo importa
su propio estado.
En los términos de MobX,
también,
podemos usarlo
dentro de tus componentes,
similar a
cómo el viento trabaja también.
Entonces,
podrías tener
datos observables
dentro de tus componentes,
pero también podrías
tenerlo en el exterior.
Entonces,
básicamente,
no sé si deberíamos introducir
antes de hacer
quizá
algunos de los conceptos
detrás de cada uno.
¿Puedes
hablar
sobre la localización
y luego podríamos.
Ok.
Yo me empujo en la regla.
Ok.
Así que,
básicamente,
podemos utilizarlo
como un replicamiento
para un estado de estado,
y estas personas
usanlo
como un
store global,
como Redax.
Entonces,
puede ser usado
para ambos.
Puedes actualmente
hacer ambos al mismo tiempo.
Es útil para ambos.
Y Redax,
es básicamente,
un solo tono,
es un store,
es una caja,
es un global,
que todo el mundo
tiene acceso a.
Entonces,
esta es la diferencia
en donde el data
está ubicado
en las tres
frameworks.
Cualquier cuestión,
entonces,
es Mobics,
como este cool
thing,
que podría ser usado
como un componente
o un global,
pero,
¿es la principal manera
de usarlo?
Entonces,
hay personas como 50-50
usandolo,
como 90-10.
Ok.
Entonces,
es una de las principales
diferencias
entre Redax y Mobics.
So,
Redax
es una forma
de usarlo.
Entonces,
cuando usas Redax,
puedes usarlo solo
de una manera.
Tú tienes la cifra,
tienes los reduciores,
tienes los creadores de actos,
tienes...
El framework
está ahí,
y tienes que usarlo de esa manera.
En Mobics,
puedes actualmente
construir tu propio,
que algunos personas
encuentran interesante,
algunos personas dicen que es...
que te da mucho frecuencia,
pero básicamente,
no te hace formar
tu estado de forma
de cualquier manera.
Entonces,
puedes tener,
como dije,
algún estado en el componente,
algún estado fuera,
puedes tener el estado
mirando como un gráfico, por ejemplo,
mientras Redax force a vosotros en el estado
para mirar como un truco, vamos a hablar de esto más tarde.
Así que, básicamente, es un poco más para cowboys,
yo diría.
Entonces, efectivamente, hemos visto aquí la misma discusión
que nos encontramos, a veces, hace mucho tiempo,
escuchamos sobre la reacción de Amber,
que es una reacción en la que tienes todo en el libro,
y con la reacción, tienes que jugar tu propio set de Lego.
Yo tengo que decir, con Redax,
también tienes que jugar tu propio set de Lego.
Así que, debes usar Redax, Redax Tank, o Sagas,
o debes usar esta mediaware o el otro.
Yo creo, y no creo que hablamos de complejidad.
Yo creo que ambos MobX y Redax son bastante complejos
para el maestro.
Yo diría que MobX es difícil de comenzar con,
como, puedes obtener tu primera reacción y tu primera reacción
muy rápido.
Pero es, en realidad, cuando quieres entender
lo que está pasando y quieres maestro,
puede ser también difícil.
Así que, yo diría que ambos MobX y Redax
serán difícil de jugar tu propio Lego, o tal, así que.
Tu se.
La siguiente cosa es que queremos hablar de la sinchronicidad.
Es como la manera en que estés updado.
Y como la reacción reacta a este estado.
Así que, la primera cosa es como, yo creo, oh, vamos a votar.
¿Es un estado de sinchronicidad o sinchronicidad en reacción?
Es genial.
Porque es como, yo creo que es una de las más tricas cosas.
A veces, las personas están viendo eso en reacción,
en el estado de sinchronicidad.
Así que, no puedes garantizar que la próxima vez,
la próxima línea que te llamas después de ese estado,
ese estado va a ser lo que te llamas antes.
Y, a veces, eso podría llevar a los bugs,
porque el tercer parámetro de ese estado es como el callback
que te puedes llamar después de que es finalmente ahí.
Just like, I think.
Pero en MobX y Redax no es el caso,
porque decidieron, OK, vamos a hacerla simple
para que la gente se entende, porque no es muy bueno
con la naturaleza de nada.
Eso es por eso que debemos hacer todas las noticias sinchronicidad.
Sí, y esto es, por cierto, este es un artículo famoso
de MobX, autor, que básicamente dice que ese estado de sinchronicidad
no es tan obvio, y él mencionó a varias veces
que se encontró usando ese estado de sinchronicidad
por la naturaleza sinchronicidad.
Así que esto es por eso que, en realidad,
algunas personas no usan el estado de sinchronicidad
y se usan MobX, porque quieren su estado de sinchronicidad,
y quieren tener esta productividad
cuando están mutando en el estado.
La siguiente es la subscripción.
Así que para ese estado, creo que es obvio
que va a ser implícita, que cualquier componente
ahí se escucha a su propio estado y automáticamente
updates, así que no necesitas hacer nada, excepto.
Cada vez que te llamas en este estado de sinchronicidad,
te esperas que hay algo.
Para MobX, es la misma historia.
Sí, MobX, y esto es, en realidad,
creo que es lo importante si queremos definir MobX.
Creo que es la mejor manera de hacerlo.
Así que básicamente, el concepto de MobX
es muy fácil de entender.
Creo que a veces, las personas no entenden eso bien.
Pero es básicamente que MobX
proporciona algunas estructuras de datos que están observables.
Entonces, tienes un estado de sinchronicidad,
tienes primitivos, o tal.
Entonces, básicamente, son como objetos normales,
pero tienen las capacidades observables.
Cuando te integras MobX con React,
te rompe tu método de rendimiento
con un auto-run, que es un concepto de MobX,
pero no ves esto.
Pero básicamente, cuando te acceso
una de estas datas observables en tu rendimiento,
se enfoca en esto.
Así que, imagínate, rende a un usuario.
Se usa solo el nombre.
Entonces, dice, OK, yo utilizo el nombre de este usuario observable.
Entonces, estoy enfocando en esto.
Si nada más cambia de usuario,
no voy a renderte.
Pero si el nombre cambia, voy a renderte.
Entonces, básicamente, el principal
es que, lo que te usas para renderte,
se va a enfocar en esto.
Y cuando esta data cambia, se va a renderte.
Entonces, es un principle muy básico,
pero creo que es una muy clave.
Porque te permite no tener que suscribirte a la data.
Te rende, básicamente, tu stuff.
Y MobX, automaticamente, va a dar los hooks
necesarios para renderte.
Un ejemplo, y eso es muy probable,
dice, en tu rendimiento, tienes un grande yif-else.
Entonces, si esto, y hay un gran enlace de code,
en el enlace, hay un gran enlace de code.
Dice, en el primer paso, el yif,
se está enfocando en un observable.
Dice, el usuario es admín.
Y admín es un observable.
Se rendirá el primero.
Y luego se va a enfocar en ese yif.
Entonces, si te cambias admín a false,
se va a renderte de nuevo.
Y se va a ir a la segunda parte de los yif-else.
Entonces, es por esto que dice que es implícita,
porque funciona como un estado de estado.
No te dices el componente y escuchas
a los cambios de estado de estado.
Recuerdas automáticamente.
Con MobX es lo mismo.
Eso es lo mismo.
Algunas personas no realmente,
a veces, saben qué es mi componente de suscripción.
¿Es rendido demasiado?
¿Es va a ser?
A veces, las personas sienten que no tienen control,
con, creo que es implícita, el API,
siempre que las personas sienten que les gustaría más control.
Pero, en el mismo tiempo, de la caña,
le da muy buena performance.
Y es, es,
fue muy bueno, en mi opinión.
Ahora, ¿cuál es la defensa?
Y para Redux, es implícita,
porque para conectar cualquier componente de Redux,
solo necesitas usar Connect Helper,
de Redux, no de Redux.
Y donde pasas, normalmente,
todos usan MAPStateToProps,
es como esta función que dice,
ok, tienes una caña ahí,
la caña está en algún lugar,
no es muy importante en dónde.
Y luego, de llamar esta función,
vas a transformar este estado
en los propios que este componente va a obtener.
Entonces, de la perspectiva de interfaz, es muy fácil,
porque, como, si,
imagínate que todos somos los componentes de react,
y incluso si estamos conectados a Redux,
estamos obteniendo propios como datos.
No estamos hablando de un estado,
sobre algunas cosas magicas,
de la unión o nada más,
estamos escuchando propios,
y eso es solo nuestro camino
para obtener el dato.
Entonces, podemos moverlo a nuestro estado local,
o algo así, pero no pensamos
realmente sobre el estado global,
solo propios.
Esto es genial, porque, como,
realmente, es una especie de separación clave
de preocupaciones,
cuando tienes tus propios componentes
que espero en propios,
y luego tienes tus selectores,
esta función que cambia
este estado global en propios,
en sí mismo,
pero a veces es también trícico
cuando veo personas pensando que, ok,
tengo este gran estado,
y luego escucho solo
el username o algo así,
y espero que
el react no vaya a render,
el estado no va a ser cambiado,
y entonces, ok,
mi Redux component, el react Redux component
escucha solo el username,
que en realidad no es cierto.
MAPState to Props es una función interesante,
que es llamada
cada vez,
cuando tu historia está informada.
Por ejemplo,
imagínate la aplicación
que incluye chat
y tasks.
No voy a decir
qué aplicaciones es, pero
teoreticamente,
estas son totalmente dos worlds separadas.
Tienen chat y tasks, y no se conectan,
pero si imaginamos
que todo este data está viviendo
en un store, como Redux Store,
cada vez que recibes una notificación
o mensaje de chat,
todos tus tasks que escuchan
a la historia Redux, van a ser
also update, no realmente update,
porque el react está haciendo reconciliación y todo eso,
pero van a ser notificados,
que hay algunas nuevas datas,
que quieren verlo.
Redux está intentando
hacer una forma muy complexa
de optimizaciones en la hoja, porque
es muy simple,
pero en realidad está haciendo mucha cosa
ahí.
Pero, a veces, lo fail,
y es muy bueno si intentas entender
cómo está funcionando en la hoja,
porque la optimización de performance
con Redux podría ser muy dramática.
Sí.
Eso es el punto.
Yo creo que,
y creo que
probablemente es la diferencia
entre las propuestas,
y obviamente
hay personas que
una o la otra por diferentes
razones.
Una forma que me gusta sumerir es que
con Redux
puedes finalmente
aprobar el site funcional
de React, lo que significa que
claramente separas tu estado
y claramente separas tu presentación.
Puedes tener tus componentes
de funciones que no tienen
cualquier tipo de estado, y son funciones
de estado de funciones.
Eso fue el propósito inicial de React.
Es que
en realidad, el UI es
una fórmula de tu estado.
Eso es muy bueno,
y eso es algo que puedes hacer con Mobics.
En términos de la estabilidad,
es muy bueno,
porque como el Ilias 8, todo es prop.
Y tus componentes
pueden ser puros,
y eso significa que no tienes que
cuidar
las portaciones, etc.
Que vamos a hablar sobre en el siguiente
slide.
Es un poco como programar en C,
donde tienes que cuidar manualmente
sobre la locación de memoria,
así que tienes que
explicitly suscribirte.
Cuando te suscribes,
puedes muy bien
estudiar,
y la misma metáfora
que vemos, si no tienes performance,
puedes conseguir lo más de
eso, porque tienes la locación de memoria,
o cualquier cosa, no hay mágica,
si te llamas la colección de grabación,
mágica, pero puedes
oversubscribe, puedes subscrever,
que es un poco truco
cuando te compras
ciertas problemas de performance.
Me gustaría sumerirlo como esto.
Correcto.
Es muy bueno tener alguien que concreta.
Mujer al siguiente slide
es la mutabilidad.
Sí, porque el estado de estado
es obviamente mutable.
Y si quieres cambiar algo,
tu tipo de colección,
no sabemos
cómo está funcionando en la hoja, pero la idea es
que te mute a tu estado,
y no puedes conseguir el estado
de tu componente.
Entonces, teoreticamente en las hojas,
puedes conseguir el estado anterior y el estado siguiente,
pero el tiempo de traje
no, el tiempo de traje, el tiempo de viajar,
como es uno de los puntos de salida
de Redux, no es posible, porque
no tienes la historia de la historia de los cambios.
Y creo que la misma historia es
sobre Mobics.
Exacto.
Eso es lo que tenía que decir.
Mobics funciona
similarmente al estado de estado,
en el sentido de que, como dije,
solo son estructuras que puedes mutar,
y cuando te muta, pueden reaccionar.
Y, en realidad, esta reacción,
cuando te integras con el reacción,
es que te pregunto si hay un componente,
aunque también puedes usarlo
para computar
el estado.
Así que, básicamente,
eso es algo que
estoy hablando de ahora, porque
tal vez no tengo otra oportunidad
de hablar de eso.
Pero una cosa
que el autor de Mobics
realiza es que
no es solo BUs reaccionando
al estado, pero también es el estado
reaccionando al estado.
Entonces, la clásica es cuando tienes un listo
de usores, y quieres decir
que eso es el número, es en realidad
la lengua del reacción.
Puedes también decir que a la edad de este usuario
puedes hacer cualquier tipo de computaciones.
Y él realiza
que muchas veces,
y él pide un ejemplo de
poner una imagen en Twitter,
y él solo aparece en uno lugar,
y no aparece en el otro.
Entonces, muchas veces, nos duplicamos el estado.
Y cuando te duplicas el estado,
tienes el problema de no estar en el estado.
Entonces, él dice,
por stabilize,
ви provide
comentarios del estado
Kind of
apoc и
que est going Anyway want to
compensate
and anything else should be derived.
So what he does is that when you
mutate this data you can actually
ips data.
obsolete
a certain certain properties.
data in the state itself.
So if you have any data that you can calculate, please
calculate it inside the render, inside anywhere.
And if you want to perform and optimize, you should
component update, or components will receive props, or any
other stuff.
But please do not store any derived data in the state.
And I think all three of our contestants are using the same
idea here.
But yeah, going back to the main topic, it's mutable,
meaning that every time you update something, it's updated,
there's no trace of the previous values.
So in this sense, it's completely mutable.
While in Redux, obviously everything is kind of
immutable because of the idea.
So the idea of Redux is that every time you're passing,
we are calling an action creator, which emits action,
and then reducers are listening to this action.
Every reducer, I know that maybe you don't know, if you
don't know the concept of Redux, sometimes it's like, oh my
gosh, action creators, reducers.
So reducers are returning the new state based on the previous
states and this action.
Sometimes they ignore if they don't understand this action,
or sometimes they do something, but returning a new state.
So the main problem and the main debugging problem that
sometimes you're thinking that, oh my gosh, my react is not
updating or something is not working with Redux, is that
you are trying to see your reducers and you're seeing
when you're mutating state and not returning a new object.
And for Connect Helper that I was talking before, it's
totally killing idea, and it's expecting you to return a new
state every time because of the nature of Redux.
Sometimes it's cool, sometimes it's not, as always
with immutability.
The cool thing of immutability is that you can do the whole
story of what happened with your data.
You can do time travel, debugging, time travel, whatever
you want.
Call it, call the debugger tools for Redux were really
using this as a selling point for them.
And sometimes it's even cool when you can use it on
production because if user sees some strange state inside
the UI, you can just ask somehow the user to send this
state to yourself and then you can totally replicate this
state on your local machine.
And I know, for example, that Sentry is using this approach
and they integrated their own bug tracking, fail tracking
tools with the Redux so you can have the whole state of the
user with your error message there.
I would add the whole iteration and the iteration.
You have the state somewhere else, let's say on an API or in
local storage or whatever, having the state somewhere
else and saying, OK, that's now the state.
It makes it very easy with Redux.
Because in the end, what you have, it's a big tree.
It's a immutable tree.
It's something that you can serialize, you can store, you
can bring back.
So it's very useful.
And that's one of the things that I think, for me, it's one
of the best selling points of Redux.
One example of this, I think last week, they recently
released Redux of Line, which is an extension to Redux that
allows you to actually work offline with your application.
And there's also a very interesting other project.
I think we're going to talk about the other one when we talk
about logging.
But I think the whole concept of that your state, you can take
your state, pack it, put it somewhere else, unpacking it,
bringing it up, and then it's there.
Because you're separating clearly what its state and
presentation.
That's very powerful.
And that's, in my opinion, the key feature for Redux.
So Redux is better than Mobux.
If you need time traveling, name two applications that need
time traveling.
No, I'm joking.
Yeah, then we have a shape.
Feel free.
Yes.
I remember well, when you used to set the state, you also have to use a function of the previous state, because it's not synchronous, am I right?
Yes, so the state is not synchronous, but it's not really, like, so, like, the definition of
set state is that you have three arguments.
The first one is that you are setting the three arguments or two arguments, like, two arguments.
I remember well, if you pass a function, that takes a previous state.
No, you can pass an object or a function.
So there are two shapes of set state.
And they're pushing more and more for the function one.
Yes, because otherwise, if you pass an object and you, let's say, the classic toggle, it's a button that it's active or not active.
And if you say the state is the negation of the previous state, that may not work if you click twice, because the state is synchronous.
But if you use the function, the function, it will just run passing you the correct state.
So they recommend using the function one.
If you're just saying the state is equals full, you can use object.
And also you have a callback.
The second parameter is a callback, yeah.
So when it's the state already there and you can be fully sure that it's set.
So I thought that redux is like taking that concept, maybe you have no idea if I can't see redux, but this is the same concept, no?
A function that takes the state, the previous state and returns the new state.
Yes, but separated completely from the component.
So in the end, what you have, it's a big tree of state.
So let's say you have your users with this, with this, and then it's a shape of a tree.
And what you have is that reducers will go after the tree and we'll try to see if there's something that has to be recreated.
And then it will return a new tree.
So it's kind of similar in the sense that it's a function that returns something else, like all the reducers are these.
But it's completely different in the sense that it's completely separated from the components.
Yeah, moving back to shape, yes, so the shape is just like the, where are you like storing your data and with state-state it's like totally star or asterisk here because you can save whatever you want.
But normally people save in objects and with mobics it's graph, why?
Yeah, so that was one of the things that was more challenging for me with redux.
So yeah, spoiler here, redux is a tree, we said it like a thousand times already, but it was sometimes for me difficult to imagine how to map my state into a tree because my state was not a tree, it was a graph.
It was, I mean a tree, it's technically a graph, but it was a graph that it was interconnected, sometimes it flows, I had relations, let's say a user has a task that belongs to a project and a project has users and these and all the objects are kind of related.
And for me it was really challenging, the fact that I was forced to use a tree.
As I said before, redux forces you these kind of conventions and because of that you can do all the, all the, you know, hydration, dehydration, you can really have a separate thing.
With mobics you can have any kind of shape, you just have your objects and you can relate them how you want, you can have computer properties from other ones, so you have much more freedom, which some people find challenging, some people say no, no, I want strict clear rules,
I really want to know how to structure my store and that's not mobics, mobics doesn't tell you how to do it, so you can find a little bit lost there, but it gives you freedom.
But by the way redux also says nothing about the, like the general, so that says you better not have more than one store.
Yes.
Interesting, so we have a discussion finally, in reality what redux tells you that hey, we have like a couple of best practices that's like Dan Abramoff and the team thinks about that they are like right because of the experience of building implications and the main best practice is like to keep your store normalized.
So please do not do like really deep graphs when you have like everything inside everything or just like authors and then you have books and then you have like no pages or something like this.
Please do not do that and do like different tables and then maybe like one or two levels of missing because it's going to be just easier, easier from the developer perspective to update, to read, to connect, to do everything.
But this is just an advice, theoretically you can do whatever you want with your state and save there and like in what shape and what form you want to do that.
And the same about like the tree idea, if you don't want to use tree, you can not to use tree.
It's like that what's composed reducers, the function from redux for doing by default.
It's like creating a tree, but feel free not to use it if you don't like it.
Okay.
And with multiple stores, it's the same idea.
Like normally like the kind of the, not the best practice, but the main use of reducers when you have like one huge object and people of like normally really like scared about this idea.
Like, oh my gosh, I'm like storing all the states in one object, what's going to be with garbage collector, my browser is going to die, all the users are going to complain.
En realidad, it's not the case and I never saw the same people like saying that, oh my gosh, store is like 100 mega to one gig and it's killing my browser.
So, but you can, you can like separate the store in two pieces, five pieces, ten pieces depends on you.
It's like no one forces you'd like to have only one store and use it like for the whole application.
If you like loading something asynchronously, like feel free to have two stores or like to merge the asynchronous store into like the main store that already have been loaded.
Like, totally full flexibility here.
Although then you lose the ability to pack everything, bring it with you and pack it whenever you want, which I think it's one of the best, I mean, you can like pack multiple stores.
You can pack multiple stores, yeah, but then you can do the same with more examples.
Okay, so yeah, one of the things that I find annoying in React and they are apparently improving it with fiber, it's traceability.
So when something fails or there's something that doesn't work, sometimes it's not really easy to know what causes it, you know.
And many times the stack trace starts at React and you're like, yeah, but I did this update or I did something and I only see the React stack and I don't see the origin of what do I do for this to happen.
So we set a state, this is the case, you know, like you don't really have a very traceable way of knowing why things updated.
So there's absolutely no logging, as far as I know, I don't know if you're aware.
And we say this logging because MobX and Redux do actually log things and they do it in a very different way.
So we thought it was interesting.
So set state, it's like when React just started everyone was writing mix scenes because it was really a thing at that time, just to hook into component will update or component will receive props and just see, okay, what state was the changes for the state and what are the changes for the props.
So you can just log into the console or do whatever you want, but yeah, that's the maximum that you can get out of the set state logging.
Yeah, so in MobX you have logs, so basically you can wrap any observable modification into an action.
So basically you can say, let's say we change the user setting from admin to not admin and you can say this is an action, it's disabled admin, you know, like very similar to how it works in Redux where you have your action creators that create these strings, their actions.
So MobX does the same.
There's actually a strict mode in MobX that allows you to only be able to mutate state if you wrap it into an action, so it forces you to make it explicit, and then whenever this mutation happens, as a side effect, it will lock this information.
So important thing here, it's a side effect.
So it's something that if you have the depth tools, you can see, you can have very similar, not as good as Redux, I have to say like Redux depth tools are the best out there, but you can have similar kind of log and you can see all this happened and this and this,
and because of this, this reacted and because of this, this was computed and so on.
So you can see actually all the cascading effects and you can see why your application is in the state that it is.
But, very important, it's a side effect. It's not something that it's baked into the framework.
Redux, it's exactly the opposite.
Yeah, because I think it was one of the sailing point when Dan Abramov came with the idea of Redux that he wanted to do time travel debugging, when you have a slider or you have actions and then you can click through them and the application is just moving forward and which is more interesting back in time on all the user actions.
So you can start with empty inputs or some view of your application and then move forward and again back to the all stages that the application went through.
And it's awesome because developer tools, it's like the whole ecosystem of developers tools really blossomed after that and like open source community created like, I don't know how many, like visualizers to all these developer state.
Time travel, like time machine in a Mac, or you can have like a graph, like build it all, like D3 visualizations, like seeing like your state updated with like all the really, really cool animations and it was awesome.
I'm not, like, but being really frank, I'm not saying it's like, it's ultra useful every day, like, but sometimes it's really cool that you have this opportunity and it's just like seeing some really strange bug, you're activating it and you're seeing like everything that happens to the store.
And sometimes it's really awesome if you have this in production, because users are complaining that yeah, something happened to your application, you're going there, you're like either asking if it's not users or QA, like to copy the whole state and get it back or just like to debug what's happened to them.
To debug what's happened to the tree, like the state tree by itself.
And I think it has interesting properties.
Again, as I said, Redux enables truly functional programming, you know, like while React out of the box or MobX, I think they are more oriented onto object oriented approach.
So, again, this lock works a bit the reverse of what we used to. So, I always, when talking to Lea about this, I made a comparison with the database.
When you do a change on the database, you mutate it and then there's a lock as a side effect, like MobX, that gets there.
Interestingly, a lot of databases use this lock to actually replicate.
For instance, MySQL, they use this lock to replicate, and it's a way that they can also mutate the state. So, Redux works sadly this way.
You talk to Redux through a lock, so you're basically appending these elements to this lock, and then through the reducers, it mutates the state.
One very interesting approach recently, I don't know who it's called, this project.
LogX?
LogX, yeah.
This interesting approach, for instance, someone was thinking, well, the way we do real-time right now, it's kind of broken.
We're all the time synchronizing state from the backend to the client, and it's always very difficult.
If we have this concept of immutable lock, why don't we apply it to state synchronization between the backend and the front end?
So, basically what they did, it was very cool, and they used this immutable lock, MySQL would use it for replication, and as a server, you could just append things to the lock.
Then the state would change on the application, and whenever you change something on the client, it will append on the lock, and it would change on the backend.
So, this idea is quite powerful, because it gives kind of an immutable place where all the things are happening, and then it allows both ends to synchronize state in a reliable way.
While in a mutable landscape, you wouldn't be able to do this reliably.
So, I think that's really powerful. It's not, as Ilya said, on your daily life, you may not use it that much, but it enables some things that maybe still have to come that are powerful, in my opinion.
I think that we really missed one slide here about the whole ecosystem, in general, because the idea of Redux is so basically good, in the right way, kind of.
So, you can see a lot of open source applications, or libraries, using it under the hood. So, for example, if we're talking about GraphQL, it's a new hot topic, it was before only Relay, now we see that Relay is not the number one anymore.
It's like a PolographQL, it's like the number one that everyone is using. Under the hood, it's using Redux, because why not? It's already awesome, we can just even enhance the experience and just use Redux as a main stage tool for the state.
In the same story with Logax, or a lot of other plugins, that just like using Redux state, and then allowing you to use all the cool things around. Even middlewares, or plugins like Redux offline, that just allows you to save your state locally and totally forget about problems with detecting if user went offline,
using the server, should we show something, should we not show something, it works out of the box, totally transparent for you, and you're not even thinking about that.
Yes, an extra slide. So, I was thinking, it's really important to see, do we have Dan Abramov for every of these solutions? So, for said state, it's partially, because he's like on the core team of React, for Mobicsnow, and for Redux, obviously, it's true.
So, disclaimer, he's Russian, Dan Abramov, and he has a crisis on Dan Abramov, but that being said, that slide, it's partially wrong, Dan Abramov said himself, you don't need Redux for all your projects, now he works on React core team, and he pushes quite on the state.
That's why it's partially wrong.
Also, he mentioned many times how awesome Mobics is out of the box, but yeah, Dan Abramov said, it's cool.
And we don't have slides anymore.
Okay, oh, and then we can leave it with Dan, no?
Yeah, maybe we can wrap up a little bit.
Yeah, we can do like answer questions, we can do a small round of discussion.
I would like to wrap up a little bit. So, we wanted to first, before diving into the different solutions, you know, we wanted to talk about said state.
We found, and that's an opinion that Dan also shares, that many people rely too early and too much into the external kind of store.
I don't think you have to choose between one of the three. I would say you probably have to use said state plus something else, unless you really want to replace it with Mobics.
But I think it's very important to understand first how said state works and, you know, like how React works before you dive into one of these two.
I think both Mobics and Redux, they have different learning curves, but they are both, I would say, quite difficult to master.
Although, you know, with Mobics you can get some results quite early, and that's one of the selling points that, at the time of the results, it's quite early.
To master it, it's quite difficult, the same as Redux.
So, whenever you want to do it, you have to remember that whenever you have something global that many people will access in any programming environment, that's always a challenge.
So, having a global store that many people will access and you have to kind of subscribe and so on, whatever you use, that's going to be challenging.
Ok, so that being said, I think it's time for the questions.
Yeah, I'm just like thinking about action items.
If you don't know React, please try with said state.
Don't try Redux Mobics at all, because it's like the main question that, hey, I'm learning React, what should I use?
Said state, just that, because no, no need, it's already like, learning could be high, and said state will give you like a lot of, can bring you far, far away, even without Redux, Mobics or any other new high tech there.
And if you decide to like to learn Redux in the right way, I really suggest you to go to Egghead and to listen to both of them courses there on how to structure.
No, no, no, no no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no.
Ah, no.
En algún momento de tiempo, aprendimos cómo usar Redux de manera correcta antes.
Pueden salvar mucho tiempo, como dibujar y poner la estructura en la escena,
porque los cursos son muy geniales y les recomiendo que escuchen a ambos de ellos.
¿Quiénes?
¿No seas chico?
Mi pregunta fue...
¡Has tenido la mic!
Mi pregunta es, ¿cuál es ese chico? Porque no lo sé.
Creo que ese es el problema, no usas Redux, por eso no lo sabes.
No, así que Daniel, básicamente es el creador de Redux,
así que es por eso que él dice que no se puede ver aquí, porque no sé cómo hacer esto.
Pero él es el creador de Redux, ahora trabaja en el equipo de Facebook.
Y básicamente es un chico que hizo mucha comunicación,
él estaba muy bueno en comunicación, él estaba muy bueno en enseñar a las personas,
él tenía muchos artículos, él tenía muchas opiniones de lo que diría.
Aparte de ser un buen desarrollador, él era un gran comunicador,
que no es siempre lo común encontrar a ambos.
Pasa, pasa.
Ah, ok, ok.
¿Tienes la mic?
Yo no tengo experiencia con MobX, pero estoy usando Redux en una gran aplicación,
y estoy buscando que, a veces, si usas el Connect Helper
en cada de tus componentes, te encuentras un grupo de componentes con tu estado.
A veces es demasiado profundo, puede ser demasiado profundo,
como si quieres cambiar un poco de tu estado, tienes que revirar o cambiar un montón de componentes.
Así que puedes revirar ese componente con el Connect Helper
a uno más alto en el estado.
¿No tienes el mismo problema con MobX?
Porque todo será más copiado con los componentes.
Bueno, en este caso, copiar es bueno,
quieres ser explicado, así que en este sentido,
si tienes un componente que es...
se relaciona con una empresa, y eso es lo principal.
Es un gran componente, porque en MobX tienes muchos empresas,
entonces no tienes una.
Si lo hicieras, puedes también tener muchos en Redux,
pero no es lo que es usual.
Entonces, digamos que tienes cinco componentes, cinco empresas,
y por ejemplo, lo colocamos antes,
lo colocamos, el que solo necesita el nombre de usuario,
así que este se va a copiar con el usuario.
Cuando cambies algo, lo único que tienes que really update,
es que si has to listen to a a new store,
you will import that new store,
so that's going to be explicit,
but you're not going to ever have to change the stores
unless you really need to change something on the stores.
So, and that, I have to say,
I find in Redux a bit complex sometimes
that I want to make changes in components,
I end up doing changes on the reducers,
and now he's going to...
Ok, but yeah, I find the separation more clear.
But if you have like your complex internal structure,
like pages, users, names,
and then you have an array there,
and you decided like, ok, I'm going to move users out of pages
like somewhere.
But that's not, it's a graph.
So that's the difference, it's a graph.
You have users, store, pages, store, this, store.
It's completely separated.
If I want to know how many pages this user have,
that's a computed thing.
So you basically compute the relationships.
So you don't really nest your data,
you don't give it a shape,
your data is on their own stores,
and you can compute the combination of them,
but that's just a side effect.
You don't have to think beforehand
how is my data going to look.
I'm just going to have...
For me, I compared a lot to SQL.
So you have your databases,
you have your tables,
and then you query,
you can do your joins, you can do whatever.
But your data is fully normalized.
So this is why I think the graph idea is powerful.
Yeah, I think normalizing your data helps a lot.
Yeah.
If you did that wrong...
That's why I'm saying, listen to them before you start.
If you don't know,
if you start out with this big, great store,
and you forget to normalize stuff,
for example,
and only later you find out that it's a good practice.
What helped for us,
it was to introduce an API for the store.
So imagine you have your selectors,
because selectors,
normally people I think are reselectors,
I'm more complex,
but these are just the functions
that return you parts of the store.
If you think about it,
it's like your public API of the store,
so you have only selectors,
functions that they get in state,
and then sometimes they return you data there.
And you don't really know
what's the internal form of the store itself.
Then you can really easily refactor your store
without changing the components.
Because components are calling just inside
map city props,
they're just calling functions.
Like a black box there.
Thank you.
Can I ask two questions?
Okay.
You talk a lot about actions,
like user actions,
but there is a time,
so what's,
which in condition of time,
let's say I have something expires
by midnight,
how each of them handles,
or what's the way.
I can talk about Mobex.
So as I said,
Mobex,
I talk a lot about how Mobex interacts with React,
but Mobex itself can work in any,
like a standalone.
The only thing it has,
as I said,
it's just observable data,
and some function that it can run,
you know,
like a callback when the data modifies.
So basically,
you could have a certain interval,
you can have anything,
and whenever this happens,
it just modifies the data,
and whoever is listening to that
will change automatically.
There's a good example
in the Mobex documents
about implementing a clock
in Mobex,
and it basically does the ticks,
and it moves around.
And totally the same story for Redux,
because action creators,
they're just like functions
that generate sections,
and they could be called
on user action,
but they could be called
on anything else.
So again,
set interval,
or something like what do you want,
it's going to call these functions,
and then they're going to
generate an action,
and store going to be updated.
And the second question,
if I do Redux,
would you use a RxJS,
would I supersede Mobex?
I never use a RxJS,
so I don't know.
I can tell a little bit, yeah.
Depends on how you're going to use a RxJS,
because if you're going to use
Redux Observables,
it's like the bindings
between RxJS and Redux,
but that's going to replace you,
like action creators more,
and it's going to be like
another layer on top
of your synchronous actions.
But I think,
you can just do
the same idea of observables
in a RxJS,
and it's going to be the idea
of Mobex,
because it's just observable.
But on performance level.
Just use Mobex.
Just use Mobex.
I mean, it's easy.
Why plug two things
if you can have any one, you know?
If we're going,
talking about like Redux
and optimizations,
I don't know,
depends on you again,
your Redux tree,
and from the React perspective
and Mobex,
I think it's going to be
kind of the same.
More questions?
Thank you for the talk.
I think you've been missing one slide,
which is unit testing.
Can you discuss about it a bit?
Yeah.
We've missing a lot of slides,
actually.
This one, I think it's crucial
in this part.
Especially me, that I haven't done any.
Yeah, as I said,
I will talk on behalf of Ilya.
So you really appreciate
that it's not a debate,
it's a collaborative talk.
As I said,
obviously,
anything that doesn't have
side effects,
it's more testable
because it's very easy
to test input-output.
You say,
this goes in
and this goes out
and that's it.
Like unit test,
it's very easy
when your components appear.
It's very easy
when your reducers appear
and so on.
So, yeah,
I think Redux
it's much better
for unit test.
But from my perspective,
the main pain point
in testing Redux
is only action creators
because it's theoretically
the only place
you can have a synchronous CT.
Also the mutation
of reducers.
But reducers are synchronous
and you can just like,
it's like a function.
You're passing state initial,
you're passing some action there
and you're expecting the output.
So it's kind of like...
That's clear.
That was more the question
about Mobex
because of the magic
under the hood.
About what?
The question
about unit testing
more related to Mobex
how to test it.
I have to say though,
in Mobex
you don't really test
the reaction itself
because that's like testing
something that's already tested
by Mobex library.
So you test the stores,
you know,
like if I do this,
this happens,
you know,
like this mutation happens.
Let's say,
imagine you say,
I want to increase the counter.
So you test
this function
then the counter is 2.
So obviously
what you're testing
it's a mutation.
It's not,
you know,
like this object
then it returns
this other one
that it's mutable.
So it's not
it's not that it's bad.
It's just that
I think
testing immutable things
it's easier.
So,
so in Mobex
and tests
you're just like
doing after-run
and then you're checking
things.
Yeah,
so you can test
the same as you would test,
you know,
like a mutation
or something here
what do I expect
the result to be.
If I
if I increment this
what I expect
the end result to be.
So,
it's,
you know,
it's normal testing
as you would do.
The only thing is
I think it's
what it's cool about
with AX
is that you can
you can treat
your tree
as a snapshot
and you can easily see
you know,
like the different
kind of states
that it would leave
depending on the states.
So,
on the actions.
Hi.
Do you have any tools
or ways
that you can
test
or see
if it's something
that you do
or a state structure
that you use
is performance
is a better performance
than another one
or
do you use
something to
test to
calculate that
or to.
I think in terms
of performance
Ilya is the
is the one
who had to deal
with all the crap,
so.
So,
no,
the main thing
that you need to start
you just need
to go to react
the tools
and activate
the
there is a tick
like please visualize me
all the updated components
because it's going
to be a first step
if you're seeing
that's your
slow, please do that
and then you're going
to see
what components are rendering
more than they should
and
and then
the question starts
why
and that's
the interesting thing here
because in terms
of performance
the main thing
as I said
is like the understanding
that every time
something happens
to the store
like
map state to props
is called
and then depends
on how you
structure your components
how you write them
they could be like
the components
could you render
or not
and this again
depends on
your selectors
it's hard to say
there is like
rule of thumb
or something like that
so
after you
found your components
that are slow
to see
it's going to be
your first step
to debug this
another question
when
when
is it there is a rule
I know it's not a rule
but sometimes
you have like
patterns
where
when do you put
state in a component
and where
do you not put
state in a component
for me
it's a really
kind of
easy rule of thumb
if I want to share the state
I'm
like putting it in the store
if
and again depends
like between
2 components
between 5
10 components
if I'm not sharing it
it's okay to
be a state there
locally
I have the cousin
the cousin rule
which is
I will apply to
programming
not to real life
but
sorry
so basically
I would say
always use
state
whenever
you feel
this
not a sibling
but someone
who is a little bit
farther away
like a cousin
like a component
that it's
maybe connected
but a little bit far
then maybe
I would think
about
extracting it
but I always
always start
trying to use
state
as much as I can
and then whenever
I say
no, that's too painful
then I move it away
I think that's
a rule that works for me
kind of
thank you
hombre, Ferran
he doesn't need a microphone
he has a powerful voice
and a beautiful one
no, the learning curve
about both technologies
I have been using
redax and mobex
and
in my opinion
mobex
has a
lower learning curve
because
it's
with all the observable
thing
is
dealing with
all your reducers
and
selectors
and all these things
that you have in redax
it depends on the
I don't know if in redax
you can
apply something else
to
to reduce this curve
because
instead of fighting
in actions
and reducers
and
go to your application
I think there's actually
an open conversation
in the redax repository
and they're actually
talking about like
ok, people is complaining
about the boilerplate
what do we do about it
so I think they're actively
right now
kind of discussing
what does this boilerplate mean
the
knowledge
kind of like the
the cognitive
cost that it has
when you get introduced
to redax with all these concepts
and so on
so it's something that
they are talking about
I would say in my opinion
as I mentioned
I wouldn't say one is easier
than the other
I think they have
different learning course
I think both are really
hard to master
so
I would compare them
with an instrument
so like
I would say Mobex
is more like a guitar
that you can take
you can do some chords
very easily
and you can sing a song
and it looks great
and then
if you want to be
like Jimi Hendrix
it's quite difficult
I would say maybe
Redax is more like
playing the saxophone
you try the first week
the first month
still doesn't
you cannot get
a note out of it
but you know
it takes more or less
the same amount of time
maybe to be
jungle train
so I would say
you know
like they have different
yeah
you like this metaphor
yeah
that makes me happy
so I would say
they are both complex
they have different
learning course
but I wouldn't say
one is easier than other
they are both complex
they are complex
problems to solve
they are not easy
I think the here is also
like a thing
of a context
because if we are like
thinking about learning curve
we are obviously
thinking about like
okay what baggage
we have already
of learning
and I think
people are normally coming
from like
OP
or like things
that we can mutate
and
in my opinion
it will be totally different
if everyone
for everyone's
first language was Haskell
so then it will be like
oh my gosh
Redax is like a homeland
what are you doing here
with Mobix
and yeah
because
the problem with Redax
Redax by itself
is like 100 lines
in code
it's ultra simple
and the idea of like
the code
that you may have there
by the concepts
the concepts
yeah you need to grasp them
you need to understand
what reducers are
what like
are they doing in general
what action creators are doing
and why they
are even there
and what action is
like if you're trying
to distill every one
of these concepts
they are super again
simple and easy
because like reducers
just function
action creators
another function
object
so but like
obviously
we are all humans
and we are trying to
apply our previous knowledge
and it just
doesn't match
and that's why you have
least all cognitive problems
and disannounce
and then you're thinking
like to stop
being a developer
but then you look at Dan
and you say
hmm
he was right all the time
any other question
one second question
oh you're cheating
how did you feel
when you discovered
how MobX subscription
thing works
because
the day that I discovered
how MobX works
was like
oh my god
this is one thing
to be done in compiler time
but he's doing it in run time
and for me it was really hard
but I ignore it for a while
and it was good
you know
I think it's very good
out of the box
so the performance
it gives you know
the subscriptions
the map
I would say almost
one to one
to what you expect
to map
but it's true
that you have to know it
so there's a common problem
with MobX
is that you don't realize
that you're not
unboxing a value
so you're not actually
observing it
you're just passing it
and then you expect
that parent component
to re-render
but it's not
and like
we had one issue
and we were like expecting
and it was actually
re-rendering
as it should have to
but we didn't really grasp it
because you have to understand
when it hooks
to that value
so I think it's magicality
it's great
when it works
when it doesn't
you have to remember
how it works
and implicitness
it's always a bit tricky
so
I think it's a good idea
for out of the box experience
and so far
I haven't had problems
but as I said
to mastery
you really have to understand
exactly
when it will hook or not
one example
and I think you made it
is if you have
if you're rendering
it's not
it's not deterministic
like let's say
imagine you have an if
else
and the if has a math
random
bigger than 0.5
then
you really don't know
what it's going to
hooked into
because it's going to
go into one branch
or the other
and then
you hold deterministicness
it's gone
I think Ferran had one
no?
yes
I forgot
ah, yes
ah, yes
ah, yes
ah, yes
is there any concept
is there any concept
of subscribing to some event
or it doesn't have any sense here
like
a user was created
so
maybe some components
want to do something
yes, yes
I mean
in terms of
in terms of redux
there's no such a thing as
events
like
everything is action
yeah
but on that way
on the kind of subscription
it's basically
you pass the state
and then
everything subscribes to the state
so like
every time you subscribe
to something
and you're saying this
okay, I'm interested
like in this part of the state
every time state changes
you're getting identified
to this callback
so it's just like
a pretty classical callbacks
in JavaScript
I mean
in terms of mobex
it basically
if there's an array of objects
and you subscribe to that array
whenever
a user is added
then you will be notified
but there's no
you cannot attack
these events
with a name
right
so
oh, people receiving
ah, ah, ah
ah, ah, ah
sorry
bad question
ah, ah, ah
ah, ah, ah
ah, ah, ah
ah, ah, ah
ah, ah, ah
ah, ah, ah
ah, ah, ah
ah, ah
y, ah, ah
ah, ah
ah, ah
ah
ah, ah
ah, ah, ah
ah, ah
ah, ah
ah, ah, ah
ah, ah, ah
ah, ah, ah
ah, ah
ah, ah
ah, ah
ah, ah
ah, ah
ah, ah
ah, ah
ah, ah
ah, ah
ah, ah
ah, ah
ah, ah
ah, ah
ah, ah
¿Puedes hacer algo para optimizarlo en un momento?
Redux es hacer nada, pero React to Redux.
Es como una otra packager que conecta Redux to React.
Es hacer mucho de cosas para optimizarlo en la hoja.
Entonces, cuando se llama Connect, es la cosa que conecta.
Reacto componentes a la escena.
Es already like returning your high-order component.
No se, pero eso funciona.
Y eso checks all the things like to optimize stuff.
Porque básicamente, puedes decir, yo tenía esto,
ahora yo tenía esto, es lo mismo, entonces va.
Así que eso es todo.
Gracias.
Móvex, puedes suscribirte a nada,
dentro de nada, ¿verdad?
Sí.
Entonces, ¿cómo limitas a ti a no empezar observando
todo y acabar siendo como Redux?
Yo no creo que hay que limitarse a ti.
Entonces, Móvex sale a ti como un spreadsheet.
Entonces, digamos que tienes un spreadsheet con números
y puedes tener un gráfico.
Cuando cambias un número, el gráfico cambia.
Pero puedes también calcular algunos números,
que puedes también publicar.
Entonces, puedes, en realidad, todo,
puede ser computado de todo.
No creo que eso es malo.
Deslizando datos, es bueno.
Entonces, no sé por qué deberías limitarse a ti.
Pero puedo circumventar, como, algunos espacios de historias.
Puedo empezar a escribir a otros espacios de historias.
Es para enviar a propias y así.
Entonces, puedo sitiar aquí y escuchar
a lo que hay gente hablando en el otro lugar,
y luego algo más, y algo más.
Es como, es un error humano, lo que estoy preguntando más,
porque...
No sé la pregunta, perdón.
Sí, creo que estará protegido de error humano.
Desde que todo es observable,
y yo puedo observar cualquier componente,
¿cómo te restrictas a ti?
No seas...
Sí, entonces, la cosa es que,
solo vas a reaccionar a las cosas
que realmente necesitas renderte.
Entonces, si necesitas renderte tres cosas
de diferentes espacios, te vas a agarrar a esto,
pero no necesitas suscribir a otros,
porque no necesitas renderte.
Entonces, la actual renderte es lo que
hace que te suscribes a las espacias que necesitas.
Y entonces, si necesitas suscribir a 100 espacios,
eso es un gran pez de componente,
pero eso es tu fallo, pero es bien,
porque esa componente necesita
esos 100 espacios para renderte.
Y, en realidad, una de las cosas que me he olvidado mencionar
es que si tienes dependencias circular,
es decir, este objeto es este,
este, este, este, este, este, este, este.
Como Mopex es el tipo de detector de fluxo,
entonces, se rende infinitamente.
Entonces, se marcará los tres de M,
y cuando los tres de M están aumentados,
te reaccionarás a esto.
También tienes transacciones,
puedes decir, estas ocho mutaciones,
yo quiero que te reaccionas solo.
No sé si eso responde a tu pregunta.
Puedes hablar de una línea, quizás lateralmente.
¿The Billy Guy?
Yo tengo un amigo que dice que,
para la generalización,
para la opción entre los dos libros,
dice que, para un pequeño proyecto,
sin pensar,
se usa Mopex,
y para grandes proyectos, se usa Redux.
¿En qué nivel te acuerdas con esta generalización?
De mi perspective,
depende de definir grande y pequeño,
porque podemos decir,
pequeño proyecto con un pequeño equipo,
o pequeño proyecto con un pequeño equipo,
no sé, porque,
lo menos,
el autor de Mopex,
y otros chicos inteligentes,
y Twitter,
es mi manera de aprender,
dice que,
si tienes mucho data,
y un gran tipo de spreadsheet,
si tienes esta cantidad de datos de computador,
obviamente Mopex es la manera de ir.
Si tienes más web clásico,
como en general,
como en el proyecto de ISAS,
Redux será más fácil,
no de ir a la comida.
De mi perspective,
puedo ver lo mismo,
porque,
si tienes un tipo de pequeño equipo,
Redux es bueno,
porque es un tipo de framework.
Todo el mundo está haciendo lo mismo,
obviamente todo el mundo complica,
que tengo que escribir este boarder,
crear constancia y todo,
pero, al menos,
están haciendo lo mismo.
Y puedes abrir cualquier componente y reducir,
y ver la misma estructura.
Con Mopex,
y el código que veo con Mopex,
a veces es totalmente random,
y las personas hacen lo que quieran.
Y para un proyecto más grande,
lo podría encontrar personalmente,
es más problemático.
Sí, no creo que sea una de las grandes de el proyecto,
como dije,
creo que las dos son difíciles de master,
así que creo que en términos de equipo,
ni si tienes ellos en el board,
ni si no tienes ellos en el board.
He visto gente mezclando con frameworks bot,
es muy fácil mezclar cosas con Mopex y Redux,
creo que las dos tienen una complejidad
que no puedes esperar
para poner algunos desarrolladores
y figurear de nuevo y resolverlo.
Esa es la forma en que el equipo
va a aprender o no.
En términos de
tus prioridades,
es como se siente,
haciendo ese proyecto.
Creo que las dos se sienten muy diferentes.
Así que depende de si quieres,
tal vez,
pensar en un motivo mutil y funcional,
y pensar en un examen de unidad,
o cosas como estas.
O creo, y esa es mi opinión,
o si quieres speed up cosas,
y eso es,
me siento de esta manera,
creo que con Mopex
puedes ejecutar más rápido.
Pero no creo que haya nada que hacer
con un proyecto de lado o un proyecto más pequeño.
Me siento de esta manera.
Creo que el primero es más rápido,
el otro es más robusto,
y el otro es más...
no sé cómo decirlo,
más testable,
o más consistente,
entreprensivo.
Más java.
Más java.
Como se dice aquí.
¿Estás bien o malo,
tener muchas transformaciones en los estados,
la cosa que mencionaste,
que tienes un estado que calcula
algo de diferentes partes del estado,
es bastante normal.
Sí, una cosa que no ha sucedido,
digamos que hay tres mutaciones en una ropa,
entonces, obviamente, tu compañía va a reivindicar
tres veces,
así que puedes romperlas en una transacción,
pero eso ocurre con predactos también,
como si mutas 10 veces,
entonces vas a recogir las estaciones,
y entonces, desgraciadamente.
Entonces, en el final,
es a ti que elegís la actualidad,
y eso es el problema con la reacción,
a veces reaccionan mucho,
que a veces veas los steps intermedios,
y te dices,
No, no, drop it, drop it.
All the tools are there.
Ok and I think that's it now.
Thank you for sharing,
y thank you for sharing your work.
Subtítulos por la comunidad de Amara.org