This is a new React Native project, bootstrapped using @react-native-community/cli.
Note: Make sure you have completed the React Native - Environment Setup instructions till "Creating a new application" step, before proceeding.
First, you will need to start Metro, the JavaScript bundler that ships with React Native.
To start Metro, run the following command from the root of your React Native project:
# using npm
npm start
# OR using Yarn
yarn startLet Metro Bundler run in its own terminal. Open a new terminal from the root of your React Native project. Run the following command to start your Android or iOS app:
# using npm
npm run android
# OR using Yarn
yarn android# using npm
npm run ios
# OR using Yarn
yarn iosIf everything is set up correctly, you should see your new app running in your Android Emulator or iOS Simulator shortly provided you have set up your emulator/simulator correctly.
This is one way to run your app — you can also run it directly from within Android Studio and Xcode respectively.
Now that you have successfully run the app, let's modify it.
-
Open
App.tsxin your text editor of choice and edit some lines. -
For Android: Press the R key twice or select "Reload" from the Developer Menu (Ctrl + M (on Window and Linux) or Cmd ⌘ + M (on macOS)) to see your changes!
For iOS: Hit Cmd ⌘ + R in your iOS Simulator to reload the app and see your changes!
You've successfully run and modified your React Native App. 🥳
- If you want to add this new React Native code to an existing application, check out the Integration guide.
- If you're curious to learn more about React Native, check out the Introduction to React Native.
If you can't get this to work, see the Troubleshooting page.
To learn more about React Native, take a look at the following resources:
- React Native Website - learn more about React Native.
- Getting Started - an overview of React Native and how setup your environment.
- Learn the Basics - a guided tour of the React Native basics.
- Blog - read the latest official React Native Blog posts.
@facebook/react-native- the Open Source; GitHub repository for React Native.
-
Mantenibilidad: Una arquitectura bien estructurada facilita la mantenibilidad del software a lo largo del tiempo. Permite a los desarrolladores realizar cambios y mejoras en el sistema de manera más sencilla y con menos riesgo de introducir errores.
-
Separación de preocupaciones: Una buena arquitectura divide el sistema en capas y componentes con responsabilidades específicas. Esto facilita la comprensión del código y permite a los desarrolladores enfocarse en aspectos particulares del sistema sin tener que preocuparse por todo al mismo tiempo.
-
Flexibilidad: Al desacoplar las diferentes partes del sistema, una arquitectura sólida permite reemplazar o actualizar componentes de manera más fácil. Por ejemplo, si un componente de la infraestructura necesita ser reemplazado por una tecnología diferente, el impacto en el resto del sistema será mínimo.
-
Escalabilidad: Una arquitectura bien definida facilita la escalabilidad del sistema, permitiendo agregar nuevas funcionalidades o mejorar el rendimiento sin tener que rediseñar
-
Mantener el costo de desarrollo constante: Una arquitectura efectiva permite que el costo de desarrollo se mantenga constante a lo largo del tiempo, evitando que aumente exponencialmente a medida que el proyecto crece y evoluciona.
-
Facilitar la incorporación de nuevos miembros al equipo: Una buena arquitectura hace que sea más fácil para los nuevos miembros del equipo comprender y contribuir al proyecto, ya que proporciona una estructura clara y bien organizada.
-
Desacoplar componentes: Desacoplar componentes es clave para lograr una arquitectura flexible y mantenible. Esto permite reemplazar o modificar partes del sistema sin afectar al resto, lo que facilita la adaptación a cambios en los requisitos o las tecnologías.
-
Separación de preocupaciones: La arquitectura debe dividir el sistema en capas y componentes con responsabilidades específicas. Esto facilita la comprensión del código y permite a los desarrolladores enfocarse en aspectos particulares del sistema sin tener que preocuparse por todo al mismo tiempo.
-
Permitir la evolución del sistema: Una buena arquitectura de software permite que el sistema evolucione y se adapte a nuevos requisitos, cambios en la tecnología o en el entorno
La Clean Architecture es un enfoque de diseño de software propuesto por Robert C. Martin (también conocido como Uncle Bob) que tiene como objetivo crear sistemas de software más mantenibles, flexibles y escalables. La idea principal detrás de la Clean Architecture es separar las preocupaciones del software en capas y componentes independientes, permitiendo un mayor desacoplamiento y modularidad.
La Clean Architecture se basa en varios principios de diseño, como la inversión de dependencias, el principio de responsabilidad única y el principio de segregación de interfaces. Estos principios ayudan a guiar la organización del código y las relaciones entre los diferentes componentes del sistema.
- Principio de responsabilidad única (SRP): Cada módulo, clase o función debe tener una única responsabilidad.
- Principio Abierto/Cerrado (OCP): Los módulos, clases o funciones deben ser abiertos para la extensión, pero cerrados para la modificación.
- Principio de sustitución de Liskov (LSP): Los objetos de una clase derivada deben poder sustituir a los objetos de la clase base sin afectar la corrección del programa.
- Principio de segregación de interfaces (ISP): Los clientes no deben verse obligados a depender de interfaces que no utilizan.
- Principio de inversión de dependencias (DIP): Los módulos de alto nivel no deben depender de los módulos de bajo nivel. Ambos deben depender de abstracciones.
La Clean Architecture se compone de varias capas concéntricas, cada una con responsabilidades específicas:
-
Capa de dominio (Domain): Esta capa contiene la lógica de negocio principal y las reglas del dominio. Incluye entidades, objetos de valor y lógica de dominio. Las entidades son objetos que tienen una identidad única y representan conceptos clave del dominio del problema. Los objetos de valor son inmutables y se definen por sus atributos en lugar de una identidad única.
-
Capa de aplicación (Application): Esta capa se encarga de coordinar y orquestar la lógica de negocio en casos de uso específicos. Los casos de uso representan acciones o flujos de trabajo que los usuarios pueden realizar en la aplicación. La capa de aplicación interactúa con la capa de dominio y la capa de infraestructura, pero no contiene lógica de negocio específica.
-
Capa de infraestructura (Infrastructure): Esta capa proporciona implementaciones concretas de interfaces definidas en las capas de dominio y aplicación. Incluye la comunicación con sistemas externos, como APIs, Storage, Cámara, etc. La capa de infraestructura es responsable de la persistencia de datos, la gestión de conexiones y la implementación de detalles técnicos.
-
Capa de presentación (Presentation): Esta capa es responsable de la interacción con el usuario y la representación visual de la aplicación. Incluye componentes de interfaz de usuario, como pantallas y componentes, así como la lógica de presentación, como la validación de formularios y la manipulación del estado de la interfaz de usuario.
Para los proyectos del BHD, vamos a tomar el enfoque de una arquitectura hexagonal (que está dentro de las Clean
Architectures) acompañada de vertical slicing.
Es un enfoque para organizar y estructurar el código de una aplicación en función de características o módulos, en lugar de agruparlos por capas técnicas. Este enfoque tiene como objetivo facilitar la colaboración entre equipos y hacer que el código sea más fácil de mantener y navegar.
Al aplicar el Vertical Slicing, cada característica o módulo tiene todos los archivos relacionados agrupados en una carpeta. Esto incluye componentes, servicios, modelos y archivos de infraestructura relacionados con esa característica específica. Como resultado, los equipos pueden trabajar en características individuales sin interferir con el trabajo de otros equipos y mantener una estructura de proyecto más clara y coherente.
└── app
├── App.tsx
├── assets
├── core
│ ├── Infrastructure
│ │ ├── Contracts
│ │ │ ├── Http.interface.ts
│ │ │ ├── Methods.ts
│ │ │ └── Storage.interface.ts
│ │ ├── Http
│ │ │ ├── Http.implementation.ts
│ │ │ └── index.tsx
│ │ └── Storage
│ │ └── async
│ │ ├── AsyncStorage.implementation.ts
│ │ └── index.tsx
│ └── Modules
│ └── CreditCards
│ ├── Applications
│ │ └── UseCases
│ │ ├── CreditCardUseCase.ts
│ │ └── index.tsx
│ └── Domain
│ ├── Dtos
│ │ └── CreditCard.dto.ts
│ ├── Entities
│ │ └── CreditCard.ts
│ ├── Mappers
│ │ └── DtoToCreditCard.ts
│ └── Repository
│ └── CreditCard.repository.ts
├── screens
│ ├── Auth
│ │ ├── Login
│ │ │ ├── Login.hook.ts
│ │ │ ├── Login.presenter.tsx
│ │ │ └── Login.style.ts
│ │ ├── RecoverPassword
│ │ │ ├── RecoverPassword.hook.ts
│ │ │ ├── RecoverPassword.presenter.tsx
│ │ │ └── RecoverPassword.style.ts
│ │ ├── components
│ │ │ ├── FormLogin
│ │ │ │ ├── FormLogin.styles.ts
│ │ │ │ └── index.tsx
│ │ │ └── FormRecoverPassword
│ │ │ ├── FormRecoverPassword.styles.ts
│ │ │ └── index.tsx
│ │ ├── hooks
│ │ └── index.tsx
│ └── Dashboard
├── shared
│ ├── Components
│ │ └── Button
│ │ ├── Button.styles.ts
│ │ └── index.tsx
│ ├── Enums
│ │ ├── Storage.enum.ts
│ │ └── index.ts
│ └── Helpers
│ └── ZodValidator.ts
└── tests-mocks