Principios SOLID en React.js (Buenas prácticas) con ejemplos prácticos
Summary
TLDRThis video script delves into the five principles of SOLID (Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion) within the context of React. Through practical examples and code implementations, it explores how adhering to these principles can lead to more maintainable, extensible, and flexible code. The instructor guides viewers through refactoring components, separating concerns, and applying techniques like abstractions and dependency injection to achieve better code organization, reusability, and modularity.
Takeaways
- ๐ SOLID principles were originally designed for object-oriented programming but are also applicable to functional programming and component-based architectures like React.
- ๐ฆ The Single Responsibility Principle states that each class, component, or function should have only one responsibility or purpose.
- ๐ The Open/Closed Principle dictates that software entities should be open for extension but closed for modification, promoting code reusability and avoiding breaking changes.
- ๐ The Liskov Substitution Principle ensures that subtypes must be substitutable for their base types without altering the correctness of the program.
- ๐ฆ The Interface Segregation Principle recommends that clients should not be forced to depend on interfaces they do not use, promoting modular and loosely coupled designs.
- ๐ฆ The Dependency Inversion Principle states that high-level modules should not depend on low-level modules; both should depend on abstractions, promoting decoupling and easier refactoring.
- ๐ Adhering to SOLID principles can improve code maintainability, extensibility, and testability in React applications.
- ๐คนโ It's essential to strike a balance when applying SOLID principles, as taking them to the extreme can sometimes lead to over-engineering and complexity.
- ๐ฌ Effective communication and context are crucial when discussing and implementing SOLID principles within a team or codebase.
- ๐ง Continuous learning, practice, and adapting SOLID principles to specific use cases are necessary for mastering their application in React development.
Q & A
What are the SOLID principles in React?
-The SOLID principles are a set of guidelines for writing maintainable, scalable, and flexible code in object-oriented programming. While originally intended for OOP, these principles can be applied to other paradigms, including React. The SOLID principles are: Single Responsibility Principle, Open/Closed Principle, Liskov Substitution Principle, Interface Segregation Principle, and Dependency Inversion Principle.
Can you explain the Single Responsibility Principle with an example in React?
-The Single Responsibility Principle states that a class or component should have only one reason to change. In React, this means that a component should have a single, well-defined responsibility. For example, separating the data fetching logic from the rendering logic into separate components or custom hooks can help adhere to this principle.
What is the Open/Closed Principle, and how can it be applied in React?
-The Open/Closed Principle states that software entities (classes, modules, functions, etc.) should be open for extension but closed for modification. In React, this can be achieved by using composition and rendering different components based on props or state, rather than modifying the existing component's behavior.
Can you give an example of the Liskov Substitution Principle in React?
-The Liskov Substitution Principle states that subtypes should be substitutable for their base types without altering the correctness of the program. In React, this principle can be applied by ensuring that child components adhere to the same contract as their parent components, and can be used interchangeably without breaking the application.
What is the Interface Segregation Principle, and how is it relevant in React?
-The Interface Segregation Principle states that clients should not be forced to depend on interfaces they do not use. In React, this can be achieved by breaking down large components into smaller, more focused components that receive only the props they need, rather than passing unnecessary data down the component tree.
Can you explain the Dependency Inversion Principle and its importance in React?
-The Dependency Inversion Principle states that high-level modules should not depend on low-level modules; both should depend on abstractions. In React, this can be achieved by using dependency injection and creating abstractions (e.g., hooks or services) that decouple components from specific implementations, making the code more modular and testable.
How can the SOLID principles improve code maintainability and scalability in React applications?
-Following the SOLID principles in React applications can improve code maintainability and scalability by promoting modular design, loose coupling, and separation of concerns. This makes it easier to understand, modify, and extend the codebase without introducing unintended side effects or breaking existing functionality.
Can you provide an example of how the Dependency Inversion Principle can be applied using React hooks?
-Certainly. The Dependency Inversion Principle can be applied in React hooks by creating custom hooks that abstract away implementation details and can be injected into components as dependencies. For example, you could create a custom hook for data fetching that can be injected into different components, decoupling them from the specific implementation of the data fetching logic.
How can the Open/Closed Principle be applied when working with React component libraries?
-When working with React component libraries, the Open/Closed Principle can be applied by designing components that are extensible through composition and props. For example, a library could provide a base component that can be extended by wrapping it with additional functionality or rendering custom content within it, rather than modifying the base component directly.
Can you discuss the trade-offs between following the SOLID principles strictly and pragmatism in React development?
-While following the SOLID principles can lead to more maintainable and scalable code, strictly adhering to them can sometimes introduce unnecessary complexity or overhead. Pragmatism is important in React development, and it's often necessary to find a balance between following best practices and keeping the codebase simple and readable. The key is to understand the principles and apply them judiciously, considering the specific requirements and constraints of the project.
Outlines
🔵 Introduction to SOLID Principles in React
This paragraph introduces the SOLID principles and their relevance in React development. It explains that SOLID is an acronym representing five principles for object-oriented programming design, but these principles can be applied to various software design paradigms, including functional programming and component-based architectures like React. The speaker plans to refactor examples for each principle and discuss their application in React.
🟢 Single Responsibility Principle
This paragraph focuses on the Single Responsibility Principle (SRP). It states that a class should have a single responsibility, and this concept can be extended to React components. The speaker demonstrates a component that violates SRP by handling state management, data fetching, and rendering logic. They refactor the component by extracting the data fetching logic into a custom hook, separating concerns and responsibilities. The paragraph emphasizes the importance of keeping components focused on a single responsibility for maintainability and reusability.
🟠 Continuing Single Responsibility Principle
This paragraph continues the discussion on the Single Responsibility Principle (SRP). It explores further refactoring opportunities by separating the state management and data fetching responsibilities into separate functions or services. The speaker emphasizes that while adhering to SRP is beneficial, taking it to extremes can lead to over-engineering and complexity. The key is finding the right balance based on the project's context and requirements.
🟣 Open/Closed Principle
This paragraph introduces the Open/Closed Principle (OCP), which states that software entities should be open for extension but closed for modification. In the context of React, the speaker provides an example of a component that violates OCP by requiring modifications to handle different types of components. They refactor the component using the composition pattern and the children prop, allowing the component to be extended without modifying its internal logic. The paragraph highlights the importance of designing components that can be extended from the outside rather than modified internally.
🔴 Continuing Open/Closed Principle
This paragraph continues the discussion on the Open/Closed Principle (OCP) and the refactoring of the example component. It introduces the concept of component slots, which allows for further extensibility and customization of the component's rendering logic. The speaker emphasizes the importance of finding the right balance between extensibility and complexity, as excessive adherence to OCP can lead to over-engineering.
🟢 Liskov Substitution Principle
This paragraph covers the Liskov Substitution Principle (LSP), which states that subtypes should be substitutable for their base types without altering the correctness of the program. The speaker provides an example of a button component that violates LSP by introducing incompatible properties or behaviors. They refactor the component to ensure that child components inherit and extend the base component's behavior without breaking the contract. The paragraph highlights the importance of designing components that can be substituted for their base types without causing any issues.
🟠 Continuing Liskov Substitution Principle
This paragraph continues the discussion on the Liskov Substitution Principle (LSP) and the refactored button component example. It explores the notion of subtypes and base types in the context of React components, emphasizing the importance of maintaining compatibility and substitutability between them. The paragraph also touches on the trade-offs and considerations when adhering to LSP, as taking it to extremes can lead to unnecessary complexity.
🟣 Interface Segregation Principle
This paragraph introduces the Interface Segregation Principle (ISP), which states that clients should not be forced to depend on interfaces they do not use. The speaker provides examples of components that violate ISP by receiving excessive props or data structures that they do not necessarily need. They refactor the components by extracting only the required props or data, minimizing dependencies and improving testability. The paragraph emphasizes the importance of designing focused and modular interfaces to avoid unnecessary coupling and complexity.
🔴 Continuing Interface Segregation Principle
This paragraph continues the discussion on the Interface Segregation Principle (ISP) and the refactoring examples. It explores additional scenarios where components might receive or pass unnecessary data, leading to potential performance issues or false assumptions about immutability. The speaker highlights the trade-offs and considerations when adhering to ISP, as excessive adherence can lead to over-engineering or complexity. The key is finding the right balance based on the project's context and requirements.
🟢 Dependency Inversion Principle
This paragraph introduces the Dependency Inversion Principle (DIP), which states that high-level modules should not depend on low-level modules; instead, both should depend on abstractions. The speaker provides an example of a component that depends on a specific implementation (SWR) for data fetching. They refactor the component by introducing an abstraction layer that decouples the data fetching logic from the implementation details. This allows the component to depend on an abstraction instead of a concrete implementation, promoting flexibility and maintainability.
🟠 Continuing Dependency Inversion Principle
This paragraph continues the discussion on the Dependency Inversion Principle (DIP) and the refactoring example. It explores the concept of dependency injection, where different implementations of the data fetching abstraction can be injected into the component without modifying its internal logic. The speaker demonstrates how this approach promotes flexibility, testability, and separation of concerns, as the component remains unaware of the specific implementation details for data fetching.
🟣 Dependency Inversion Principle Example
This paragraph provides an additional example to further illustrate the Dependency Inversion Principle (DIP) and dependency injection. It demonstrates how different implementations of the data fetching abstraction can be injected, such as fetching from an API, local storage, or a global context. The speaker highlights the power and flexibility of this approach, as components remain agnostic to the data source implementation details, promoting loose coupling and ease of maintenance.
Mindmap
Keywords
💡Single Responsibility Principle
💡Open/Closed Principle
💡Liskov Substitution Principle
💡Interface Segregation Principle
💡Dependency Inversion Principle
💡Refactoring
💡React Components
💡Hooks
💡Abstraction
💡Modularity
Highlights
The SOLID principles are a set of design principles for object-oriented programming, but they can also be applied to other paradigms like functional programming and component-based architectures like React.
The Single Responsibility Principle states that a class or component should have only one reason to change, i.e., it should have a single responsibility.
The Open/Closed Principle states that software entities (classes, modules, components, etc.) should be open for extension but closed for modification.
The Liskov Substitution Principle states that objects of a superclass should be replaceable with objects of a subclass without affecting the correctness of the program.
The Interface Segregation Principle states that clients should not be forced to depend on interfaces they do not use.
The Dependency Inversion Principle states that high-level modules should not depend on low-level modules; both should depend on abstractions.
In React, the Single Responsibility Principle can be applied by separating concerns into different components or custom hooks.
The Open/Closed Principle in React can be achieved by using composition and children props to extend component functionality instead of modifying the component's internal implementation.
The Liskov Substitution Principle in React can be applied by ensuring that components that extend or specialize other components maintain a consistent interface and behavior.
The Interface Segregation Principle in React can be applied by minimizing the number of props a component receives, passing only the necessary data and abstractions.
The Dependency Inversion Principle in React can be achieved by depending on abstractions (e.g., interfaces, higher-order components, render props) instead of concrete implementations.
Applying SOLID principles in React can improve code maintainability, extensibility, and testability by promoting modular and decoupled components.
The context is important when applying SOLID principles; sometimes, taking a principle to the extreme can be counterproductive and increase complexity.
Dependency injection in React can be achieved by creating abstraction layers and injecting dependencies (e.g., data fetching, state management) into components, allowing for easier testability and flexibility.
The SOLID principles should be balanced with pragmatism and the specific context of the project, as blindly following them can sometimes lead to over-engineering and unnecessary complexity.
Transcripts
a playa sol y principles en react que es
solita 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
re factorizar los hay aquí ejemplos en
cada uno de los ejemplos tenemos esto es
la inversión de dependencias liskov open
close principle single dispositivo y de
cada uno tenga un código de ria que lo
que vamos a hacer es re factorizar lo
que es solid sol y 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 componentes acción con
ría 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
responsibility principal open close
principal listos sustitución interface
gration 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 rayak así que
empezamos con el primero que se les 5
responsibility principle este la
definición original es que cada clase
tiene que tener una sola responsabilidad
como os digo esto estaba pensado para la
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 por
ejemplo puedes tener la clase y usher
pero claro en la casa usher 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 quedas cambiar te va a
costar mucho eso 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 el hecho de que un componente
haga demasiado una y te quiero dar de
contexto es que hay gente que considera
que el single responsability principal
no habla tanto del código o de las
clases sino que habla más de la uner si
yo no estoy muy de acuerdo vale yo no
estoy muy de acuerdo aunque hay gente
que por ejemplo robert si martín también
habla de esto de los stakeholders 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 riad tiene sentido y
al final creo que ya va escribir
cualquier cosa tiene sentido y el
ejemplo de ría que es muy potente porque
muchas veces
justamente lo hacemos más vale que es
una responsabilidad hombre verde y coca
en responsabilidad eso es una palabra
literal en general la responsabilidad
como si una persona tuviera muchas
responsabilidades 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 muchas
tareas
que te corresponde a hacer demasiadas
cosas una responsabilidad es lo que te
corresponde hacer lo que ya sea por tu
estatus por tu puesto por la vida es lo
que tendrías que hacer y en el tema la
programación es los dotes que le estás
dando a una clase o una función cuántas
cosas tiene que hacer un componente lo
vamos a ver si un serían como freelance
eso no es verdad eso está bastante buena
mira también este este artículo está muy
chulo que es él es sólo y principal sin
pictures así que bueno lo podemos pero
también gracias por compartirlo equipan
una single responsability vale esto es
una híper simplificación una clase tiene
que tener una sola responsabilidad pero
bueno pensad justamente no sólo en
clases sino en componentes en funciones
lo que sea pero 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 separarlos 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 principio sin
responsibility tenemos un robot que es
el cocinero es un robot que es el
jardinero un robot que es el que pinta
qué es el crimen tuit 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 type script pero no os
preocupéis porque nos 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
responsability principal 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 ponerlo 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
de 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 viene tenéis yusef news state parece
que todo bien aquí tiene un tipo para ti
para 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
phising de datos vale tienes que hacer
el juz effect tienes la responsabilidad
de saber cómo haces el festín 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 como podríamos mejorar
esto siempre a ver esta es una
generalización pero es una
generalización que al menos podéis tener
en cuenta normalmente en un componente
de riac si tienes un yusef ect
significa que puedes crear un casting
hook para evitar tests así que qué es lo
primero que yo os haría yo lo primero
que haría sería crear un casting que sea
todo vale vamos a crear un casto hub y
este caso lo que vamos a hacer es
extraer primero yo extra haría todo lo
que no necesitamos dentro del componente
así que yo esto lo metería por aquí voy
a hacer una cosa antes todo esto vamos a
hacer una cosita para asegurarme que
está funcionando lo que estamos haciendo
justamente en el ts xv es que yo estoy
realizando ya todos los componentes así
que voy a comentar lo que no necesitamos
ahora vamos a ver en la local host 3000
vale aquí ya tenemos este sería el
componente que está reutilizando es una
lista como de 'todos' o sea que parece
que funciona funciona entonces vamos a
refactorización pero que asegurándonos
que funciona hubiera gustado hacer tests
hubiera sido genial porque a la hora de
autorizar los tests son muy chulos pero
en este caso no va o tiempo imposible el
día que me dedique sólo al contenido
aparte de hacer shorts de 15 segundos le
daremos cañita mal entonces en este
ejemplo lo que podemos hacer extraer en
un cartón hub y esto ahora lo vamos a
quitar de aquí vale ya no necesitamos
que significa pues que ahora fíjate cómo
se simplifica sólo con esto sólo con
esto a buenas prácticas que tenemos que
devolver podríamos devolver el de hita
el de italia vamos a dar a todo vale y
ya está vamos a hacer esto vamos a
devolver un objeto que sea to do is
facing para saber si está haciendo fecha
el tubo le va a ser el que reciba el
data o que le ponemos a que poner todo
vale y set tools
vamos a poner y así quedará mejor todo
vale y éste 'todos' sería el que de
volveríamos aquí al papá papá y ahora
esto quedaría así de fácil sus fechas
todo y simplemente haríamos esto ahora
lo que bueno esto sería 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 casto niuk
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 phising de datos dentro de
sus componentes esto además de que hace
que sea cero reutilizable porque al
final ese componente está totalmente
como atado pues lo que estamos haciendo
es separar la responsabilidad de ese
componente a un gasto que es lo que
hacen esos los dos estados del casto
bueno en este estamos guardando y
guardando los datos del festval y esto
sería para saber si
si está cargando y así cuando está
cargando podríamos hacer un reto esto
sería 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 crean books books sería your face to
to 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 nuestro componente fíjate que ni
siquiera estamos viendo yusef esto ni
siquiera estamos viendo ningún importe
de axios ningún tipo de importe vale
ningún tipo de importe swr lo veremos
después vale veremos un ejemplo con swr
y porque tiene interesante y porque es
interesante swr y cómo hacer inyección
de dependencias y todo esto
y cuál sería parecida swr ya están
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 por qué porque si miramos este
castón hood como podemos ver se dedica a
dos cosas por un lado se dedica a la
gestión del estado y por otro lado al
racing de datos así que aquí tenemos un
ejemplo de que esto tampoco tampoco
sería single responsibility vale esto
nos sería exactamente al cien por cien
responsabilidad única porque podemos ver
que tiene dos responsabilidades gestión
del estado gestión de datos vale
importante ahora bien esto significa que
deberíamos volver a refactorización
volverá a saberlo pues depende a veces
que sí a veces quiero por ejemplo todo
esto que vemos aquí esto de action o
secos en cuanto lo podríamos sacar muy
fácil volvemos a sacarlo vale y hacemos
aquí
de hecho luego vamos a indagar más en
este ejemplo podemos hacer un fet de los
tubos y que simplemente esto haga y esto
de aquí hacemos esto return vale y aquí
hacemos el de delray es punto de it 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
fixture y aquí ponemos el punto d en
tendríamos aquí ya los tutús y hacemos
el set todo
aquí le guardamos 'todos' y en el final
y podríamos sacar el falta de unidad
esto lo dejamos así y ya lo tendríamos
podríamos hacer catch del error por
ejemplo lo podríamos hacer aquí y aquí
tendríamos la responsabilidad también de
hacer un caché del error y aquí hacer
mil millones de cosas tendríamos
diferentes historias aquí por ejemplo
podríamos podríamos tener la lógica
decir vale yo soy el que se encarga de
hacer el festín de datos por lo tanto yo
soy el que decide cómo gestionar el
error en lugar de hacer un consell 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 le
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 pfets lo que vamos a hacer aquí
es comernos dentro de esto dentro de
aquí vamos a comernos ese error y
identificar cómo queremos devolver vale
aquí podríamos un knock down en lugar de
devolver el error con el status code eso
significa que sabríamos que estamos
haciendo un festín de datos pero y si
estoy viendo en un local storage y si
esto viene de las cookies y si esto
viene del gráfico él y mil millones de
historias vale esta 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 festín de datos así
que ahora ya así 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 ver subir esto
no podríamos decir service es esto sea
lo mínimo y aquí podríamos hacer tu 2.3
equis y aquí los todos pues ya
tendríamos vamos a sacarnos todo esto y
volvemos a hacer esto vale
importamos el fechu tudelano fech
'todos' fech todos quedarán aquí nuevas
todos portando 'todos' y también el tipo
de tuta esto lo habría que habría que
sacarlo sacarlo a un archivo de taiz
vale pero no puedes taquito elegida
sacando archivos al efes tutús from
services 'todos' bueno pues ahora falta
que lo pongamos
importamos el tipo del tributo y ya está
vale entonces ya podemos ver que esté
castón hub también ha dado una vuelta
más hemos vuelto a hacer el single
responsibility principle 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 señor responsability
la responsabilidad única hemos tenido
que crear una estructura de ficheros y
luego otra vez entonces está bien
separarlo pero también tiene que tener
en cuenta el coste que tiene esto y hay
veces que hay principios que si los
llevas muy lejos pueden ser
contraproducentes solo que lo tengas en
cuenta vale no no no que lo vuelvas ahí
como así hay que hacerlo sí para siempre
ya está entonces 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 qué y aquí además tiene un week
ago 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 ya aquí
vemos que está haciendo bueno el casting
lo ha separado también a un jucio users
ha sacado más cosas ves está sacando
component izando también la parte del
united lo ha sacado aquí no sé lo que
está haciendo es compone tizar s para
responsabilidades mira aquí una función
para el week hago este 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 open close principle
vamos con el open close principle el
open close principle lo que el open
close principal 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 del iac
y vais a ver porque 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 no lo voy a comentar
porque va a ser mucho más fácil con el
ejemplo lo vais a ver clarísimo y no os
vais a preocupar 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 reutilizar 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
sea 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 riad vais a ver que esto se hace
mucho mucho mucho con los children con
los chiles 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 qué es
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 puede reutilizar lo que te dé la gana
pero en cambio por ejemplo voy a hacer
un ejemplo rápido antes de ponernos aquí
no imagínate un botón un botón que a uno
le llama le pasáis el children pero
tenéis otro botón que sólo se puede
pasar un title y el tight él 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 éste es extensible por
defecto y éste no este no es extensible
este para extenderlo tienes que
modificar el componente por dentro y
tendrías que empezar a poner le fay con
entonces icon vale y ahora dentro tienes
que añadir esa proviene que hacer que
funcione en cambio este botón pues en
algunas bases le ponías clic aquí y en
otro sitio le dirías vale ahora
necesitan le fay con bueno pues lo único
que voy a hacer aquí es ponerlo en la
afa le fay con no podría poner por
ejemplo crear un componente que sea
button left eye con que puedes ponerlo
dentro y aquí poner el icono que tú
quieras por ejemplo svg no sé que no sé
cuánto es extensible y esto podría
funcionar desde él 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 hagamos 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 chile es un ejemplo
muy claro pero tenerlo en cuenta que lo
puede llevar a muchos sitios vale
entonces vamos a ver el ejemplo de este
de open close principal aquí lo que
tenemos tenemos las propias de nuestro
componente tenemos un componente title y
este componente title recibe un title un
type un hr el botón text y el un clic
bueno que lo tenemos tipado aquí lo que
podemos ver dentro del componente
justamente es que si el tipo es
whistling 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 0-6 un
placer gracias por por la raid y por
pasarte y genuino buenas tardes estamos
justamente hablando de principios solid
en riad así que nada si os gusta la
programación quedamos 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 path es igual a tal render
hizo tal por qué porque eso significa
que vas a tener que modificar por dentro
el componente cada vez que añadas una
nueva ruta una nueva ruta o lo que sea
entonces esto no tenga es 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 ponéis wifi link
button vale pues tendría sexto width
normal button vale tendrías esto pero
qué pasa si el día de mañana tengo el
wef min button no digo as pues algo
definido button el midi 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 tratamiento o sentido que exista
así que vamos a crearlo este como él
el tight el prox ahora lo cambiaré
porque eso lo vamos a editar vamos a
necesitar menos cosas como hemos visto y
la estrategia del children vamos a
utilizarla también aquí así que vamos a
ponerles 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 chiles
en 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
seguir modificando ay no me he fijado si
estaba funcionando el ejemplo a ver vale
hasta aquí 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
próx así que perfecto y todo esto
ponemos aquí voy a ponerlo bien para que
lo podamos comentar y des comentar uno a
uno y vamos a ver si esto es renderiza
algo principio sol y río bueno como
podéis ver no tiene mucha historia
también es verdad que no le he pasado
mejor el botón text haber button text
aloha vale es que esto es with type
whistling button vale es que pues todo
solo default vamos a poner width normal
button aquí por enseñar algo no no sé si
es que se ha quedado así si es que me
estás donde me estás haciendo el botón
la madre que lo parió y que está la otra
punta ya que está fijando ahí días vale
está que la aloja vale estaba ahí estaba
y bueno quería ver que todo funcionaba
para que ahora los refractory zemos 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 vamos a tener por un lado el
title ya que hemos separado pero ahora
vamos a tener más podemos tener el title
width link props y lo que vamos a hacer
es que sólo tenga las próx que realmente
necesita porque encima lo que es
interesante de esto es que podemos ver
qué a evitar que le pasemos alomejor
props a un componente que no necesitaba
así que vamos a hacer un export comes
con el title with link esto vamos a
decirle que tiene estas propias light el
whistling props entonces igual title el
chef y button milk sin necesito un
consejo como 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 esperarán
dos semanas que me recomiendas hacer 45
días de antelación dio 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
pero lo primero que puedes hacer es al
menos dar dos dos semanas y a las dos
semanas entonces irte a 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 dudas dos semanas que es así
que son por ley y luego te vas
normalmente va por convenio y luego eso
sería una y por las malas otra que
puedes hacer es avisar a tu empresa hoy
ha dicho dos semanas y tal podemos hacer
algo después de las dos semanas llegar a
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 no sé si lleva de
buenas lo puedes intentar luego también
puede 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 ya
lo mejor ahí la otra empresa así 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 'the times' del
whistling entonces utilizamos el title
que es el componente que hemos creado y
en el title wikileaks lo que hacemos
bueno en este caso no me acuerdo cómo
era el del link es estar aquí vale pues
hacemos esto reutilizamos sólo lo que
necesitamos que es esta parte aquí esta
parte de aquí para papá
y el title title dice no puede declarar
vale esto lo vamos a comentar lo
comentamos aquí tenemos aquí el tight el
estoque cierre por aquí vale y el title
de que se queja title title children no
es asignable atentamente teta
bueno igualmente title es por el fce
este que creo que no existe en el tight
el prox track un acuerdo se arría que
element no va
a hacer un tour de esto vale vale el
problema también es que si no hago un
reto de esto esto va a realizar lo que
yo sé vale vale creo que esto no es
necesario
vale pues ya estaría no tenemos el tate
el wifi link y lo mismo podríamos hacer
con el title with button prox que lo voy
a sacar aquí rápidamente porque si no le
pongo si no me puedo estar aquí todo el
día hoy esto estaría mal y ya estaría ya
tendríamos habríamos separado teníamos
el title mucho más extensible a partir
del alquiler luego tendríamos la parte
que era con el link y utilizaríamos el
title pero le pasaríamos por children la
parte que tiene que cambiar y luego en
la del botón 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 componentes
para que veáis claramente tenemos los
buenos no sé por qué no funciona nos
exigen 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 pasábamos el
title el type veis que pasamos un type
en lugar de pasarle
para indicar cuál es el que tiene que
utilizar es que directamente ahora lo
que podemos hacer es utilizar el title
with y link entonces lo que haríamos
aquí es importar el title wispa no es
normal button perdón es el queremos
utilizar width button aquí puesto props
la madre que me trajo with button vale
lo traemos aquí lo traemos aquí esto lo
quitamos aquí está hecha red no tiene
sentido de hecho es que además es mejor
aquí no acaba escapó pero fíjate que
además al no tener un componente tan
grandes en los que sólo con las propias
que necesita tenemos la propiedad a un
clic que nos dice oye es que para este
componente en concreto necesita ser un
clic de otra forma puedes tener un
montón de errores cuando tú haces que se
puedan modificar de dentro y cambias
muchos comportamientos desde dentro al
final lo que te pasa es que dejas de
tener singer responsability no y tienes
un montón de pro para cambiar el
comportamiento desde dentro en lugar de
ser extensible sino que hay que
modificar para cambiar su comportamiento
y entonces aquí haríamos esto a esto por
aquí para acá y aquí tenemos el aloha
vale el aloha 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 aquí donde está la
gracia imagínate que lo tienes en 800
sitios y necesitas un tercero dices
ostras es que necesitamos un title con
otro tipo de botón vale export const
title with yo que sé special button vale
y tú lo creas aquí y ya tienes un
componente totalmente nuevo que va a
hacer que todos los demás anteriores
sigan funcionando sin ningún tipo de
problema para evitar pasar tantas
propias modifica el comportamiento
interno se puede usar con componentes
también de hecho esto que hemos hecho
aquí también lo podríamos hacer con
componentes descompuestos vale esto
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 campo componen de forma
así vale podríamos decir no pasa lunch y
lideren como tal sino pasarle un title
punto width button algo así no y hacerlo
así y aquí pasarle a un clic que no sé
que lo malo es que esto al final te
puede que puede traer otros problemas
porque por ejemplo podrías poner dos
podrías poner cuatro podrías poner ocho
el más difícil que es el fcc fcc es
funcional componen eso sería el tema
vale me dude escribiendo mis errores a
ver estos errores los hace todo el mundo
no os preocupéis y a veces de nuevo a
veces te he sentido hacerlos otras veces
hay que tener cuidado de no pasarse para
que un nuevo si no al final se vuelve
muy loco en el ejemplo que pueden ellos
vale el tipo de las rutas estén muy
claro también en lo este sería el
ejemplo malo no utilizando vales y spam
de unter render hizo esto si spanair
utilizó de 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 pack men admin 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 ha hecho dos cosas por un
lado en el que ver qué le está poniendo
para ir claro para cambiar el link
porque se pasa una página a otra quieres
cambiar el botón para ir a una página a
otra perfecto ahí ya está pensaba que a
porque aquí es como lo está haciendo
aquí en el header vale es que es el
componente header vale vale pues tiene
sentido vale en el gdr estación el sitio
está haciendo exactamente lo mismo que
hemos hecho nosotros pero con otro
componente que sería el header de una
página que que sí que tiene sentido así
este header está abierto a extensión no
está abierto a modificación no es que
necesite modificarlo sino que tú lo
extiende hasta ten en cuenta que aunque
hemos visto dos ejemplos de children
esto a veces puede ocurrir también con
una pro por ejemplo qué pasa que en el
general mejor tienes clarísimo que
siempre vas a tener un hr que va a ir a
una página no sería no estaría tan mal
utilizar props no pongáis a utilizar a
la children's 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 a extensión en el sentido de que
alguien pueda en lugar de renderizar un
link renderizar un botón imagínate que
él por lo que quieras quieras forzar a
que siempre sea un link pues a veces no
tiene tanto sentido abierto a ver lo
tanto abrirlo tanto vale esto lo digo
para que tengas en cuenta como siempre
el contexto el contexto es súper
importante ok vale vamos con liskov
bueno disco no sé si esta gente tiene
algún ejemplo a ver disco vale disco
básicamente es que un objeto que sea un
subtipo de objeto debería ser
sustituirle por un objeto que sea del
que hereda un súper o un súper tipo de
ese objeto o sea que son intercambiables
si tú haces por ejemplo un animal
perro el son deberían ser
intercambiables sin que pase
absolutamente nada sin que algo
reventase 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 aquí 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 es tan japonés porque el
ejemplo que encontraba en estado en
japonés y me ha hecho mucha gracia ha
dicho ostras se ve súper bien la letra
fíjate si 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ía
ser intercambiables y lo que está
pasando aquí es que si de repente
utilizas es el gato pues esto te
prestaría porque te daría un error y por
lo tanto bueno en este caso sería así de
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 superclase
esperas tener el reino animal al final
lo que podrías tener son tipos de
animales por ejemplo los animales que
pueden nadar entonces esto sería de
swimming animal el perro que sería de su
mismo animal pero el gato no se asume un
animal señaló 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 riad 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 un 6
vamos a hacer un color bien 6 y vamos a
poner un children vamos a hacerlo así
vale y hacemos un retour del botón y le
ponemos esto y ponemos aquí el children
y ponemos aquí que esto del color cada
del color que venga y que esto es del
tamaño que venga vale por de final claro
esto tendría sentido porque al final le
estábamos pasando al bueno esto no sería
así esta parte vamos a poner así está
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
es lo que vamos a hacer después entonces
esto hasta aquí hasta centraremos aquí
vale y este button lo haríamos pequeño
no fijas tanto en la implentación este
vota de hecho lo voy a cerrar un poco
para que lo pongamos que tenemos aquí
por ejemplo un red button que está al
final lo que tiene es el children y sólo
el 6 y esto lo que hace es return
tenemos un botón que ya tiene justamente
tanto utilizaría el que hemos creado que
le pasaríamos el saint saëns así el
color siempre sería red este reto no
hace falta pues cuál sería uno de los
problemas que tendríamos si no
estuviéramos siguiendo este principio
del disco pues un problema sería
imaginad que esté size en lugar de
ponerle size vamos a ponerle
entonces es bic y estoy aquí le ponemos
xl y si no le ponemos aquí sm por decir
algo vale entonces aquí lo que estaremos
haciendo imaginad que tenemos aquí un
componente imagina que tenemos un
componente y que tenemos aquí el red
button y tenemos aquí el children que
sería aquí mi botón rojo bueno en lugar
del botón rojo mi botón que funciona me
votan que funciona tenemos el reto de
esto con el red button y le decimos is
big 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 que va
cambiar por el componente por el que
estamos componiendo lo vale pues hacemos
button y dejamos el lic básicamente
estaría como rompiendo también la
sustitución del disco porque en lugar de
tener o sea ya no funcionaría de repente
aunque esté red button esté componiendo
utilizando el button le hemos cambiado
el comportamiento de las propias 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 button 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 éste sería
como el del que estamos generando todo
así que lo que nos gustaría es que en
lugar de tener el svi que esté así de
esta forma es que el size sea compatible
exactamente con el que tengamos arriba y
que nos que reviente o que pase una cosa
diferente y así podríamos dejar
justamente esto y si ahora en el site
digamos que ponemos que el size es x l
el día de mañana podríamos utilizar
tanto el subtipo como el tipo en este
caso el botón sin que se rompa
absolutamente nada no hay ningún cambio
de comportamiento y tal obviamente sí
que de la ayuda y por qué deberíamos
añadirle qué color queremos pero normal
porque al final el red button es normal
que sea más específico eso es normal
como el perro es más 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
no se ha entendido pero ahí estaría el
tema el tema es el subtipo lo veríamos
poder sustituir con el tipo sin ningún
tipo de problema ok ahí lo hemos
entendido o sea el red button lo
diríamos cambiar fácilmente por el
button y no debería romperse
absolutamente nada por ese ejemplo se me
ocurre el tipo de objeto de tejero todas
las varias funciones para no usar un
switch todos deberían poder usarse con
los mismos parámetros de poder devolver
componentes las funciones al final los
componentes el subtipo lo podrías poder
cambiar por el tipo para ese principio
ayuda mucho textil es verdad vamos con
otro interface se gration principle
venga vamos con el otro interface segre
jason en este caso lo que comenta el
artículo es que el interface de gration
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 osea que recibía un montón de
proxy al final no necesitaba no que en
el primer ejemplo sino que en el segundo
no lo hemos visto con el open open close
principle el title al principio recibía
demasiadas cosas ahora demasiado
parámetros su interfaz está de las
propias fíjate recibirá 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 wifi link button sólo
necesitaba el hr entonces estaba
recibiendo más información de la que
necesitaba y esto a veces no solo pasa
cuando hacemos estos componentes que son
demasiado grandes aunque
eso que tiene más de una responsabilidad
esto también puede pasar cuando vamos
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 propias que es una red de
vídeos vale y entonces en hayter se le
pasa a todo pues fíjate que en el
componente zoom neil lo que estamos
haciendo es pasarle todo el vídeo
estamos pasando el vídeo completo pero
realmente es un mail el componente zoom
neil necesita el vídeo completo vamos a
verlo si lo miramos aquí podemos ver que
aunque se está pasando el vídeo contra
las próx sólo necesita el cover journal
esto justamente es lo que indica el
principio de que el cliente los clientes
en este caso el componente túnel es un
cliente no necesita
necesita dos aprox sólo deberían recibir
lo que necesitan porque es en una
interfaz que estamos pasando lo que
tiene que como respetar es demasiado
grande porque si este componente es un
mail que siempre recibe un vídeo y tiene
que acceder a cover y ahora él siempre
fuese así si tú este componente lo
quisieras cambiar por otro para
sustituirlo no tienes esto 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
sí es buena práctica mala práctica el
hecho de cómo está hecho el componente
si no hablamos del principio que hay que
que hay por encima aquí a mejor title
vale y en lugar de pixel pues aquí
ponemos un píxel match entonces es más
difícil que tú puedas seguir manteniendo
la funcionalidad porque le está 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 sigue pasando todo el contacto de
la interfaz porque no podría romper
cosas así que este ejemplo está bastante
bien
ah mira y encima lo que está haciendo es
seguir separando seguir separando claro
y aquí pues puedes ver vale si es un
sitio un cover y orel el vídeo vale pero
yo entiendo que ahí le pasará ves le va
a pasar solo el cover your él porque es
lo único que necesita el fonden así que
en este caso tiene más sentido que
sobrepase 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 de paso
es un string a que le tenga que pasar un
objeto completo con todas las
propiedades que puede tener vídeo que
pueden ser 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 dependiendo
de knight en tiene el cover your él o
tiene el premio journal vale pues sólo
le vamos a pasar la propia necesita
dependiendo de qué valores el que está
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 se ve
que yo no sé qué bueno lo podemos ver
muy claro igual no sé si lo dejo como
como deberes pero lo que podemos ver es
que en este post este objeto post está
pasando hacia abajo otro ratón o post
title post post state 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 a la falta
que tenga el twitter así que el title
que puede ser esto lo podemos extraer de
texto y también pero para simplificar lo
vamos a poner así no y bueno claro es
que esto no hace falta hacerlo aquí
podemos hacer que esto sea title y esto
sea no estaríamos simplificando bastante
y el day props pues esto lo mismo es que
de hecho aquí le estamos pasando en
lugar de todo el post pues le podríamos
pasar credit edad o incluso le podrían
pasar el string directamente pero bueno
vamos a indicar que esto imaginemos que
es así vale crédit de edad que esto
debería ser una fecha entonces el crit
edad vamos a poner que esto es un dato y
esto 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
taita póster y que en este caso en lugar
de todo el post va a recibir el póster
a
esto muchas veces a mucha gente lo que
le pasa es que se vuelve loca con esto
dice ah vamos a pasar esto hasta acá
vamos vamos todo todo pasando 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 y que a veces tienen más
sentido vale entonces hay veces que esto
mucha gente lo hace esto puede estar
bien pero también estar mal porque puede
estar bien porque a lo mejor tú sigues
haciendo esto dices vale post-it el
title no sé qué pero por otro lado puede
estar mal porque porque estás pasando
información que no es necesaria no
aunque es verdad que aquí la interfaz te
dice oye solo 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
twitter pero igualmente estás haciendo
aquí una copia de un objeto que puede
ser enorme que muchas veces puede ser un
innecesario vale puede ser innecesario
porque imagínate que el post tiene a
reyes creo que se un montón de
propiedades si estás haciendo una copia
estás creando un nuevo objeto en cada
render además cada vez que se realiza
este post si lo tienes controlado si lo
entiendes no pasa nada pero tengo en
cuenta imagínate que te hubieses aquí un
estado count
o likes suponemos que tienes likes &
likes y van cambiando los likes pues
cada vez que cambien los likes lo que va
a pasar imagen que estos lo pasamos al
spam y tenemos aquí los likes cada vez
que se realicen los nuevos likes lo que
va a pasar es que vas a tener una nueva
copia aunque aunque esté pero la copia
de salud pero bueno que no sea de salud
creas un nuevo objeto aunque no sea
profunda la copia creas un 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 day
tienes un list of tax por decir algo que
esto es una red obviamente sobre el
listado está que esto es una red de n
buena pone bien y porque tampoco sé de
qué es
puedes tener la falsa sensación que post
day te está recibiendo una lista de tags
que es una copia y que tal no sé quién
es o cuánto y te puedan falsa sensación
porque al final lo que estás haciendo
justamente aquí lo que dices tú una
copia que es que nos profunda sino que
es superficial que no digo que esté bien
que esté mal que no sé qué es odio que
lo tengáis todo esto en cuenta por qué
no está bien que al menos aquí estaba el
interfaz pero aquí pasan cosas que
tienen un coste que tiene unas
implicaciones que hay que controlar y
hay veces que si lo hace de una forma
incontrolada te puede morder vale de
hecho he visto un montón de programas
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 él parece
bastante sencillo creo que se entiende
creo que tiene sentido extraer las dos
propios que son y ya está
ahora que el post-it él 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 tengáis 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 dates
sobre sólo necesitaba el crédito o el
crédito crédito 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 a depender
que no van a utilizar bueno de métodos
que no van a utilizar en este caso ya
veis que no es tanto ese ese estilo aquí
tenemos ejercicios todos los robots
tienen que hacer spin aragón rotar no sé
qué y aquí vemos que cada robot va a
hacer una cosa en concreto los robots
que tiene en brazos rotan los brazos los
que tienen antenas hacen chicle con las
antenas y cada robot solo hace una cosa
solo recibe la información que realmente
necesita en este caso es mucho más
sencillo hacer esto que el context
porque porque el contexto se puede se
puede reventar mucho 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 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 day y ya está ya
tienes este componente ya está probando
en cambio si tienes un context pero ya
tienes que crear aquí un context tendría
que pasar cuál es el valor del contexto
no tendrías que empezar a grape ar
el context puede estar bien pero hay que
utilizarlo con cuidado especialmente ya
os digo que tiene casos hay no digo que
esté siempre en contra pero en esto en
este ejemplo yo no utilizaría un context
porque al final lo complica bastante y
estamos viendo que está tirando se hace
una responsabilidad de leer de un
contexto sería más inyección de
dependencias porque el contexto lo
podemos utilizar para eso para que te dé
cuidado un poco con esto sobre complicar
a veces es venga vamos con la última va
que sólo nos queda uno que la inversión
y la independencia inversión principal
como su nombre indica es que deberíamos
nuestros componentes nuestras clases
funciones deberían depender de
abstracciones y no de implementaciones
concretas por ejemplo antes justamente
hemos podido ver un ejemplo con el
action era una implementación concreta
ya os digo que depende como lo queráis
llevar al final también ria 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 éste
fischer lo que es interesante es que
aquí podemos ver que estamos como
dependiendo de liu swr aquí tendríamos
esta url y estamos dependiendo este
fichero
sabemos como su implementación de la url
italia tenemos una implementación de que
editamos un fichero con una url y esto
lo tenemos aquí o sea esto no tenemos
una cosa que nos esté atrayendo 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
fichero como a ver que estamos el fechas
y que lo vamos a saber no pasaría
absolutamente nada pero lo que podríamos
es separar tanto el juz fets para quitar
el fecha este de aquí en medio o sea lo
que vamos a hacer por ejemplo sería
sacar todo esto en un casto en jugo y
depender pero vamos a crear el caso juli
vamos a llamar los fecha al punto t s x
1 s x no hace falta después empezamos
mal empezamos que unirse sw vamos a
crear es así quita de la interfaz porque
abajo alguno se vuelve aquí un poco
tarumba temos la equis del string y aquí
vamos a utilizar el fechar vale fecha y
que el fecha nos devuelva una promesa
del tipo t estamos creando como la
interfaz que sea como la ex abstracción
y lo mismo vamos a hacer con la
respuesta de esta forma lo que vamos a
conseguir es que él si el día de mañana
en lugar de poner aquí que necesitamos
el pfets que necesitamos esta url en
lugar de depender de esa de dónde vamos
a extraer la información lo que vamos a
hacer es separarlos 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 puedo sacar de otro en
point del local storage de la caché de
donde tú quieras entonces aquí lo que
podemos tener claro es que lo que
necesitamos es que cumpla tanto la
interfaz de liu sets como la de la
respuesta es lo que queremos que cumplan
así que le vamos a poner aquí la
respuesta y que queremos que esto tenga
la data sino que sean de find el error
string y todo lo 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 ya esto porque se queja de
ahora hacemos este set que llamamos you
sets porque es de hacer un set de datos
como le puedo llamar sus data vamos a
llamarle -usted vale en lugar de jazz
fest porque effects parece que es muy de
la implementación y como hemos dicho
justamente queremos evitar la
implementación le vamos a poner le vamos
a pasar tanto una aquí como el fletcher
y esto que estamos haciendo también lo
que estamos evitando es que nuestro
componente sepa que estamos utilizando
sw swr
y si le pasa a un latte por aquí y esto
devuelve la respuesta del tipo te vale
supuesto esto bien creo que si response
y ahora te muestro tener la beta bueno
esto sí que no lo podemos copiar de aquí
más o menos que tenemos teníamos aquí la
dieta el error si está validando
tendríamos aquí en lugar del es wr este
aquí lo que te pasaríamos por un lado
sería lo que queremos recuperar y aquí
tendríamos la aquí vale el aquí el
fetzer y devolveríamos tanto la de eta
como el error como se está validando
vale hemos creado una abstracción lo que
estamos haciendo es utilizar el swr pero
abstraído porque porque ahora en nuestro
ejemplo de bueno si lo he hecho todo
bien porque es un montón de cosas pero
en nuestro ejemplo bueno lo que haríamos
es que podríamos utilizar este fecha y
si lo podríamos inyectar directamente si
no estaríamos pasando en lugar de tener
la implementación aquí lo que estaríamos
es inyectar lo o sea que todo esto lo
podríamos utilizar sin necesidad de
saber cómo vamos a hacer el fich de
datos lo podríamos hacer de un montón de
formas y ahora lo veremos el fecha de
este lo vamos a utilizar todavía pero
vamos a poner aquí el tac del response
que lo vamos a necesitar vamos a pasar
con el de él y de que sea un number y el
title title un estricto response type y
esto le vamos a decir en lugar de
utilizar el swr este vamos a utilizar
nuestros yusef yusfi que no me porque no
me lo lo exportado si a la cita pero
newsday está vale lo importamos ahora
quitamos la importación estadios wr y
ahora que tenemos esto le pulsamos el
responsable son array con él aquí
'todos' y directamente el fecha si
decimos que esto va a devolver primor
response type vale
alguna porque ya necesitamos ya
necesitamos esto y ahora os explicaré
por qué necesitamos la url porque ya no
le pasamos la url ahora os lo aplicó
porque esto vamos a llamarle lugar de
facer vamos a llamarle
setzer from a pie por ejemplo y esto en
realidad ya sabe que a pie es la que
quiere utilizar no la hemos visto antes
es esta de buena manera ópera te admira
perfecto dirige al compañero más
algo es esta url ya esto ya lo tenemos y
aquí tenemos el fecha de forma que hemos
hecho con todo esto es que todavía
algunos gustaba just the law and igual
se ha escapado alguna cosa a la hora del
a qué le llaman fecha que es que tiene
que llamarse fecha perdón perdón que se
te que llamar fecha quería poner aquí el
tema éste de que ahora sí vale que hemos
hecho aquí tenemos como esta abstracción
que le hemos llamado yusif es que al
final tenía que haber sido just data
porque no queremos que se llame fecha
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 en lo que te vuelve loco
porque lo que hemos hecho aquí gracias a
toda esta extracción es que le podemos
inyectar como vamos a hacer el phising
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 un aquí de un string y
le tengo que pasar un fichero que va a
devolver una promesa vale no le
devolvemos ningún parámetro y te que
devolver una promesa donde nos devuelva
el tipo genérico de que es el que le
estamos indicando aquí a esta te si está
te está te sería justamente el
responsbale una rey del response type
que hemos dicho que sería una red de
ideas 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 gráfico el de
de belloch ese de locales tórax y
vas a ver cómo de potente es porque una
vez que tienes esto que esto lo
podríamos separar en lugar de ponerlo
aquí este fecha de aquí en medio lo
podríamos separar a otro archivo y todo
esto este fichero lo tenemos así como
que al final podríamos crear otro fecha
que haga exactamente cumpla la interfaz
no promise response 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 sé qué es
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 del local
esto right punto guetta ítem y tenemos
aquí los posts y esto hacemos entonces
bueno esto sería un poco más complicado
porque aquí tendríamos el ítem y
tendríamos que hacer un reto si tenemos
el aire jason pase a items bueno vamos a
ponerle posts post entonces a tengamos
o sí 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 no sea 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 sólo podríamos inyectar por
aquí le podríamos pasar por propia o por
contexto podríamos utilizar un contexto
esta mente y fíjate lo potente que es
esto fíjate lo potente que sector lo
potente que es esto es que podrías
utilizar
imagínate que tenemos un contexto y
tenemos aquí fetzer o dudus from y para
esto le llamamos flecha news contexto
podríamos hacer así decidir nosotros si
lo queremos recuperar de la api from
local storage de donde sea vale el
llamado bus con text y esto deberá
pasarle el contexto bueno ya me
entendéis vale hoy es global context
para que lo entendáis mejor o
directamente que sea totalmente
transparente que estuviese al fecha y
que sólo desde el punto del global
context desde un solo sitio estemos
cambiando
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 fet si
estamos atacando una app y si vamos al
local storage si sale de las cookies y
le estoy haciendo un mod 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 fechas se no estamos en
jets se los podemos inyectar e indep y
los tres funcionan porque cumplen el
contrato no 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 realmente potente lo
importante y lo interesante de la
inyección de dependencia si esto lo
podéis hacer en un montón de historias
si el facher es un mod para qué sirve el
aquí y aquí está a ver por ejemplo este
fecha este es un modo está aquí en
realidad es un tema más de
swr vale está aquí lo utiliza para el
global state para la caché y este tipo
de cosas o sea al final si tú este todo
y 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 lo interesante
no el hecho de cómo tienes aquí ahora
tres fechas que esto es totalmente claro
acá no tengo
Voir Plus de Vidéos Connexes
5.0 / 5 (0 votes)