applying solid principles en react que es solid antes de que empecemos vamos a seguir un poco la
guía del artículo pero yo tengo aquí unos ejemplos que he ido encontrando y que lo que
voy a hacer es refactorizar los vale hay aquí ejemplos en cada uno de los ejemplos tenemos
esto es la inversión de dependencias list of open close principal single responsable y de cada uno
tengo un código de react que lo que vamos a hacer es refactorizar lo que es solid solid como hemos
dicho es un acrónimo vale es un acrónimo donde cada letra representa un principio a la hora de
diseñar con programación orientada a objetos hay que tener en cuenta que aunque estuviese pensado
en su día estos principios para la programación orientada a objetos lo cierto es que se ha podido
llevar a un montón de otro tipo de diseño de software sea programación funcional ya sea en
componente componentización con ria con view con lo que tú quieras se puede llevar al menos los
principios no de la forma más pura porque hay veces que hablan literalmente de clases pero sí
que es verdad que muchas veces lo puedes adaptar más o menos vale entonces los cinco principios
single responsable y principal open close principal list of substitution interface
segregation y dependencia inversión estos son los cinco principios vamos a ver cada uno de los
principios que significan y cómo los podemos llevar un poquito al terreno de ria así que empezamos
con el primero no que es el de single responsibilidad principal este la definición original es que cada
clase tiene que tener una sola responsabilidad como os digo esto estaba pensado para programación
orientada a objetos y por lo tanto hablaba mucho de clases oa veces incluso de módulos y lo que
quiere decir es que hay veces que tienes una clase que hace demasiadas cosas no por ejemplo puedes tener
la clase y user pero claro la clase de user que se ocupe de abrir cuentas de cambiar toda la información de
la dirección del usuario tienes demasiadas cosas al final lo que quieres hacer es simplificar al
máximo las clases y que simplemente hagan una sola cosa porque porque si no lo que va a pasar es que
cuando lo quieran modificar o lo quieras cambiar te va a costar mucho esto lo puedes ver también un
poco con con el tema de los componentes si haces un componente que haga más de una cosa que tenga más
de una responsabilidad y vamos a ver lo fácil que es que tenga más de una responsabilidad y te vas a
ver reflejado como yo me veo reflejado muchas veces vas a ver que es muy fácil que esto te ocurra
no el hecho de que un componente haga demasiado una cosa que te quiero dar de contexto es que hay
gente que considera que el single responsibility principal no habla tanto del código o de las
clases sino que habla más de el ownership yo no estoy muy de acuerdo vale yo no estoy muy de acuerdo
aunque hay gente que por ejemplo roberts y martin también habla de esto de los stakeholders no de
que una clase o esa parte del código tenía que tener como un solo un solo stakeholder un solo dueño
sabes era un poquito más así entiéndelo como quieras solo te doy esa definición de que hay gente que la
defiende un poquito de esa manera pero yo prefiero verla un poco por el código porque creo que tiene
sentido creo que en react tiene sentido y al final creo que en javascript en cualquier cosa tiene
sentido y el ejemplo de react es muy potente porque muchas veces justamente lo hacemos mal vale que es
una responsabilidad hombre y coca responsabilidad eso es un una palabra literal en general o sea
responsabilidad es como si una persona tuviera muchas responsabilidades no imagínate que en un trabajo
una persona no sólo tuviese que programar sino además tuviese que diseñar y además tuviese que
hacer la comida y además también tuviese que hacer todas las reuniones eso es una responsabilidad el
hecho de que tenga muchas tareas que te que te corresponde hacer demasiadas cosas una responsabilidad
es lo que te corresponde hacer lo que ya sea por tu estatus por tu puesto por por la vida es lo que
tendrías que hacer y en el tema de la programación es los dotes que le estás dando a una clase o una
función cuántas cosas tiene que hacer y un componente lo vamos a ver si serían como freelancers eso es
verdad eso está bastante buena mira también este este artículo está muy chulo que es el de solid
principles en pictures así que bueno lo podemos ver también gracias por compartirlo equiman una single
responsibility vale esto es una hiper simplificación una clase tiene que tener una sola responsabilidad
pero bueno pensar justamente no sólo en clases sino en componentes en funciones y lo que sea pues aquí
tenemos un robot que tiene demasiadas responsabilidades porque es el cocinero es el jardinero es el que
pinta es el conductor y en cambio para evitar esto lo que tenemos que hacer es separarlo en diferentes
para que cada uno cada parte cada clase cada función cada componente tenga o cada robot tenga una sola
responsabilidad vale ese sería principios single responsibility tenemos un robot que es el cocinero
es un robot que es el jardinero un robot que es el que pinta y uno que es el que estremean tweets bueno
entonces al final lo que tienes que hacer es que cada uno tenga una sola responsabilidad vamos a
ver un ejemplo en react vale esto es un proyecto que he hecho con beat tiene typescript pero no os
preocupéis porque no casi no se utiliza y lo poco se utiliza lo vais a entender súper fácil tengo una
carpeta para cada uno de estos principios y vamos a ver un código por ejemplo este no en este código
tenemos el de single responsibility principle y vamos a ver cómo lo podríamos hacer bien y os voy a
explicar por qué estaría mal porque incumple la el principio de single responsibility y cómo lo
podemos mejorar entonces voy a poner aquí el tema es el principio más complicado porque como sabes que
tienes una sola responsabilidad y aquí nivel claro como os he dicho antes las los principios no es un
un switch no es un interruptor sino que muchas veces es un tema de intensidad y hasta dónde quieres
llegar con la madriguera del conejo de cada principio al final hay que tener cuidado porque si te
pasas en los principios solid tenemos el single responsibility responsabilidad única y en react
tendríamos este componente vale y os voy a decir qué es lo que vemos mal yo lo que vería mal en este
componente lo que podemos ver bueno parece al principio que bien no tener use effect y un use
state parece que todo bien aquí tiene un tipo para tipar el contrato de lo que se guarda en el estado
pero aquí empiezan un poquito los problemas el tema es que este componente tiene diferentes
responsabilidades tiene la responsabilidad de gestionar el estado tiene la responsabilidad de
hacer el fetching de datos vale tienes que hacer el use effect tienes la responsabilidad de saber cómo
haces el fetching de datos y finalmente tiene la responsabilidad de renderizar el contenido por lo
tanto tiene demasiadas responsabilidades y esto obviamente lo podemos mejorar y lo vamos a hacer
cómo podríamos mejorar esto siempre a ver esto es una generalización pero es una generalización que al
menos podéis tener en cuenta normalmente en un componente de react si tienes un use effect significa
que puedes crear un custom hook para evitarte esto así que qué es lo primero que yo haría yo lo primero
que haría sería crear un custom hook que sea use fetch to do vale vamos a crear un custom hook y este
custom hook lo que vamos a hacer es extraer primero yo extraería todo lo que no necesitamos dentro del
componente así que yo esto lo metería por aquí voy a hacer una cosa antes de todo esto vamos a hacer una
cosita vale para asegurarme que está funcionando lo que estamos haciendo justamente en el a punto
tsx ves que yo estoy renderizando ya todos los componentes así que voy a comentar los que no
necesitamos ahora vamos a ver en la localhost 3000 vale aquí ya tenemos este sería el componente que
está renderizando es una lista como de todos o sea que parece que funciona funciona entonces vamos a
refactorizarlo pero que asegurándonos que funciona me hubiera gustado hacer test hubiera sido genial porque a
la hora de refactorizar los test son muy chulos pero en este caso no me ha dado tiempo imposible el día que me
dedique sólo al contenido aparte de hacer shorts de 15 segundos le daremos cañita vale entonces en este
ejemplo lo que puedes hacer extraer en un custom hook y esto ahora lo vamos a quitar de aquí vale ya no
lo necesitamos qué significa pues que ahora fíjate cómo se simplifica sólo con esto sólo con esto
ah bueno espérate que aquí tenemos que devolver podríamos devolver el data el data le vamos a todo vale
y ya está vamos a hacer esto vamos a devolver un objeto que sea to do is fetching para saber si está
haciendo fetching el to do va a ser el que reciba el data aunque le ponemos a que poner todo vale y set
to do o set todo vamos a ponerse todo y así quedará mejor se todo vale y este todo sería el que
devolveríamos aquí vale papapapa y ahora esto quedaría así de fácil use fetch todo y simplemente haríamos
esto ahora lo que bueno esto sea todo y aquí ya estaría con este ejemplo con esto que parece tan
tonto en realidad ya hemos simplificado bastante el componente lo que estamos haciendo es un custom hook
que sería esto de aquí donde hemos extraído parte de la responsabilidad que tenía nuestro componente
ahora nuestro componente su responsabilidad es sólo renderizar los datos es lo único que tiene que
pensar esto es un error bastante común en el que mucha gente mete todo el fetching de datos dentro de
esos componentes esto además de que hace que sea cero reutilizable no porque al final ese componente
está totalmente como atado pues lo que estamos haciendo es separar la responsabilidad de ese
componente a un casto que es lo que hacen esos los dos estados del casto hook bueno en este estamos
guardando guardando los datos del fetch vale y esto sería para saber si está si está cargando y así cuando
está cargando podríamos hacer un reto esto sería lo que lo que estaría haciendo ya está una vez que
hemos hecho esto yo lo llevaría más allá por ejemplo en lugar de dejarlo todo en un mismo
componente lo interesante lo que podemos hacer sería por ejemplo crear hay gente aquí que crea hooks no
hooks sería use fetch to do y es totalmente válido vale no os preocupéis no pasa nada esto está esto
está bien esto correcto vale aquí lo que deberíamos hacer es importar todo esto y entonces ya todavía lo
estaríamos separando todavía mejor porque porque ahora en nuestro componente fíjate que ni siquiera
estamos viendo y un hecho tú ni siquiera estamos viendo ningún import de axios ningún tipo de import
vale ningún tipo de import swr lo veremos después vale veremos un ejemplo con swr y porque tiene
interesante y porque es interesante de swr y cómo hacer inyección de dependencias y todo esto y react query
sería parecido a swr y ya está entonces ya veis cómo ha quedado el componente súper limpio súper
fácil de entender lo puede utilizar cualquiera aquí lo que hemos separado es toda la lógica y aquí tenemos
que todo sigue funcionando exactamente igual ahora bien podríamos llegar a un siguiente nivel vale
podríamos llegar a un siguiente nivel porque porque si miramos este custom hook como podemos ver se dedica
a dos cosas por un lado se dedica a la gestión del estado y por otro lado al fetching de datos así que
aquí tenemos un ejemplo de que esto tampoco tampoco sería single responsibility vale esto no sería exactamente
al 100% responsabilidad única porque podemos ver que tiene dos responsabilidades gestión del estado fetching
de datos vale importante ahora bien esto significa que deberíamos volver a refactorizarlo y volver a
saberlo pues depende a veces que sí a veces quiero por ejemplo todo esto que vemos aquí esto de axios no sé
qué no sé cuánto lo podríamos sacar muy fácil volvemos a sacarlo vale y hacemos aquí el fetch de hecho luego vamos a
indagar más en este ejemplo podemos hacer un fetch de los todos y que simplemente esto haga esto de aquí hacemos esto
retun vale y aquí hacemos el den del res punto date ya tenemos una función que directamente nos lo está
sacando de aquí y ahora esto lo que sí que podemos hacer aquí hacemos un fetch todos y aquí ponemos el punto den
tendríamos aquí ya los todos y hacemos ese todo y le aquí le guardamos todos y en el final y podríamos sacar el
todo bueno que no hace falta todos ni nada esto lo dejamos así y ya lo tendríamos podríamos que hacer catch del
error por ejemplo lo podríamos hacer aquí y aquí tendríamos la responsabilidad también de hacer un
catch del error y aquí hacer mil millones de cosas tendríamos diferentes historias vale aquí por
ejemplo podríamos podríamos tener la lógica decir vale yo soy el que se encarga de hacer el fetching de
datos por lo tanto yo soy el que decide cómo gestiona el error en lugar de hacer un console error por
ejemplo podría decir bueno quiero gestionar el error de que quiero devolver directamente un array vacío o
quiero devolver al menos algún tipo de cosa o puedes decir no voy a tener el error pero voy a devolver un nuevo
error dependiendo del error que tenga por ejemplo si el error el código es 404 el voy a devolver un
nuevo error porque es esto importante esto lo veremos más adelante vale pero lo que haríamos
aquí es que en lugar de mostrar de dejar que pasen los errores de la infraestructura de del fetch lo que
vamos a hacer aquí es comernos dentro de esto dentro de aquí vamos a comernos ese error y identificar
cómo lo queremos devolver vale aquí podríamos un not found en lugar de devolver el error con el status
code eso significa que sabríamos que estamos haciendo un fetching de datos pero y si esto viene de un local
storage y si esto viene de las cookies y si esto viene de graphql y mil millones de historias vale
este sería el ejemplo por ahora lo vamos a simplificar pero para que sepas que lo interesante es que ahí
podrías hacer la gestión de los errores también al hacer el fetching de datos así que ahora ya sí que
podríamos quitar todo esto de aquí y entonces se simplificaría todavía más de nuevo que podríamos
hacer pues aparte que tenemos los hooks aquí podríamos voy a subir esto no podríamos decir
services esto sea lo mínimo y aquí podríamos hacer todos punto tsx y aquí los todos pues ya tendríamos
vamos vamos a sacarnos todo esto y volvemos a hacer esto vale importamos el fecho todos claro
todos todos todos que ahora no es que no estoy exportando todos y también el tipo de todo type esto lo habría que
habría que sacarlo sacarlo a un archivo de types vale pero no puedo estar aquí todo el día sacando archivos
vale fetch todos from services todos bueno falta que lo pongamos y importamos el tipo del to do type y ya
está vale entonces ya podemos ver que este custom hook también ha dado una vuelta más hemos vuelto a hacer
el single responsibility principal hemos vuelto a hacer justamente que tenga una sola responsabilidad
por eso os digo que hay grados no hemos llegado y está bien que os quedéis a mitad vale porque de verdad
llega un momento en el que si intentáis ir al límite vuestro código puede sufrir ya ya habéis visto no que
conforme hemos ido indagando en el single responsibility no la responsabilidad única hemos tenido que crear
una estructura de ficheros y luego otra vez entonces está bien separarlo pero también tienes que tener en cuenta
el coste que tiene esto y hay veces que hay principios que si los llevas muy lejos pueden ser
contraproducentes sólo que lo tengas en cuenta vale no no no que lo vuelvas ahí como así hay que hacerlo
sí para siempre ya está antes de seguir vamos a ver el ejemplo que tenía el artículo yo es que he buscado
por ahí ejemplos pero el artículo este tiene otros ejemplos aquí por ejemplo habla bueno de algo parecido
veis el mismo ejemplo el artículo tiene un ejemplo también de que tiene un efecto que hace un load users
aquí además tiene un wikago que entiendo que esto hace como un tipo de lógica el filtrado de usuarios
aquí que a lo mejor se puede sacar en otro sitio entonces dice aunque este componente es relativamente
corto se pueden hacer algunas cosas bueno y aquí vemos que está haciendo bueno el custom hook lo ha
separado también a un use users ha sacado más cosas ves está sacando componentizando también la parte del
user item lo ha sacado aquí no o sea lo que está haciendo es componentizar es separar responsabilidades
mira aquí una función para el wikago este no porque este componente todavía tiene aquí como una lógica
que tiene es claro que la puedes extraer porque esta responsabilidad mejor la podrías incluso reutilizar
en otro sitio así que lo ha extraído aquí en un método y ahora queda mucho mejor este componente
mucho más fácil de entender y al final de mantener pues venga vamos con el open close principle
vamos con el open close principle el open close principle lo que el open close principle es que básicamente
las entidades que tengamos en nuestro software tienen que estar abiertas para extender pero cerradas
para ser modificadas claro esto en clases y tal pues suele tener bastante más sentido y en componentes
de react también y vais a ver por qué y tiene un ejemplo bastante claro que está muy chulo y que vais
a decir madre mía pues no he hecho estas cosas veces qué quiere decir esto que esté abierto a extensión
y cerrado para modificación o lo voy a comentar porque va a ser mucho más fácil con el ejemplo lo vais a ver
clarísimo y no vais a preocupar vale pero una cosa que tiene es que tú cuando por ejemplo necesitas
añadir o que una parte de tu software un componente tenga que renderizar algo diferente en lugar de tener
que tocar dentro del componente lo cual podría provocar que cosas que están funcionando dejen de funcionar lo
que tienes que hacer es que de alguna forma desde fuera seas capaz de extender la funcionalidad que tiene
ese componente o sea que en lugar de tener que modificar lo de dentro para añadirle para extender su
funcionalidad que lo puedes hacer desde fuera sin necesidad de modificarlo desde dentro así que al
final la idea sobre todo en react vais a ver que esto se hace mucho mucho mucho con los children con
los children sería un caso clarísimo de extensión porque tú cuando tienes un children lo que estás
haciendo es que independientemente de lo que haga dentro el children si ya tienes claro que eso es lo que
se renderiza los estás extendiendo desde fuera sea lo que sea lo que estás pasando desde fuera puedes
extender la funcionalidad de ese componente que acepta el children por ejemplo un botón y puedes
renderizar lo que te dé la gana pero en cambio por ejemplo voy a hacer un ejemplo rápido antes de
ponernos aquí no imaginad un botón un botón que a uno le llama le pasáis el children no pero tenéis
otro botón que sólo se puede pasar un title no y el title sería el title y ya está y esto es el botón
cuál es el problema que luego esto también tiene sus matices vale pero cuál es el problema que este
es extensible por defecto y este no este no es extensible este para extenderlo tienes que modificar
el componente por dentro y tendrías que empezar a poner left icon entonces icon vale y ahora dentro
tienes que añadir esa prop tienes que hacer que funcione en cambio este botón pues en algunas
pasas le ponías clic aquí y en otro sitio le dirías vale ahora necesitas un left icon bueno pues lo único que
voy a hacer aquí es ponerle un laza left icon no podrías poner por ejemplo crear un componente que
sea botón le fall con que puedes ponerlo dentro y aquí poner el icono que tú quieras no por ejemplo
svg no sé qué no sé cuánto es extensible y esto podría funcionar desde el principio desde fuera sin
necesidad de entrar al componente button hemos podido extender su funcionalidad sin modificar el
original de esta forma no hemos roto el contrato ese componente por dentro y que a mejor se está
utilizando un montón de sitios hasta aquí bien ahora lo vais a ver bastante claro con el ejemplo
el patrón de los slots bueno me parece bien el patrón de los slots hay que tener en cuenta que esto se
puede llevar a otros sitios no sólo en children o sea el children es un ejemplo muy claro pero tenerlo en
cuenta que lo puede llevar a otros sitios vale entonces vamos a ver el ejemplo este de open close
principal aquí lo que tenemos tenemos las props de nuestro componente tenemos un componente title y este
componente title recibe un title un type un href el botón text y el onclick bueno que lo tenemos tipado
aquí y lo que podemos ver dentro del componente justamente es que si el tipo es with link button
entonces renderiza un botón que se hace un clic y dentro esto esto no tiene sentido no nos hagáis
caso de que esto tenga sentido y chero sec un placer gracias por por la raid y por pasarte y genuino
buenas tardes estamos justamente hablando de principios solid en riac así que nada si os gusta la
programación quedaos que está bastante interesante entonces aquí tenemos un ejemplo y esto lo puedes ver
también en rutas por ejemplo en una ruta que te diga si el paz es igual a tal renderizo tal no por qué
porque eso significa que vas a tener que modificar por dentro el componente cada vez que añadas una
nueva buta una nueva ruta o lo que sea entonces esto no tenga muy claro o sea no de hecho yo creo que
esto esto no tiene mucho sentido vamos a poner un tip porque no tiene mucho sentido semánticamente vale
vamos a dejarlo así entonces imagínate que pone with link button vale pues tendrías esto with normal button
vale tendrías esto pero qué pasa si el día de mañana tengo el with midu button no digo ah pues
ahora puede decir midu button el midu button vale pues tengo que añadirlo manualmente tengo que modificar
esto tengo que justamente tengo que modificarlo si lo tengo que modificar significa que no estamos
cumpliendo el principio que tiene que ser abierto a extensión cerrado a modificación vamos a ver cómo
podemos arreglar esto para que no se modifique vamos a separar todo en componentes vamos a tener
uno que sea el del title el del title tiene todo sentido que exista así que vamos a crearlo este como
el vamos a ponerle title props ahora lo cambiaré porque sólo vamos a editar vamos a editar menos cosas como
hemos visto en la estrategia del children vamos a utilizarla también aquí así que vamos a poner es
qué es lo que tiene que devolver el title bueno ya veo que tiene este dip vale esto parece que sí que lo necesita
el h1 también lo necesita pero fíjate que aquí tenemos como dos children diferentes no así que lo que vamos a hacer
es que esta parte que es la que se extiende o que queremos extender de este componente sin necesidad de
modificarlo vamos a hacer que esto sea con el children vale ahora lo que podemos hacer con el title vamos a tener aquí
el title props vamos a poner que el title sea un string entonces este title por ahora lo voy a comentar para que lo
podamos ir modificando ahí no me fijado si estaba funcionando el ejemplo a ver vale hasta que lo hemos
dejado vamos a quitar este de single responsibility principal vamos a renderizar el de open close que se
le estaban pasando ya las props así que perfecto y todo esto lo ponemos aquí mira voy a ponerlo bien
para que lo podamos comentar y descomentar uno a uno y vamos a ver si esto se renderiza algo principio
solo y react bueno como podéis ver no tiene mucha historia también es verdad que no le he pasado a
mejor el button text a ver button text aloja vale es que esto es with el type with link button vale
que puesto solo default vamos a poner el with normal button aquí por enseñar algo no no sé si es que se
ha quedado así si es que me estás en mira donde me está saliendo el botón la madre que lo parió y que
está en la otra punta yo me estaba fijando ahí dios vale está aquí la aloja vale estaba ahí estaba ahí
bueno quería ver que todo funcionaba para que ahora lo refactor icemos vale y veamos que sigue
funcionando entonces como os decía estaba creando este componente por aquí y aparte de este componente
lo que vamos a hacer es justamente separar el title como en dos sitios no vamos a tener por un lado el
title ya lo hemos separado pero ahora vamos a tener más podemos tener el title with link props y lo que
vamos a hacer es que solo tenga las props que realmente necesita porque encima lo que es
interesante de esto es que podemos ver que vamos a evitar que le pasemos a lo mejor props a un
componente que no necesitaba así que vamos a hacer un export cons con el title with link esto vamos a
decirle que tiene estas props like title with link props entonces igual title el chref y botón de mi
sí necesito un consejo por contrato al renunciar a mi trabajo tengo que avisar con 45 días de
antelación y acabo de conseguir una oferta laboral en la cual me esperan dos semanas que me recomiendas
hacer 45 días de antelación dios una oferta laboral en la cual me esperarán dos semanas lo mejor que
puedes hacer es informarte con alguien que sepa eso lo primero que sabe que sabrá mejor que yo vale
pero lo primero que puedes hacer es al menos dar dos dos semanas y a las dos semanas entonces irte o sea dar
un preaviso al menos de dos semanas aunque te vayas a ir pero das oye vale es 45 días por ley o por
convenio debe ser por convenio no por ley que son dos cosas diferentes entonces tú das dos semanas que
es así que son por ley y luego te vas normalmente eso va por convenio y luego eso sería una ir por las
malas otra que puedes hacer es avisar a tu empresa hoy es que me ha dicho dos meses dos semanas y tal
podemos hacer algo después de las dos semanas llegar algún tipo de acuerdo para hacer un traspaso yo
intento trabajar al menos media jornada durante un mes para que es que si no es que me hace mucha
no sé si va de buenas lo puedes intentar luego también puedes jugar con las vacaciones dependiendo
del número de vacaciones que tengas también podrías en lugar de 45 si te quedan 20 días de vacaciones
por decir algo podrían ser sólo 25 días y a lo mejor ahí la otra empresa sí que lo considera así que
hay un montón de cositas que puedes echarle un vistazo venga vamos con esto vale lo que estamos
haciendo aquí lo que estamos haciendo aquí básicamente es el hecho de vamos a ir separando
el title with link entonces utilizamos el title que es el componente que hemos creado y en el title
with link lo que hacemos bueno en este caso no me acuerdo cómo era el del link es está aquí vale
pues hacemos esto realizamos sólo lo que necesitamos que es esta parte aquí esta parte de aquí papá y el
title title dice no puede redeclarar vale esto lo vamos a comentar lo comentamos aquí tenemos aquí el
title esto que cerré por aquí vale y el title de que se me queja title dice title children no es asignable
bueno igualmente title es por el fc este que creo que han quitado el children no existen en el title
props react no acuerdo sea react element o react note ahora puedo hacer un retour de esto vale vale
problema también es que si no algún retur de esto esto va a renderizar lo que yo sé vale vale creo
que esto no es necesario a posee bueno bueno pues ahí lo tenemos vale pues ya estaría no tenemos el
title with link y lo mismo podríamos hacer con el title with button props que lo voy a sacar aquí
rápidamente porque si no si no me puedo estar aquí todo el día y esto estaría mal y ya estaría o sea
tendríamos habríamos separado teníamos el title mucho más extensible a partir de las children luego tendríamos
la parte que era con el link no y utilizaríamos el title pero le pasaríamos por children la parte
que tiene que cambiar y luego la del button props sería lo mismo pero el children sería otro diferente
entonces esto lo que estamos haciendo es que el title y en este caso con el open close principal a nivel
de componente para que veáis claramente tenemos los bueno no sé por qué no funciona no sé si es que no
acuerdo vale aquí lo tenemos funcionando lo que pasa vale que ahora ahora en lugar de tener este open
close principal que era el que le pasamos el title el type veis que le pasamos un type en lugar de
pasarle un type para indicar cuál es el que tiene que utilizar es que directamente ahora lo que podemos
hacer es utilizar el title with link entonces lo que haríamos aquí es importar el title with a no with
normal button perdón es el que queremos utilizar with button aquí he puesto props la madre que me trajo
with button vale lo traemos aquí lo traemos aquí esto lo quitamos aquí este href no tiene sentido de
hecho es que además es mejor aquí pero fíjate que además al no tener un componente tan grande sino
es que sólo con las props que necesita tenemos la propiedad un clic que nos dice oye es que para
este componente en concreto necesitas en un clic de otra forma puedes tener un montón de errores cuando
tú haces que se pueda modificar de dentro y cambias muchos comportamientos desde dentro al final lo que
te pasa es que dejas de tener single responsibility no y tienes un montón de props para cambiar el
comportamiento desde dentro en lugar de ser extensible sino que lo tienes que modificar para
cambiar su comportamiento y entonces aquí haríamos esto esto por aquí esto por acá y aquí tenemos en
la loja vale en la loja y esto aquí ahora lo bueno es que imagínate que el día de mañana tenemos este
componente en 800 sitios imagínate es que cada aquí es donde está la gracia no imagínate que lo tienes
800 sitios y necesitas un tercero dices ostras es que ahora necesitamos un title con otro tipo de
botón vale export const title with yo que se especial batón vale y tú lo creas aquí y ya tienes
un componente totalmente nuevo que vas a hacer que todos los demás anteriores sigan funcionando sin
ningún tipo de problema para evitar pasar tantas propias modificar comportamiento interno se puede
usar con pon components también de hecho esto que hemos hecho aquí también lo podríamos hacer con
componentes compuestos vale eso también lo podríamos hacer podríamos hacer que en lugar de o sea
podríamos tener el title podríamos poner title aquí y hacer un compón component de forma así
vale podríamos decir no no pasarle un children como tal sino pasarle un title punto with button
algo así no y hacerlo así y aquí pasarle el onclick que no sé qué lo malo es que esto al final te puede
te puede traer otros problemas porque por ejemplo podrías poner dos podrías poner cuatro podrías poner
ocho es más difícil que es el fc fc es funcional componen eso sería el tema vale me estoy describiendo
mis errores a ver estos errores los hace todo el mundo así que no os preocupéis y a veces que de
nuevo a veces tiene sentido hacerlos otras veces hay que tener cuidado de no pasarse vale que uno sino
al final se vuelve muy loco en el ejemplo que ponen ellos vale el típico de las rutas este es muy claro
también el lugo este sería el ejemplo malo no utilizando vale si es para mí que render hizo esto
si es para mí utilizo esto claro esto al final no está siguiendo el principio y lo que está pasando
es que cada vez que tú añadas un nuevo paz me paz me vas a tener que ponerlo aquí está están
modificando el componente por dentro así que claro utilizando el children es que en la clave utilizar
el children no y entonces en cada children vas poniendo aquí encima hecho dos cosas por un lado en el
género que le está poniendo para ir claro para cambiar el link porque si estás en una página
otra quieres cambiar el botón para ir a una página u otra perfecto ahí ya está pues pensaba que porque
aquí es como lo está haciendo aquí en el género vale es que es el componente género vale vale pues
tiene sentido vale o sea en el género está haciendo el chile está haciendo exactamente lo mismo que hemos
hecho nosotros pero con otro componente que sería el género de una página que estoy que sí que tiene sentido
así este género está abierto a extensión pero no está abierto a modificación no es que necesiten
modificarlo sino que tú lo extiendes y ya está ten en cuenta que aunque hemos visto dos ejemplos de
children esto a veces puede ocurrir también con una prop por ejemplo qué pasa que en el género a
lo mejor tienes clarísimo que siempre vas a tener una href que va a ir a una página no sería no estaría
tan mal utilizar props no pongáis a utilizar a las children para todo porque no tiene por qué o sea esto
es llevarlo un poco al extremo porque a lo mejor lo que estás haciendo aquí es dejarlo demasiado abierto
la extensión en el sentido de que alguien pueda en lugar de renderizar un link renderizar un button
imagínate que por lo que quieras quieras forzar a que siempre sea un link pues a veces no tiene tanto
sentido abierto a verlo tanto abrirlo tanto vale esto lo digo para que tengáis en cuenta como siempre
el contexto el contexto súper importante ok vale vamos con liskov bueno de liskov no sé si esta gente tiene algún
ejemplo a ver liskov vale liskov básicamente es que un objeto que sea un subtipo de objeto debería ser
sustituible por un objeto que sea del que hereda un súper un súper tipo de ese objeto o sea que son
intercambiables si tú haces por ejemplo un animal y un perro el son deberían ser intercambiables sin
que petase absolutamente nada sin que algo reventase o sea supuesto tú deberías poder utilizar un perro y
deberías poder utilizar un animal porque al final si la clase perro está heredando de animal debería
funcionar tú tienes el perro que extiende animal o el gato que extiende animal y entonces qué pasa que el
perro puede nadar y el gato no puede nadar esto también se hace muchas veces con pájaros por ejemplo
el pingüino no puede volar esto que está en japonés porque el ejemplo que he encontrado estaba en
japonés y me ha hecho mucha gracia ha dicho ostras se ve súper bien la letra fíjate tú alguien la puede
leer me imagino que dice hola soy un gato no me da la gana no me gana nada en este caso se está
rompiendo justamente este principio el gato como el animal deberían ser intercambiables y lo que está
pasando aquí es que si de repente utilizas es el gato pues esto te petaría porque te daría un error y por lo
tanto bueno en este caso sería así el new cat esto te daría un error y por lo tanto no estaría
cumpliendo el principio para evitar esto podrías hacer otro tipo de cosas por ejemplo podrías
utilizar en lugar de tener una super clase que esperas tener el reino animal al final lo que
podrías tener son tipos de animales por ejemplo los animales que pueden nadar y entonces esto sería
de swimming animal no el perro si es que sería su mismo animal pero el gato no se haya sumin animal
sino que sería de walking animal por decir algo y aquí este sí que no necesitaría ni siquiera
implementar el swing porque es que ni siquiera lo necesita esto pasa por ejemplo con una clase de
pájaros y tal pero este ejemplo es muy de general en react un ejemplo que a mí se me ocurriría un
componente por ejemplo pongamos un botón pongamos que tenemos un botón y que tenemos un text un title y
un color vale un color y usáis me vamos a hacer un color y usáis y vamos a poner un children vamos a
hacerlo así vale y hacemos un retur del batón y le ponemos esto no y ponemos aquí el children y
ponemos aquí que esto es del color del color que venga y que esto es del tamaño que venga vale por
decir algo claro esto tendría sentido porque al final le estamos pasando más bueno esto no sería así
exactamente vamos a poner así style color 6 vamos a poner que este 6 vamos a poner que si el 6 si el 6
es xl pues entonces vamos a poner que 18 32 píxeles y si no 16 píxeles vale no os fijéis tanto en la
implementación sino más bien en lo que vamos a hacer después entonces esto hasta aquí esto cerraríamos
aquí vale y este batón lo haríamos pequeño vale no os fijáis tanto en la implementación este botón de hecho
lo voy a cerrar un poco para que no pongamos que tenemos aquí por ejemplo un red batón que está al
final lo que tiene es el children y sólo el size y esto lo que hace es retun tenemos un botón que
ya tiene justamente tanto utilizaría el que hemos creado que le pasaríamos el 6 el 6 y el color siempre
sería red este retún no hace falta pues cuál sería uno de los problemas que tendríamos si no
estuviéramos siguiendo este principio del iscov pues un problema sería imaginar que este size en lugar de
ponerle 6 vamos a ponerle entonces is big dentro de aquí le ponemos xl y si no le ponemos aquí sm por
decir algo vale entonces aquí lo que estaremos haciendo imaginar que tenemos aquí un componente
imaginar que tenemos un componente y que tenemos aquí el red batón y tenemos aquí el children que sería
aquí mi botón rojo bueno en lugar de botón rojo mi botón que funciona mi botón que funciona tenemos el
retún de esto con el red batón y le decimos is big es es cuál es el problema imaginad que el día de
mañana decimos no no no es que este botón lo quiero cambiar lo quiero cambiar por el componente por el
que estamos componiendo lo vale pues hacemos batón y dejamos el is big básicamente estaría como rompiendo
también la sustitución del iscov porque en lugar de tener o sea ya no funcionaría de repente aunque este
red batón esté componiendo utilizando el batón le hemos cambiado el comportamiento de las props que van hacia
abajo aquí hemos hecho aquí algo especial y le hemos cambiado el nombre lo mismo podría ser también por
ejemplo con un usuario que en un sitio pongamos name y en otro first name por decir algo o el
comportamiento que hagamos dentro sea diferente pero en este caso lo que estamos haciendo es
red batón al final no hereda como una clase pero sí que podríamos decir que es un objeto que es un
subtipo de este tipo que es superior vale porque este sería como el del que estamos generando todo así que
lo que nos gustaría es que en lugar de tener el is big este así de esta forma es que el size sea
compatible exactamente con el que tengamos arriba y que no es que reviente o que pase una cosa diferente
y así podríamos dejar justamente esto y si ahora en el size digamos que ponemos que el size es xl el día
de mañana podríamos utilizar tanto el subtipo como el tipo en este caso el batón sin que se rompa
absolutamente nada no hay ningún cambio de comportamiento y tal obviamente si que de la
guay porque deberíamos añadirle qué color queremos pero normal porque al final el red batón es normal
que sea más específico eso es normal como el perro es más efe específico de un animal pero lo que no
es normal es que de repente utilizando el subtipo se rompa lo que vamos a hacer con el tipo vale no sé
si se ha entendido pero ahí estaría el tema el tema es el subtipo lo deberíamos poder sustituir con
el tipo sin ningún tipo de problema ok ahí lo hemos entendido o sea el red batón lo deberíamos cambiar
fácilmente por el por el batón y no debería romperse absolutamente nada por ese ejemplo se me ocurre el
típico objeto de que retornar varias funciones para no usar un switch todos deberían poder usarse con los
mismos parámetros de poderes devolver componentes las funciones al final los componentes el subtipo lo
podrías poder cambiar por el tipo para ese principio ayuda mucho type script es verdad vamos con otro
interface segregation principal venga vamos con el otro interface segregation en este caso lo que
comenta el artículo es que el interface segregation es que los clientes no deberían depender de interfaces
que no necesitan esto lo hemos visto con el primer ejemplo de que teníamos un componente muy grande que
necesitaba o sea que recibía un montón de props que al final no necesitaba no con el primer ejemplo
sino con el segundo lo hemos visto con el de open open close principal el title al principio recibía demasiadas
cosas o sea demasiados parámetros su interfaz esta de las props fíjate recibía todo esto cuando
dependiendo del type había veces que no lo necesitaba o sea si el type era default no necesitaba ninguna
de estos si el type era with link button sólo necesitaba el hrf entonces estaba recibiendo más
información de la que necesitaba y esto a veces no sólo pasa cuando hacemos estos componentes que
son demasiado grandes o que reciben demasiadas props o que tienen más de una responsabilidad esto
también puede pasar cuando vamos a cuando lo que hacemos es que viajen objetos por ejemplo mira
este ejemplo va a ser muy muy claro tenemos aquí un vídeo listo o sea tenemos un tipo vídeo tenemos las
props que es una rey de vídeos vale y entonces en items se le pasa todo pues fíjate que en el
componente thumbnail lo que estamos haciendo es pasarle todo el vídeo estamos pasando el vídeo completo
pero realmente thumbnail el componente thumbnail necesita el vídeo completo vamos a verlo si lo miramos aquí
podemos ver que aunque se está pasando el vídeo con todas las props sólo necesita el cover url esto
justamente es lo que indica al principio de que el cliente los clientes en este caso el componente
thumbnail es un cliente no necesita no necesita todas esas props sólo deberían recibir lo que necesitan
porque si no la interfaz le estamos pasando lo que tiene que como respetar es demasiado grande porque
si este componente es un nail que siempre recibe un vídeo y tiene que acceder a cover url siempre fuese
así si tú este componente lo quisieras cambiar por otro para sustituirlo no tienes esto de lo que es
cambiar por otro tendrías que asegurarte que le sigues pasando exactamente el mismo objeto de vídeo porque no
sabes si al final aquí haces otra cosa como por ejemplo en el alt que no no me meto en si es buena
práctica o mala práctica el hecho de cómo está hecho el componente si no hablamos del principio que hay que hay por encima
aquí a lo mejor title vale y en lugar de picture pues aquí ponemos un picture un image entonces es más
difícil que tú puedas seguir manteniendo la funcionalidad porque le estás pasando demasiadas
cosas vale si la interfaz es demasiado grande el contrato que tiene el componente demasiado grande
cuando lo quieras cambiar tienes que asegurarte que le sigues pasando todo el contrato de la interfaz
porque si no podría romper cosas así que este ejemplo está bastante bien a mira y encima lo que
está haciendo es seguir separando seguir separando claro y aquí pues puedes ver vale si es un si tiene
un cover url el vídeo vale pero yo entiendo que ahí le pasará ves le va a pasar sólo el cover url porque
es lo único que necesita el thumbnail así que en este caso tiene más sentido que sólo le pase la prop que
necesita mucho más fácil de testear a la hora de testear si tuvieras que simular el uso de este
componente muy mucho más fácil que pases un string a que le tenga que pasar un objeto completo con todas
las propiedades que puede tener vídeo que pueden ser en este ejemplo puede parecer muy poco pero puede
ser muchísimo aquí además como podemos ver es súper fácil que puedas extender la funcionalidad o incluso
pasarle diferentes no dependiendo de en item tiene el cover url o tiene el preview url vale pues sólo le vamos a
pasar la prop que necesita dependiendo de qué valor es el que tiene así que minimizamos un poco las
dependencias entre componentes y simplificamos el contrato que tienen los componentes en el ejemplo que yo
he puesto que es el de este interface segregation no sé qué bueno lo podemos ver muy claro igual los no sé si
os lo dejo como como como deberes pero lo que podemos ver es que en este post este objeto post está
pasando hacia abajo todo rato no post title post post date post y esto no tiene mucho sentido porque no hace
falta que lo tengan todo por ejemplo el post title pues el post title sólo hace falta que tenga el
title así que el title que puede ser esto lo podemos extraer de types y también pero para
simplificarlo vamos a poner así no bueno claro es que esto no hace falta hacerlo aquí podemos hacer que
esto sea title y esto sea lo estaríamos simplificando bastante y el date props pues esto lo mismo es que de
hecho aquí le estamos pasando en lugar de todo el post pues le podríamos pasar el crédito y tat o incluso le
podríamos pasar ya el string directamente pero bueno vamos a indicar que esto imaginemos que es
así que esto debería ser una fecha entonces el crédito vamos a poner que esto es un date y esto es tan
fácil como esto y entonces en lugar de hacer que viaje el objeto constantemente lo que vamos a hacer es
que el post title pues sólo recibe el title post title y que en este caso en lugar de todo el post va a
recibir el post date el great hat vale y ahora a ver a criticar esto muchas veces a mucha gente lo
que le pasa es que se vuelve loca con esto dice vamos a pasar esto a saco vamos vamos todo todo
pasa lo todo cuál es el problema a veces de esto que no tiene por qué ser una mala práctica en general
o sea puede estar bien a veces de hecho de nuevo el contexto es muy importante estos son principios que a
veces tienen sentido a veces tienen menos sentido que a veces tienen más sentido vale entonces hay
veces que esto mucha gente lo hace esto puede estar bien pero también puede estar mal por qué
puede estar bien porque a lo mejor tú sigues haciendo esto dices vale post title title no sé
qué pero por otro lado puede estar mal por qué porque está pasando información que no es necesaria
no aunque es verdad que aquí la interfaz te dice oye sólo tienes el string vale pues hasta ahí bien
no hay hasta ahí bien o sea al menos en la interfaz de este componente te dice que sólo recibe el title
pero igualmente estás haciendo aquí una copia de un objeto que puede ser enorme que muchas veces puede
ser innecesario vale puede ser innecesario porque imagínate que el post tiene arrays tiene lo que
sé un montón de propiedades y estás haciendo una copia estás creando un nuevo objeto en cada render
además cada vez que se renderiza este post si lo tienes controlado si lo entiendes no pasa nada
pero tenlo en cuenta imagínate que te tuvieses aquí un estado no count o likes que tienes likes
set likes y van cambiando los likes pues cada vez que cambien los likes lo que va a pasar imagínate
que esto se lo pasamos al spam y tenemos aquí los likes vale cada vez que se rendericen los nuevos
likes lo que va a pasar es que vas a tener una nueva copia aunque aunque dice pero la copia es shallow
pero bueno aunque no sea shallow creas un nuevo objeto o sea aunque no sea profunda la copia creas un
nuevo objeto creas un nuevo objeto y al final además te puede dar la falsa sensación de que lo
que estás pasando son son cosas inmutables por ejemplo si tú haces esto y pongamos que aquí en el
post date tienes un list of tags por decir algo que esto es un array obviamente no vamos a poner list
opta que esto es un array de eni voy a poner de eni porque tampoco sé de qué es puedes tener la falsa
sensación que post date está recibiendo una lista de tags que es una copia y que tal y no sé qué no sé cuánto
y te puede dar una falsa sensación porque al final lo que estás haciendo justamente aquí lo que dices
tú una copia que es que no es profunda sino que es superficial que no digo que esté bien que esté
mal que no sé qué sólo digo que lo tengáis todo esto en cuenta porque no está bien que al menos aquí
estaba en la interfaz pero aquí pasan cosas que tienen un coste que tienen unas implicaciones que
hay que controlar y hay veces que si lo haces de una forma incontrolada te puede morder vale de hecho he visto
un montón de problemas justamente con estas cosas por llevarlas al yo en este caso por ejemplo en este
ejemplo yo en este ejemplo utilizaría exactamente esto porque porque me parece bastante sencillo creo
que se entiende creo que tiene sentido extraer las dos propios que son y ya está ahora que el post
title tiene que recibir 10 props del post pues igualmente haría lo otro vale así que todo tiene su caso de
uso y su idea vale para que lo tengas en cuenta es no enviar todo un objeto en resumen esto en resumen
es evitar enviar props objetos información que los componentes no necesiten vale por ejemplo el post date
sólo sólo necesitaba el credit ad o el credit credit ad pues sólo le vamos a pasar esa información no le
vamos a pasar todo el post porque porque no necesita tener informa esa información aquí con los dibujitos
vale los clientes no deben ser forzados depender en métodos que no van a utilizar bueno de métodos
que no va a utilizar bueno en este caso ya veis que no no es tanto por ese ese estilo no aquí tenemos
ejercicios todos los robots tienen que hacer spin around rotar no sé qué y aquí vemos que cada robot va a
hacer una cosa en concreto no los robots que tienen brazos rotan los brazos los que tienen antenas hacen
jiggle con las antenas y cada robot sólo hace una cosa sólo recibe la información que realmente necesita
en este caso es mucho más sencillo hacer esto que el context porque porque el context se puede se puede
reventar muchos de los principios que hemos estado hablando y a la hora de testear esta parte es mucho
más fácil hacerlo con pasándole un una fecha o sea que fíjate esto es tan fácil como probar o sea probar
esto está tirado haces así haces así haces un new date y ya está ya tienes este componente ya se ya
estás probando en cambio si tienes un context pero ya tienes que crear aquí un context le tendrías que pasar cuál es el
valor del context no tendrías que empezar a grapear el context puede estar bien pero hay que utilizarlo
con cuidado especialmente ya os digo que tiene casos no digo que estoy siempre en contra pero en estos en
este ejemplo yo no utilizaría un conte porque al final lo complica bastante y estamos viendo que está
tirando o sea tiene una responsabilidad de leer de un contexto sería más inyección de dependencias
porque el context lo podemos utilizar para eso pero hay que tener cuidado un poco con esto sobrecomplicar
a veces es venga vamos con la última va que sólo nos queda uno que la inversión la independencia
inversión principal como su nombre indica es que deberíamos nuestros componentes nuestra clase
funciones deberían depender de abstracciones y no de implementaciones concretas por ejemplo antes
justamente hemos podido ver un ejemplo con el axios no era una implementación concreta ya os digo que
depende como lo queráis llevar al final también ría estaríamos en lugar de depender de una
abstracción está estamos dependiendo de una implementación concreta vale aquí veo ya un
ejemplo que es bastante curioso y bastante típico donde mucha gente a veces suele tener estos
problemillas aunque tiene alguna cosa que no está mal no porque aquí podemos ver que este fetcher lo
que es interesante es que aquí podemos ver que estamos como dependiendo del use swr aquí tendríamos
esta url y estamos dependiendo de este fetcher que sabemos como su implementación de la url y tal
o sea tenemos una implementación de que necesitamos un fetcher con una url y esto lo tenemos aquí o sea
esto no tenemos una cosa que nos esté abstrayendo de esta necesidad para arreglar esto lo que podríamos
hacer es crear una abstracción que no dependiese absolutamente nada de saber la url ni de que necesitamos
este fetcher a ver que necesitamos el fetcher sí que lo vamos a saber y no pasaría absolutamente nada
pero lo que podríamos es separar tanto el usefetch para quitar el fetche este de aquí en medio o sea
lo que vamos a hacer por ejemplo sería sacar todo esto en un custom hook y depender mira vamos a crear
el custom hook le vamos a llamar usefetch vale punto tsx bueno tsx no hace falta ts por donde empezamos
vale empezamos con el use sw vamos a crear no sé si crear la interfaz porque a lo mejor alguno se vuelve
aquí un poco tarumba tenemos la key de string y aquí vamos a utilizar el fetcher vale fetcher y que el fetcher
no te vuelva una promesa del tipo t estamos creando como la interfaz que sea como la extracción y lo
mismo vamos a hacer con la respuesta de esta forma lo que vamos a conseguir es que si el día de mañana
en lugar de poner aquí que necesitamos el fetcher necesitamos esta url en lugar de depender de saber
de dónde vamos a extraer la información lo que vamos a hacer es separarlo para poder cambiarlo e inyectarle
un sitio totalmente distinto o sea decir vale lo vamos a sacar de un sitio diferente lo podemos sacar de una
url podemos sacar de otro point del local storage de la caché de donde tú quieras vale entonces aquí
lo que podemos tener claro es que lo que necesitamos es que cumpla tanto la interfaz del usefetch como la
de la respuesta es lo que queremos que cumpla no así que le vamos a poner aquí la respuesta y que
queremos que esto tenga la data sino que sean define el error string y todos los que lo que queramos
que queramos utilizar a la hora de recuperar esta información es importante que cumpla esta abstracción que
estamos haciendo y esto porque se queja de ahora hacemos este usefetch que le llamamos usefetch porque es de hacer
un fetch de datos como le podemos llamar use data vamos a llamarle use data vale en lugar de usefetch porque
fetch parece que es muy de la implementación y como hemos dicho justamente queremos evitar la
implementación vale le vamos a poner le vamos a pasar tanto un aquí como el fetcher y esto que estamos haciendo
también lo que estamos evitando es que nuestro componente sepa que estamos utilizando sw swr
¿vale? usefetch le pasamos la t por aquí y esto devuelve la respuesta del tipo t ¿vale? no sé si he puesto esto bien creo que sí
response vale y ahora tenemos que devolver lo nuestro ¿no? tenemos la data bueno esto sí que no lo podemos copiar de aquí más o menos
¿ok? tendríamos aquí la data el error si está validando tendríamos aquí en lugar de swr este aquí lo que le pasaríamos por un lado sería lo que queremos
recuperar y aquí tendríamos la key ¿vale? el aquí el fetcher y devolveríamos tanto la data como el error como se está validando ¿vale?
hemos creado una abstracción lo que estamos haciendo es utilizar el swr pero abstraído ¿por qué? porque ahora en nuestro ejemplo de bueno si lo he hecho todo bien porque he hecho un montón de cosas
pero en nuestro ejemplo bueno lo que haríamos es que podríamos utilizar este fetcher y se lo podríamos inyectar directamente ¿vale? se lo estaríamos pasando en lugar de tener la implementación
aquí lo que estaríamos es inyectarlo o sea que todo esto lo podríamos utilizar sin necesidad de saber cómo vamos a hacer el fetch de datos lo podríamos hacer de un montón de formas y ahora lo veremos
el fetcher este lo vamos a utilizar todavía pero vamos a poner aquí el type del response type que lo vamos a necesitar vamos a pasar con el id el id que sea un number y el title title un string ¿vale? response type y esto le vamos a decir en lugar de utilizar el
uswr este vamos a utilizar nuestro usefetch usefetch que no me ¿por qué no me lo no lo he exportado? ¿sí? ah que lo he llamado usedata perdón usedata ¿vale?
lo importamos ahora quitamos la importación esta de uswr y ahora que tenemos esto le ponemos el response type que va a ser un array con el aquí todos y directamente el fetch
si decimos que esto va a devolver primord response type ¿vale?
alguna... ah porque ya no necesitamos ya no necesitamos esto y ahora os explicaré por qué no necesitamos la url
¿por qué ya no le pasamos la url? ahora os lo explico porque esto vamos a llamarle en lugar de fetcher vamos a llamarle
fetcher from api por ejemplo ¿vale? y esto en realidad ya sabe que api es la que quiere utilizar ¿no?
la hemos visto antes es esta de... bueno ahora espérate ¡ah mira! perfecto joder el keyhackopilot me ha salvado
es esta url ya esto ya lo tenemos y aquí tenemos el fetcher from api ¿qué hemos hecho con todo esto?
bueno espérate que todavía... algo no le gustaba usedata... bueno igual se me ha escapado alguna cosa a la hora del...
¡ah! es que le llamamos fetcher es que es que tiene que llamarse fetcher perdón ¿eh? perdón es que se tiene que llamar fetcher
quería poner aquí el tema este de que... ahora sí ¿vale? ¿qué hemos hecho aquí? tenemos como esta abstracción
que le hemos llamado usefetch que al final tenía que haber sido usedata porque no queremos que se llame usefetch
pero bueno hemos creado esta interfaz ¿vale? que es una abstracción donde vamos a pasar tanto la key que es un string
y lo que le vamos a inyectar como dependencia y esto es lo que es súper importante y es lo que te vuelve loco
porque lo que hemos hecho aquí gracias a toda esta abstracción es que le podemos inyectar
cómo vamos a hacer el fetching de datos sin saber de dónde lo va a sacar
lo importante de todo esto es que realmente tiene que cumplir todo este contrato
tiene que cumplir que le tenemos que pasar una key de un string y le tenemos que pasar un fetcher
que va a devolver una promesa ¿vale? no le devolvemos ningún parámetro
y tiene que devolver una promesa donde nos devuelva el tipo genérico t
que es el que le estamos indicando aquí a esta t
si esta t, esta t sería justamente el response type, un array del response type
que hemos dicho que sería un array de ids y titles
ya hemos creado esta abstracción y estamos utilizando todo esto
sin necesidad de saber si lo vamos a sacar de una API, de GraphQL, de MongoDB, yo que sé
de local storage y vas a ver cómo de potente es porque una vez que tienes esto
que esto lo podríamos separar ¿eh? en lugar de ponerlo aquí, este fetcher aquí en medio
lo podríamos separar a otro archivo y todo esto
este fetcher lo tenemos así como que al final podríamos crear otro fetcher
que haga exactamente, cumpla la interfaz ¿no? promise, response type
esto va a cumplir la interfaz
pero lo que va a pasar es que en realidad lo va a sacar por ejemplo de un objeto
o sea, esto es un objeto y podemos ver que no se queja absolutamente de nada
porque está cumpliendo exactamente la misma interfaz
y esto podría también exactamente funcionar si en lugar de hacer esto
pusiéramos que esto lo saca de local storage.getItem
y tenemos aquí los post y esto hacemos
bueno, esto sería un poco más complicado porque aquí tendríamos el item
y tendríamos que hacer un return
si tenemos el item, json, parse, items
bueno, vamos a ponerle posts, posts
entonces hacemos posts, posts, posts
y si no, pues hacemos un arriba
pero fíjate que estos tres
lo que estamos haciendo es justamente inyectar esta dependencia
de forma que independientemente de donde extraemos los datos
independientemente, o sea, no nos estamos
yo no sé, nada de aquí, nada de lo que hay aquí
o sea, si yo desapareciese esto
que no funcionaría obviamente
pero lo que estamos haciendo es que esto se lo podríamos inyectar por aquí
le podríamos pasar por props o por context
podríamos utilizar un context justamente
y fíjate lo potente que es esto
fíjate lo potente que es esto, ¿vale?
lo potente que es esto es que podrías utilizar
imagínate que tenemos un useContext
y tenemos aquí fetcher o todos from API
esto lo he llamado fetcher, useContext
podríamos hacer así
decidir nosotros si lo queremos recuperar de la API
from local storage, de donde sea, ¿vale?
le he llamado useContext y esto deberíamos pasarle el context
pero bueno, ya me entendéis, ¿vale?
o useGlobalContext
para que lo entendáis mejor
o directamente que sea totalmente transparente
que fetchToDo sea el fetcher
y que solo desde el punto del global context
desde un solo sitio
estemos cambiando de dónde vamos a sacar esta información
y nosotros en estos componentes
no estamos viendo en ningún sitio
en ningún sitio
estamos viendo realmente de dónde sale esta información
porque en ningún lado se ve que estamos haciendo un fetch
si estamos atacando una API
si vamos al local storage
si sale de las cookies
si le estoy haciendo un mock
no lo sabe, no lo sabe, ¿vale?
esto es lo que hace que esto sea
la inyección de dependencias
hace que sea realmente potente
en este caso, el caso más claro
se ve justamente aquí
estos tres fetchers
se los podemos inyectar
y los tres funcionan
porque cumplen el contrato
cumplen la abstracción
y no nos basamos en la implementación
a la hora de utilizar todo esto
¿ok?
así que esto es lo que es realmente potente
lo importante
y lo interesante
de la inyección de dependencias
y esto lo podéis hacer
en un montón de historias, ¿vale?
si el fetcher es un mock
¿para qué sirve la key?
la key esta
a ver, por ejemplo
este fetcher
este es un mock
esta key en realidad
es un tema más de SWR
¿vale?
esta key lo utiliza
para el global state
para la caché
y este tipo de cosas
o sea, al final
si tú este todo
esto lo haces
desde otro sitio
va a utilizar
la caché interna
para no volver a llamarlo
o si lo actualizas
para sincronizarlo
este tipo de cosas
pero ¿os quedáis con esto?
con la potencia
que tiene esto
o sea, yo creo que
aquí es donde se ve
justamente lo interesante
¿no?
el hecho de
cómo tienes aquí ahora
tres fetchers
que esto es totalmente
claro
es que ahora no tengo
el...
¿no?
¿no?