Principios SOLID en React.js (Buenas prácticas) con ejemplos prácticos

Summary

This 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

00:00

🔵 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.

05:01

🟢 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.

10:03

🟠 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.

15:06

🟣 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.

20:07

🔴 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.

25:08

🟢 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.

30:09

🟠 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.

35:09

🟣 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.

40:11

🔴 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.

45:11

🟢 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.

50:13

🟠 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.

55:13

🟣 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.

Keywords

💡Single Responsibility Principle

The Single Responsibility Principle states that a class or component should have only one reason to change, or in other words, should have a single responsibility. In the context of the video, this principle is applied to React components, suggesting that each component should have a single, well-defined responsibility. The video illustrates this by refactoring an example component that initially had multiple responsibilities, such as managing state, fetching data, and rendering, into separate hooks or smaller components, each with a single responsibility.

💡Open/Closed Principle

The Open/Closed Principle states that software entities (classes, modules, components, etc.) should be open for extension but closed for modification. In the context of React, this principle is demonstrated by creating a `Title` component that can be extended by passing different children components (e.g., `TitleWithLink`, `TitleWithButton`) instead of modifying the original `Title` component to handle different cases. By following this principle, new functionality can be added without modifying the existing code, making it more maintainable and less prone to introducing bugs.

💡Liskov Substitution Principle

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. In the context of React, this principle is illustrated with an example of a `Button` component that receives props like `size` and `color`. The video demonstrates how violating this principle can lead to issues where a subcomponent (e.g., `RedButton`) breaks the expected behavior when substituted for the base component (`Button`). By adhering to this principle, components can be more easily extended or replaced without breaking existing functionality.

💡Interface Segregation Principle

The Interface Segregation Principle states that clients should not be forced to depend on interfaces they do not use. In the context of React, this principle is illustrated by an example where a component receives unnecessary props or data that it does not need. The video demonstrates how refactoring the component to receive only the required props or data can make the component more maintainable, testable, and easier to understand. By following this principle, components become more modular and decoupled, reducing the risk of unintended side effects when changes are made.

💡Dependency Inversion Principle

The Dependency Inversion Principle states that high-level modules should not depend on low-level modules; both should depend on abstractions. In the context of React, this principle is demonstrated by creating an abstraction layer for fetching data, allowing components to depend on this abstraction instead of depending directly on a specific implementation (e.g., a specific API or data source). The video illustrates how this abstraction can be injected or swapped out, enabling components to remain agnostic to the underlying data fetching implementation, making the codebase more flexible and maintainable.

💡Refactoring

Refactoring refers to the process of restructuring existing code without changing its external behavior. In the context of the video, refactoring is a recurring theme, as the instructor demonstrates how to apply the SOLID principles by refactoring example React components. Refactoring is presented as a way to improve code quality, maintainability, and adherence to best practices, while preserving the original functionality of the components.

💡React Components

React components are the building blocks of React applications. In the video, React components are used as the primary context for illustrating and applying the SOLID principles. The instructor demonstrates how components can be refactored to adhere to principles like the Single Responsibility Principle, Open/Closed Principle, and Interface Segregation Principle, leading to more modular, maintainable, and extensible components.

💡Hooks

Hooks are functions introduced in React 16.8 that allow developers to use state and other React features without writing a class component. In the video, hooks are presented as a way to separate concerns and responsibilities within components, adhering to the Single Responsibility Principle. The instructor demonstrates how custom hooks can be created to encapsulate specific behaviors or functionality, making components more modular and easier to maintain.

💡Abstraction

Abstraction is the process of hiding complex implementation details and exposing only the essential features or behavior of a system or component. In the context of the video, abstraction is demonstrated when creating an abstraction layer for fetching data, allowing components to depend on this abstraction instead of a specific implementation. This adherence to the Dependency Inversion Principle promotes code flexibility, maintainability, and the ability to swap out implementations without affecting dependent components.

💡Modularity

Modularity refers to the principle of dividing a software system into smaller, independent, and interchangeable modules or components. Throughout the video, the instructor emphasizes the importance of modularity in React applications, as it aligns with the SOLID principles and promotes code reusability, maintainability, and testability. By refactoring components into smaller, more focused modules with single responsibilities, the codebase becomes more modular and easier to reason about.

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