A ver, tenemos aquí a nuestro compañero Jack Franklin, no sé si conocéis a Jack Franklin, es un chico que hace bastantes charlas de programación y ahora está trabajando en las Chrome DevTools, ¿vale? En el equipo de Chrome DevTools.
La verdad es que es un chico que dice bastantes cosas interesantes, me gusta mucho de temas de tecnología, tema político, ya ahí no me meto.
Pero de temas de tecnología sí que muchas veces tiene temas interesantes. Hombre, gracias Enrique, joder, que me gusta esto de recibir 100 bits, joder, tengo que venir más.
Bueno, el tema es que ha escrito un artículo bastante chulo porque Jack hasta hace poco trabajaba con React, ¿vale?
Y es que cuando se cambió de equipo, ¿no? Que estaba en un sitio que trabajaba con React, que era un e-commerce, cuando se fue a Google a trabajar con las Chrome DevTools,
su foco era, pues claro, no iba a ser meter React, sino era introducir web components como nuevo fundamento para construir estas nuevas features en la nueva UI, ¿no?
Entonces, me parece interesante, ¿no? Porque al principio decía, cuando dejó React, pues decía que esperaba que la transición fuera difícil y que iba a echar de menos React.
Entonces, este artículo, y aquí lo dice bastante bien, no es para decir que los web frameworks sean buenos o malos, ni para decir que esto, esto es otra cosa que,
vamos a decir otro, vamos a meter otra puntillita. He visto en Twitter mucha gente que utilizando este artículo se pone web component, web component, web component todo,
es que React, es que... Yo soy un amante de la plataforma web y me gustan un montón los web components, me gusta un montón React, me gusta un montón todo.
Porque al final la plataforma lo es todo, todo es la plataforma. Lo que entiendo que mucha gente lo que dice es utilizar la plataforma directamente en tus desarrollos.
Pero muchas veces las bibliotecas y los frameworks lo que hacen en realidad es ayudarte a construir aplicaciones o a escribir menos código
o a tener cosas mentales que te van a facilitar la vida. Mucha gente incluso dice web components y luego utilizan lead, que sí, que está bien,
que está basado en web components, pero no deja de ser una biblioteca, por muy pequeña que sea. Y es que esa es la idea muchas veces, ¿no?
Que no tiene mucho sentido a veces tocar la plataforma constantemente cuando hay bibliotecas que te facilitan la vida.
Pues eso, que esto no va de esto. El artículo dice que no es una llamada para que todo el mundo deje de utilizar React,
ni es para declarar que React está muerto, ni que es una mala decisión para cada proyecto, ni nada de esto, ¿vale?
No es, no es, no es nada de esto. Es simplemente como su opinión de cómo lo ha vivido, ¿no?
Sobre esto de dejar React. Cómo ha sentido esto de dejar React.
Entonces, ¿cómo ha sido esto, no? Porque muchas veces, ves, usar la plataforma a veces está como demasiado usado.
Es una frase muy, que se abusa mucho justamente para esto, con lo que comentaba, ¿no?
Que es, no, usa la plataforma así como en general. Y al final hay que entender que siempre estamos usando la plataforma.
Lo que sí que es interesante es conocerla para intentar sacarle el máximo partido.
Y aquí habla de tres cositas que, obviamente, hay algunas que conoceréis, que está bastante bien.
Ya estáis con el artículo, ya estáis con el artículo. Sí, pum, ahí te lo dejo.
Entonces, por ejemplo, una cosa que estaba interesante, y hay que tener en cuenta el foco, ¿vale?
Que esta persona está trabajando a Chrome DevTools, donde puede hacer este tipo de cosas y, a lo mejor, tiene más sentido.
Por ejemplo, utilizar los atributos de validación de HTML.
Que esto, no sé si los conocéis, pero son súper típicos.
Como, por ejemplo, el require, min, length, el min, el max, el pattern.
Esto es lo que te permite, mira, esto, lo que te permite de forma súper fácil,
es que puedas tener algún tipo... A ver, ¿what do you prefer a banana cherry?
Vale, te require... Bueno, que puedes tener que sea... Esto es para estilarlo, pero esto es bastante horrible, ¿vale?
Tú lo que puedes hacer es decirle que un campo sea required.
Le dices simplemente que sea aquí, con un atributo required, y ya está.
Y lo bueno es que, además, lo puedes estilar con CSS.
Esto sin nada de JavaScript, ni absolutamente nada.
Pero, ojo con esto, porque esto lo he visto un montón de bifis,
y, de hecho, es que la gente... Este tipo de validaciones están súper bien.
Está súper, súper, súper bien.
Es verdad que en tema de estilos, a veces tienes que tener cuidado,
porque a lo mejor en un navegador se ve de una forma, en otro navegador se ve de otra.
Pero lo más importante es que este tipo de validaciones no sirven, en realidad, para nada,
más que para ayudar en la experiencia del usuario.
¿Qué quiere decir esto?
Que cualquier validación de formulario se tiene que hacer en el backend,
o en la API, o en el microservicio, o donde sea que tienes esa lógica.
Antes de meterse en la base de datos, es donde se hace la buena validación.
Estas validaciones, en realidad, se pueden desactivar, se pueden quitar, se pueden hacer mil cosas.
Las validaciones a nivel de frontend no sirven para nada más que la experiencia del usuario.
¿Vale? Eso aquí. Eso aquí, vamos.
En Pyscript lo tienes, sí, sí, lo tienes, pero con 50 megas, ¿no?
Igual la plataforma no siempre es suficiente.
Muy bien. Estoy de acuerdo, J.R. García.
Sobre todo en temas de accesibilidad y componentes.
Pues estoy totalmente de acuerdo.
No siempre es suficiente.
Y justamente, tenemos que entender, y esto es una realidad, a mí me encanta la plataforma,
pero si la plataforma hoy en día es lo que es, y mañana será lo que sea,
es gracias a que hay frameworks, código abierto, lo que sea, que empuja la plataforma hacia adelante.
Si jQuery no hubiera reinado durante muchos años, seguramente la manipulación del DOM
no sería como la conocemos hoy en día.
Se hubiera quedado ahí, pues, de otra forma.
Y lo mismo pasa con React, con temas web components, pues, algunos cambios,
la necesidad del service al rendering, no sé, un montón de cosas,
como los problemas de Shadow DOM.
O sea, la plataforma evoluciona, y evoluciona gracias a que cuando no llega a la plataforma
se hacen implementaciones para que intente llegar a esos sitios.
Y lo mismo con el fetch, hay mil millones de ejemplos.
Son validaciones de frontend, no de negocio.
Efectivamente, también me gusta esa explicación.
Herramienta de desarrollo, eliminar, required.
Sí, o sea, claro, es que hay que tenerlo en cuenta, ¿no?
Porque al final hay gente que se cree que haciendo este tipo de validaciones, pues, ya lo tiene.
Pero bueno, para validaciones sencillas sí que puede ser suficiente.
Y yo, la verdad, es que muchas veces veo gente que se pone a meter librerías,
y para ciertos patterns o cosas complicadas sí que pueden tener sentido.
Mira, aquí tenemos, por ejemplo, los patterns, ¿no?
Que puedes poner un pattern para decirle que, mira, tiene que ser banana,
pero que tiene que empezar con B mayúscula o B minúscula, y C, C cherry.
Claro, entonces, de esta forma podemos ver aquí que si yo pongo cualquier cosa, me lo dejan rojo.
Y si pongo banana, pues, ya lo tendríamos.
Y así tenemos este tipo de validación.
De hecho, si no lo pones, pues, ¿ves?
Te pone ahí, eh, que esto está mal.
Y si pones otra cosa, pues, también te dice que está mal.
Y este tipo de validaciones incluso se puede utilizar un poco de JavaScript para recuperar qué errores tienes.
Así que es bastante potente.
El problema antes es que no todos los navegadores tenían este tipo de validación.
No funcionaba esta validación.
Pero, a ver si...
Required, ¿ves?
Required.
Pero ahora, por ejemplo, Required ya lo soportan todos.
¿Cuál es el problemilla que normalmente tiene?
Pues, el problemilla que tienen es que el cómo se ve visualmente el Required, a veces sale un tooltip.
En este caso entiendo que es que lo tienen desactivado.
Pero, a veces, cuando sale el tooltip, pues, como se ve en Safari, en Firefox y en Chrome, no es igual.
Pero, que esto es una cosa que, sobre todo, muchas veces le preocupa a la gente de UX, pero a veces tiene sentido que no sea igual.
La experiencia del usuario en Firefox, en Chrome y en Safari, no siempre es la misma.
Y el usuario, igualmente, está más acostumbrado a la experiencia nativa de cómo es el campo requerido, que no como a lo mejor tú piensas que lo vas a hacer.
Y va a ser mucho más accesible, normalmente, el nativo del navegador que el que tú puedas trabajar.
Así que, me parece un muy buen consejo en este caso.
Y tenéis un montón, ¿eh?
Por ejemplo, el Min Length, el Max Length.
Tenéis tipos de datos que tenéis...
¿Ves? Aquí en esta, ¿cuánto es el máximo?
Tenéis el Max, el Min también, ¿ves?
Para los valores numéricos, Min y el Max.
Y un montón. Es que hay un montón.
Por ejemplo, podéis utilizar el Pattern para validar también en JavaScript.
Y aquí tendríamos lo de validar formularios utilizando JavaScript.
Este es menos conocido, pero es bastante interesante.
Y es el hecho que puedes utilizar la Constraint Validation API.
No está... No sé cómo está de soporte.
O sea, creo que no está tan bien como el otro.
Constraint Validation.
Creo que no está tan bien como el otro.
Bueno, lo podemos ver.
No está mal. O sea, que ya tiene un 96%.
Y lo que puedes hacer es tener validaciones personalizadas.
Que mucha gente se cree que necesita sí o sí una librería o algo para hacerlo.
Y con este tipo de cosas lo puedes hacer con JavaScript.
Y está bastante bien, como podéis ver.
Tiene bastante buen soporte, excepto Internet Explorer.
Bueno, depende, ¿no?
Hay algunos, pues, que están así, así.
Pero bueno, esos son un 2%.
Los que tienen así, así, un 2%.
Igual un día hacemos un vídeo de esto, porque me parece bastante chulo.
Y está bastante bien.
Y esto lo podéis hacer con... Bueno, con si es demasiado largo, si es bastante...
No sé.
Tenéis un montón de... Lo típico de si es largo, si no tiene el pattern y tal.
Y además lo podéis reportar.
De forma que podéis utilizar cualquier...
Customizar lo que queráis.
Tanto el mensaje...
Tanto el mensaje...
Que esto muchas veces hay gente que dice...
Ah, pero es que el mensaje no se puede personalizar y tal.
Es que sí que lo podéis personalizar.
¿Veis?
Email.
Set custom validity.
I'm expecting an email address.
¿Vale?
Y de esta forma lo que cambiáis es el mensaje del tooltip.
¿Vale?
Porque hay muchas veces que la gente decía...
Ostras, pero no se puede.
Mira, lo vamos a ver aquí en el coding link.
En un momento.
Porque esto es por lo que antiguamente no se utilizaba.
Y esto ahora ya lo han arreglado.
Y está bastante bien.
Entonces, a ver.
¿Ves?
¿Ves que este mensaje?
I'm expecting an email address.
Este mensaje es este.
Esto ahora lo podéis personalizar.
Que esto es una queja que hubo durante mucho tiempo.
Normalmente, por defecto, es este.
Incluye un signo arroba en la dirección de correo electrónico.
Que son una mierda.
Los mensajes estos son bastante...
Son poco basura.
Entonces, si lo queréis...
Una de las razones por las que muchas veces no se utilizaba este tipo de validación
era porque no se podía personalizar el mensaje del input.
Y en realidad, como podéis ver, ahora sí que se puede personalizar.
Lo podéis hacer para tener el tono que queráis tener en vuestra empresa, en vuestro producto.
Por si hay traducciones que no os gusta la del navegador y la queréis hacer de otra forma.
De hecho, esto acepta...
A ver.
¿Acepta emojis?
Con emojis y todo.
Bueno, que lo sepáis.
Que hay muy poca gente que sabe que se puede utilizar esta API para personalizar ese mensaje.
Y ya tendríais el tooltip gratis.
Tendríais un montón de cosas.
Así que, bueno, para que lo tengáis en cuenta.
De hecho, él habla de esto, justamente.
De que había utilizado el Validation Attributes.
El Form Data.
Esto lo tengo en un vídeo.
Para poder recuperar todos los datos de un formulario.
Y el Constraint Validation API.
Que justamente es la que os estoy enseñando.
Esto es solo la punta del iceberg.
Porque tenéis un montón, pero un montón de métodos y validaciones que podéis hacer.
Y poder mirar.
Así que le podéis echar un vistazo en el MDN.
Que lo vais a tener bastante bien.
Más cositas.
Más cositas que he comentado por aquí.
Bueno.
El tema de las dependencias.
Y ahora os cuento esto de las dependencias.
Voy a leer un momento.
Y os cuento lo del tema de las dependencias.
¿Cómo se puede divulgar mejor cuando aparecen errores como got?
Yo lo hago paso a paso.
Entonces, ¿mi consulta es algo más directo de encontrar error?
Bueno.
En las Chrome DevTools puedes poner puntos de captura.
Bastante fácil.
¿Crees que vale la pena suscribirse a Tailwind UI?
No creo.
Depende, ¿no?
O sea, yo supongo que puede ser que valga la pena si vas a hacer muchos proyectos.
Si no, no creo que valga la pena.
¿Cuándo utilizar un PASS y cuándo un IaaS?
O sea, IaaS es infraestructura como servicio y un PASS es un platform as a service.
¿Cuándo utilizar?
A ver, depende.
La infraestructura como servicio normalmente es porque tienes un equipo...
O sea, no tienes DevOps.
Entonces, tienes más de la infraestructura.
La tendrías como más subcontratada, digamos, al servicio.
Pero sí que tienes tu negocio muy importante respecto a microservicios, a la parte del backend y todo esto, ¿no?
Porque de esta forma te puedes encargar de crear tú la plataforma.
Y la plataforma as a service...
La verdad es que no se me ocurre plataforma as a service.
Entonces, ¿algún ejemplo de... yo qué sé?
Me imagino que Google App Engine y cosas así, ¿no?
No sé.
La verdad es que tampoco he utilizado ningún PASS, sinceramente.
Claro, yo he utilizado más SaaS y he utilizado más BaaS.
Pero nunca he utilizado un PASS.
Supongo que es para algún tipo de empresa muy particular.
Así que no sabría decirte muy bien la diferencia entre un IaaS o un...
O sea, la diferencia me la sé.
Pero no sabría decirte cuál es la ventaja realmente.
Pregunta random.
¿Copilot va o no va en una entrevista?
Hostia, qué buena pregunta.
¿Qué creéis?
¿Creéis que estaría bien utilizar una entrevista copilot o no?
Oye, Lavaldi.
Muchas gracias por suscribirte durante un mes en el nivel 1.
Muchas gracias por animarte.
Gracias, Episobrio.
Muchas gracias.
¿Creéis que vale la pena?
O sea, ¿creéis que estaría bien...?
¿Creéis que estaría bien?
O sea, ¿creéis que estaría bien utilizar copilot en la entrevista?
Yo creo que sí, la verdad.
Yo creo que sí.
Sí, Vercel sería un PASS, por ejemplo.
Sería un Platform as a Service.
Sí.
Pero en el sentido de decir entre un IaaS, que es una infraestructura as a service, o un PASS...
No sé, el IaaS a lo mejor es como más a bajo nivel, un poquito más bajo nivel.
O sea, debe ser algo para todavía tener más control que lo que tienes en Vercel.
¿Comprobar un DNI lo harías en el back o en el front?
A ver, Andrea, chupisí.
Todo hay que hacerlo en el backend.
O sea, nunca, jamás, nunca, nunca hay una duda de lo harías en el backend o en el frontend.
El tema es, ¿lo hago en el frontend o no?
Porque en el backend lo tengo que hacer seguro.
Eso es lo que tienes que pensar.
En el backend es innegociable.
Siempre hay que hacerlo.
Otra cosa es que en el frontend, por mejorar la experiencia del usuario, pues lo hagas.
Pero hay veces que no hace falta, por ejemplo, muchas veces en los formularios.
Por ejemplo, pongamos este formulario, ¿vale?
Este formulario.
Tú aquí, si lo que haces es una action que tú tienes aquí, pues el POST.
Ay, esto es el action, no es esto.
Es el method.
Es el POST, ¿vale?
Esto al final, lo que va a ocurrir cuando tú hagas esto, es que esto va a refrescar la página
cuando hagas el enviar el formulario.
Entonces, harías el chequeo.
Pongamos que esto es el DNI, ¿vale?
Vamos a ponerlo DNI.
Vamos a poner aquí DNI.
¿Vale? DNI.
Entonces, tú pones ahí 4, 5, 5, no sé qué, no sé cuánto.
Vamos a ponerle que es un input para que no se vea qué.
Entonces, tú le pones aquí el danillo 4, 6, bueno, 4, 5, 3, 1, 2, bla, bla, bla.
Entonces, tú cuando le das un input a esto, lo que puedes hacer es que haga el POST y realmente, al enviarle los datos, lo chequee el backend directamente.
Y refresque la página y ya está.
O sea, que en el backend puedes hacer ese chequeo y no hacer nada en el front.
Eso, de hecho, es una cosa que en algunas páginas lo hacen y no funciona mal.
Además, si la validación se hace al cliente, te evitas que se haga la request y falle en el servidor.
Claro.
Pero eso, al final, es pura experiencia de usuario, en realidad.
Porque que falle en el servidor, es verdad que te lo puedes evitar, pero no es seguridad.
O sea, no es algo de seguridad, ¿vale?
Meter rando a lodas para una o dos cositas del proyecto.
Eso tiene muchos bichos.
Pensamiento, el way to wait.
Por eso cada framework aporta algo.
Cuando utiliza...
Ahí pone eso, ¿eh?
Para que el cliente no haga submits por gusto y mejora su experiencia, no por seguridad.
Exacto.
Es para que el cliente no haga submits por gusto, para mejorar la experiencia del usuario.
Pero nunca, jamás, es por seguridad.
Súper importante, ¿eh?
Santiago dice...
Hola, Mitu, te conocí hace dos semanas y me declaro fan.
Me encanta tu contenido.
Hombre, muchas gracias, Santiago.
Me alegro.
Espero que estés por aquí todavía, que hace un rato que lo habías escrito.
Pero espero que estés por aquí.
¿Los estilos se pueden personalizar?
Los estilos no se pueden personalizar, Guzmán.
No se pueden personalizar.
Eso es lo que comentaba, ¿no?
Que hay mucha gente que por personalizar los estilos del tooltip este...
A ver que...
Vamos a poner esto para atrás.
Pam, pam, pam.
Este...
Uy.
Me lo he cargado.
Me lo he cargado.
Me lo he cargado.
Hostia, que he puesto el...
No es un email.
Vale.
Esto...
Esto no se puede personalizar.
Por ahora.
Al menos por ahora.
Ya veremos.
Igual el día de mañana sí que se puede personalizar.
Pero es lo que te digo.
Mucha gente, muchos UX y tal, dice...
No, es que yo lo quiero personalizar porque no sé qué.
Pero ¿sabes qué pasa?
Que los usuarios van a estar...
Seguramente puedes intentar hacer un tooltip o una forma mejor.
Lo que sí que se puede estilar...
El tooltip no se puede estilar, ¿vale?
El tooltip no se puede estilar.
Pero lo que sí que se puede estilar, por ejemplo, es el input.
En el input sí que puedes estilar cosas.
De hecho, lo habíamos visto por aquí en el MDN.
Podríamos tener required.
Required.
Esto utilizando el pseudo...
Por aquí lo habíamos visto.
Aquí arriba se está destilando.
¿Ves?
Para ver si es válido o inválido.
Así que con un pseudo selector puedes hacer esto.
Lo pondríamos aquí.
Y aquí lo tendrías.
Cuando no es válido estaría en rojo.
Y cuando ponemos algo válido...
Bueno, se pone en negro, pero podríamos poner verde, por decir algo.
Y aquí lo tendrías.
Podrías hacer más cosas.
Podrías incluso...
Incluso con esto se podría hacer un tooltip, si quisieras.
No tiene mucho sentido, pero puedes hacer bastantes cosas.
Mostrar, por ejemplo, un mensaje debajo o lo que sea.
O sea, que hay un montón de cosas.
Y con esto de JavaScript incluso podrías añadir tu clases.
O sea, lo bueno de esto es que tienes las validaciones en la parte nativa del navegador sin dependencias.
Y al final te permitiría, por ejemplo, pues con esto de validity type mismatch, porque al final puedes ver todos los diferentes validities, todos los checks que ha hecho.
Si es el pattern, si es la validación del tipo, si es que era required y no está.
Cosas así.
Lo podrías mirar y poner mensajes diferentes con JavaScript.
O sea, bueno, con JavaScript mostrarlos.
¿Vale?
¿Por qué la página es sin estilar?
Bueno, porque no hemos puesto estilos, pero al final tampoco es muy importante.
Buenas, ¿puedes pasarnos el enlace?
El enlace del artículo.
Lo habíamos antes, ¿eh?
¿Midu, está bien Apollo Client como State Management?
Hombre, como State Management no.
O sea, Apollo Client, el State Management es en realidad una consecuencia.
¿Sabes?
Es como, en realidad lo que es, es un cliente de GraphQL.
El State Management al final es un side effect que tienes.
Entonces, como State Management así en general, no.
Pero, ¿puedes aprovecharte de State Management si tienes el cliente de GraphQL y está bien?
Sí, está bastante bien.
Pero hay veces que puede ser un poco complicado a la hora de actualizar esa caché.
Cuando haces una mutación la tienes que cachar y todo.
Así que, Miguel, ¿es buena práctica usar un Never Listener de alguna tecla para todo el DOM
y desactivarlo cuando escribes en algún input?
A ver, sí, porque hay veces que vas a querer hacerlo.
Por ejemplo, con los accesos directos se hace así, escuchando la tecla totalmente.
Así que, no hay ningún problema.
Lo que puedes hacer al escuchar la tecla es que evites, aunque escuches el evento,
tú propagues el evento y lo evites de escuchar cuando estás dentro de lo que tú quieras.
¿Qué más recomiendas?
Pues, por ejemplo, tienes Supabase, Firebase, que están bastante chulas.
Sammy dice, hola, Midu, genero todo tu contenido.
No sé si vas a hablar o has hablado en algún momento sobre cómo poder prevenir el burnout.
Ostras, pues de eso íbamos a hablar también, amigos.
Siguiente tema.
Ya hemos visto que, bueno, terminando el tema de dejar React, que está bastante chulo,
os recomiendo mucho el tema este del artículo, porque yo soy un amante de React,
pero dice cosas que están bastante interesantes y al final es el tema este,
que dice, elige dependencias que sean fáciles de reemplazar.
Mira, muchas veces me preguntáis, ¿cómo crecer en senior y tal?
Seniority, bla, bla, bla.
Y una de esas cosas es esto, ¿no?
Es el hecho de entender también la responsabilidad de la construcción del software.
¿Y a qué me refiero con esto?
Me refiero que hay veces que perdemos un poco el foco en por qué hacemos lo que hacemos.
Y entonces nos ponemos a meter un montón de dependencias, bibliotecas o lo que sea, ¿no?
Y nos olvidamos para qué hacemos eso.
En realidad lo hacemos porque queremos solucionar un problema
y la idea es que ese problema lo podamos mantener solucionado a lo largo del tiempo.
Entonces, a mí me encanta React y esto no creo que sea un tema de crítica a React, ni mucho menos.
Pero, por ejemplo, el tema de utiliza la plataforma.
Yo creo que lo que hay que entender es que hay veces que el añadir una dependencia no está justificado
si la plataforma te proporciona algo que no va a impactar negativamente al usuario.
Pero, obviamente, esto es un coste de oportunidad.
Todo en la vida es un coste de oportunidad.
El coste de oportunidad básicamente es qué es lo que me ofrece algo a cambio de algo que tengo que dejar de...
Tengo que dar o que tengo que dejar de hacer o que tengo que entregar a cambio de eso, ¿no?
Entonces, el coste de oportunidad, por ejemplo, de React es, vale, voy a poder construir mucho mejor una UI y todo esto,
pero el coste de oportunidad obviamente es que es pesado, tengo que añadir una dependencia que voy a tener que mantener.
Por ejemplo, yo en Adivinta siempre lo que he intentado es que tengamos las mínimas dependencias posibles a nivel de arquitectura.
Por eso yo siempre estuve en contra de meter Redux.
Porque al meter Redux, al final, el problema que tienes es que es una dependencia que se mete en toda tu aplicación.
Entonces, teníamos por una parte la lógica de la aplicación, era con puro JavaScript,
eso no tiene ningún tipo de dependencia, en la que el día de mañana si utilizamos React, Vivo o lo que sea,
podemos seguir utilizando eso.
O sea, todo lo que sería llamar a APIs, cómo transformamos los datos, validación de datos,
eso lo tenemos totalmente separado, no dentro de nuestros componentes, y con cero dependencias.
Eso ya es evergreen, eso ya dura por siempre.
Así que eso es súper importante.
Y luego por eso yo intentaba no meter Redux, a no ser que lo necesitáramos.
Porque necesitáramos realmente y no lo necesitábamos realmente.
Porque a lo mejor había un caso, dos casos que hubiéramos solucionado con Redux,
pero el coste de oportunidad era demasiado alto porque nos hubiera atado a una dependencia en diferentes verticales
que siempre vamos a tener que estar pendientes tanto del versionado, tanto de actualizar esa dependencia,
hacer las migraciones que hagan falta para lo que realmente nos aportaba, que era muy poco.
Entonces, eso es lo que es interesante.
No solo pensar en, usa la plataforma, sino si no uso la plataforma o si instalo una dependencia,
¿qué me está dando a cambio para que se gane el puesto en mi proyecto?
Y eso es súper importante porque muchas veces o pocas veces pensamos en este tipo de cosas.
Hay gente que a lo mejor utiliza una dependencia y a lo mejor utiliza un 5% de esa dependencia.
Y sería cuestión de pensar, bueno, ¿hay una alternativa o puedo hacer otra cosa para evitar esto?
Porque al final, esa complejidad que vamos añadiendo, pues, ¿qué te parece Redux Toolkit?
Pues un poco lo mismo.
Me parece muy bien que simplifica bastante las cosas, pero también simplifica más las cosas a cambio de ocupar todavía más.
O sea, eso es bastante interesante, Redux Toolkit, ¿no?
Redux Toolkit.
Redux Toolkit lo que tiene es que simplifica bastante, ¿no?
Y hace que sea más simple Redux, pero no mucho más, o sea, sí que es más simple, pero todavía tienes algunas cositas, ¿no?
Pero claro, el problema de Redux Toolkit es justamente de lo que estoy hablando.
Redux Toolkit no viene gratis.
O sea, Redux Toolkit tú lo tienes que instalar aparte de Redux.
Entonces, lo que te arregla, o sea, lo que te intenta solucionar es también a cambio del coste de oportunidad que estoy comentando, ¿no?
Y esto es lo que hay que pensar.
Hay que añadir 12k más al proyecto, un paquete más que está versionado, que por lo tanto hay que mantener y hay que tener en cuenta.
Te simplifica mucho esto, pero es a cambio de algo.
No es que han mejorado Redux, que, ¿sabes?
Hay mucha gente que dice, no, es que ahora Redux es mejor.
No, no, a ver, no es que Redux sea mejor, es que han hecho un plugin a Redux que tienes que instalar aparte para simplificar el desarrollo con Redux.
Entonces, la pregunta sería, oye, lo que te está dando Redux con Redux Toolkit, ¿sería más conveniente, por ejemplo, mirar si lo que realmente necesitamos para esos pequeños trozos del estado
es utilizar Zustan, porque Zustan es una sola dependencia, ¿vale?
Que solo tiene, o sea, solo tiene una dependencia que es using external store, ¿vale?
Ocupa un K, es una sola dependencia.
En cambio, tendríamos Redux Toolkit, que es una dependencia que a su vez tiene la dependencia de Imer, de Redux, de Reselect, de Babel Runtime y de Redux Zank.
Aparte de esto, tienes que instalar aparte también React Redux, que son otros 4Ks y que también tiene estas dependencias de aquí, ¿no?
Mira, esta también es la misma que te Zustan.
Entonces, ¿está mal utilizar Redux? No está mal. No digo que esté mal.
Lo que hay que tener en cuenta es qué es lo que me está dando a cambio de todo lo que ocupa y toda la complejidad que le añade a mi proyecto.
Si lo compensa y estás seguro, segura que lo compensa, pues no pasa nada. Tiene todo sentido del mundo.
¿Cuándo lo puede compensar? Cuando tienes muchísimos estados globales.
Es una aplicación muy compleja, con un montón de interacciones estados globales que se manejan por un montón de sitios
y hay que ser súper estricto en la forma de cómo se maneja ese estado y tal.
Bueno, pues a lo mejor tiene sentido utilizar Redux.
O a lo mejor ya empieza a tener más sentido utilizar algo como Apolo Client o utilizar Relay o cosas así.
Cuando aplicaciones son mucho más grandes ya Redux también se vuelve demasiado complejo y tal y suele salir más a cuenta de eso.
Es tenerlo en cuenta. Punto. O sea, eso es lo importante.
O sea, no está ni bien ni mal. Es cuestión solo de ver dónde encaja.
¿Vale? O sea, es mi opinión, ¿eh?
Que si hay gente que le encanta a Redux y lo quiere meter en todo sitio, pues ya está.
Midu, si estás entrevistando a alguien y lo hubieras probado con Copilot, ¿qué pensaría?
Bueno, he visto la encuesta que había ganado Copilot, pero ya os he comentado.
A mí me parece bien. O sea, me parece bien. No tendría ningún problema.
Cosas que sí que veo mal. Por ejemplo, que copie código.
Que vaya a un fichero y copie código.
Eso sí que me parece un poco raro.
Otra cosa sería revisarlo. Eso me parece bien.
Pero es que Copilot me parece una herramienta muy normal.
O sea, no sé. Me parece normal.
No pensaría nada raro.
Pero, por ejemplo, una cosa que he visto a veces es la gente que dice
No, es que yo en realidad no sé cómo inicializar un proyecto con React.
Y en lugar de ir a buscar la documentación, se va a un proyecto suyo, se copia un archivo entero,
no sabe y le preguntas y le dices
Vale, pero ¿qué está haciendo este archivo?
Ah, no lo sé. Yo siempre he hecho esto.
No sé qué está haciendo esto.
Yo no sé, no sé.
No sé qué hace esto, pero yo solo sé que funciona.
No, no, tío. No, no sea.
O sea, eso no. Eso no.
No puede ser así.
O sea, está bien que tenga aquí Jacob Pailo, pero tienes que entender lo que está haciendo.
Si no...
Es como si pudieras conducir un coche.
O sea, estás en un Tesla y te dice
Bueno, tú lo único que tienes que hacer es pulsar este pedal para acelerar.
Y entonces vas solo y tal.
Pero alguien te pregunta
Oye, ¿por qué estás pulsando ese pedal?
Y dices
Ah, no sé, no sé. Yo solo hago esto y sé que funciona.
Bueno, pero...
¿Por qué lo estás pulsando?
Joder.
Bueno.
¿Vale la pena usar un Safari?
Me gustan sus tools.
Bueno, no me gustan mucho las tools de Safari, la verdad.
Creo que están a año en luz, por desgracia, de las Chrome, de tools y las de Firefox.
¿Un teclado mecánico barato que me recomiendes, Midu?
Claro que sí.
A ver, no lo tengo.
No lo tengo.