DEV Community: Asiel Alonso

SOLID + ReactJS

Asiel Alonso — Sat, 27 Apr 2024 22:28:01 +0000

Los principios SOLID son una parte fundamental del desarrollo de software y son esenciales para crear aplicaciones sólidas y escalables. Fueron introducidos por el ingeniero de software Robert C. Martin, y cada uno de ellos aborda un aspecto específico del diseño de software. En el contexto de ReactJS, aplicar estos principios puede ayudar a crear una arquitectura más cohesiva y modular, lo que puede resultar en un código más fácil de mantener y de modificar.

En este artículo, vamos a explorar los cinco principios SOLID y cómo se aplican específicamente en ReactJS.
Cubriremos ejemplos prácticos de cómo aplicar cada principio y discutiremos por qué son importantes para el desarrollo de aplicaciones de calidad. Ya seas un desarrollador principiante o experimentado, esperamos que este artículo te brinde información útil sobre cómo aplicar los principios SOLID en ReactJS. ¡Comencemos!

Responsabilidad Única (Single Responsibility Principle): Este principio establece que una clase o componente debe tener una única responsabilidad. Esto significa que una clase o componente debe tener una sola razón para cambiar. Al aplicar este principio, se puede mejorar la modularidad de una aplicación y hacer que el código sea más fácil de mantener y de entender. En ReactJS, esto se traduce en asegurarse de que cada componente tenga una función única y no se responsabilice de demasiadas tareas. Por ejemplo, dividir un componente de lista de tareas en componentes más pequeños que se encarguen de mostrar cada tarea individualmente.

Imaginemos que tenemos un componente llamado TodoList que muestra una lista de tareas. El componente TodoList también se encarga de manejar la lógica para agregar nuevas tareas y eliminar tareas existentes. Sin embargo, esto viola el principio de Responsabilidad Única, ya que el componente está manejando múltiples responsabilidades.

Para aplicar el principio de Responsabilidad Única, podemos dividir el componente TodoList en componentes más pequeños y especializados. En lugar de manejar toda la lógica de la lista de tareas en un solo componente, podemos crear componentes más pequeños y especializados para manejar tareas individuales y para agregar y eliminar tareas.

A continuación, te mostraré un ejemplo de código donde hemos aplicado este principio. Hemos dividido el componente TodoList en componentes más pequeños y especializados que se encargan de tareas individuales y la lógica de agregar y eliminar tareas:

function TodoItem({ task, onRemove }) {
  return (
    <li>
      {task}
      <button onClick={onRemove}>Eliminar tarea</button>
    </li>
  );
}

function useTodoList() {
  const [tasks, setTasks] = useState([]);

  function handleAdd(newTask) {
    if (newTask !== "") {
      setTasks([...tasks, newTask]);
    }
  }

  function handleRemove(index) {
    const newTasks = [...tasks];
    newTasks.splice(index, 1);
    setTasks(newTasks);
  }

  return [tasks, handleAdd, handleRemove];
}

function TodoList() {
  const [tasks, handleAdd, handleRemove] = useTodoList();
  const [newTask, setNewTask] = useState("");

  function handleChange(e) {
    setNewTask(e.target.value);
  }

  function handleAddTask() {
    handleAdd(newTask);
    setNewTask("");
  }

  return (
    <div>
      <ul>
        {tasks.map((task, index) => (
          <TodoItem
            key={index}
            task={task}
            onRemove={() => handleRemove(index)}
          />
        ))}
      </ul>
      <div>
        <input value={newTask} onChange={handleChange} />
        <button onClick={handleAddTask}>Agregar tarea</button>
      </div>
    </div>
  );
}

En este ejemplo, hemos creado un hook personalizado useTodoList que se encarga de manejar la lista de tareas y la lógica para agregar y eliminar tareas. Luego, el componente TodoList utiliza el hook para obtener la lista de tareas y los manejadores handleAdd y handleRemove.

El componente TodoList solo se encarga de renderizar la lista de tareas y manejar las interacciones del usuario, lo que cumple con el principio de Responsabilidad Única.

Al separar la lógica del componente TodoList en un hook personalizado, hemos hecho que el código sea aún más modular y fácil de entender y de mantener. Además, hemos mejorado la reutilización del código, ya que ahora podemos usar el hook useTodoList en cualquier componente que necesite manejar una lista de tareas.

Abierto/Cerrado (Open/Closed Principle): Este principio establece que una clase o componente debe estar cerrado a la modificación pero abierto a la extensión. Esto significa que una clase o componente debe ser fácilmente extensible sin tener que modificar su código existente. En ReactJS, esto significa que deberíamos poder agregar nuevas características a nuestro código sin tener que modificar el código existente.

Para aplicar este principio en React, podemos crear componentes reutilizables que sean fácilmente extensibles sin tener que modificar su código original.

Por ejemplo, supongamos que tenemos un componente Button que se utiliza en varios lugares de nuestra aplicación. Ahora necesitamos agregar una nueva funcionalidad a este componente: agregar un icono junto al texto del botón. En lugar de modificar directamente el código del componente Button, podemos crear un nuevo componente que extienda la funcionalidad del Button original.

Aquí te muestro cómo quedaría el código:

import React from "react";

function Button({ children, ...rest }) {
  return <button {...rest}>{children}</button>;
}

function IconButton({ icon, children, ...rest }) {
  return (
    <Button {...rest}>
      <span>{icon}</span>
      {children}
    </Button>
  );
}

export { Button, IconButton };

Sustitución de Liskov (Liskov Substitution Principle): Este principio establece que las clases o componentes derivados deben poder ser utilizados como instancias de sus clases o componentes base sin requerir ninguna modificación adicional. En otras palabras, cualquier instancia de una clase o componente debe poder ser reemplazada por cualquier instancia de su clase o componente base sin que la aplicación falle. En ReactJS, esto significa que los componentes derivados deben poder ser utilizados en lugar de sus componentes base sin causar problemas. Esto se logra manteniendo una estructura coherente y consistente en todos los componentes.

En cuanto al tercer principio, el principio de Sustitución de Liskov, podemos aplicarlo en React cuando utilizamos los patrones de composición y herencia de componentes. En términos generales, podemos decir que un componente hijo debe poder ser utilizado en lugar de su componente padre sin que se produzca un comportamiento incorrecto en la aplicación.

Un ejemplo sencillo de cómo aplicar este principio en React sería el siguiente:

Supongamos que tenemos un componente llamado Button que se utiliza para renderizar botones en nuestra aplicación. Ahora queremos crear un nuevo tipo de botón, llamado SubmitButton, que tenga un estilo diferente y que sea utilizado para enviar formularios.

Podemos crear el nuevo componente SubmitButton heredando de Button y sobrescribiendo el estilo por defecto:

import React from 'react';
import Button from './Button';

function SubmitButton(props) {
  return (
    <Button
      {...props}
      style={{ backgroundColor: 'green', color: 'white' }}
    />
  );
}

export default SubmitButton;

En este ejemplo, el componente SubmitButton hereda de Button y sobrescribe el estilo por defecto para tener un fondo verde y un texto en blanco. Podemos utilizar este nuevo componente SubmitButton en lugar del componente Button en cualquier parte de nuestra aplicación donde necesitemos un botón de envío.

De esta manera, hemos aplicado el principio de Sustitución de Liskov en nuestro código de React, ya que el componente SubmitButton se comporta como un tipo de botón válido en cualquier lugar donde se necesite un botón, y podemos utilizarlo sin preocuparnos de que el comportamiento de nuestra aplicación cambie de manera inesperada.

Segregación de Interfaces (Interface Segregation Principle): Este principio establece que una clase o componente no debe implementar interfaces o comportamientos que no necesite. En ReactJS, esto significa que deberíamos dividir nuestros componentes en piezas más pequeñas y especializadas, en lugar de crear un componente gigante que haga todo. Por ejemplo, podemos separar un componente de formulario en componentes más pequeños que se encarguen de campos de entrada individuales, y un componente que se encargue de enviar el formulario.

Supongamos que tenemos un componente Header que muestra el título de una página y tiene un botón de navegación. Podríamos dividir este componente en dos partes: Title y NavigationButton, que manejan específicamente el título y el botón de navegación respectivamente.

import React from 'react';

interface HeaderProps {
  title: string;
  onNavigation: () => void;
}

function Header({ title, onNavigation }: HeaderProps) {
  return (
    <div>
      <Title title={title} />
      <NavigationButton onNavigation={onNavigation} />
    </div>
  );
}

interface TitleProps {
  title: string;
}

function Title({ title }: TitleProps) {
  return <h1>{title}</h1>;
}

interface NavigationButtonProps {
  onNavigation: () => void;
}

function NavigationButton({ onNavigation }: NavigationButtonProps) {
  return (
    <button onClick={onNavigation}>
      <span>Go to Next Page</span>
    </button>
  );
}

export default Header;

En este ejemplo, Header se ha dividido en dos partes más pequeñas, Title y NavigationButton, que se encargan específicamente de mostrar el título y el botón de navegación, respectivamente. De esta manera, podemos reutilizar estas partes en otros componentes que necesiten mostrar un título o un botón de navegación sin tener que incluir todo el componente Header.

Inversión de Dependencias (Dependency Inversion Principle): Este principio establece que los componentes de nivel superior no deben depender de los componentes de nivel inferior, sino que deben depender de abstracciones. En ReactJS, esto significa que los componentes no deben depender directamente de otros componentes, sino de abstracciones como los props o state. También es importante utilizar patrones de inyección de dependencias para evitar acoplamientos excesivos entre componentes.

Supongamos que tenemos un componente UserList que muestra una lista de usuarios y permite eliminar usuarios haciendo clic en un botón. En lugar de hacer que el componente UserList dependa directamente de una API de usuarios, podemos utilizar una interfaz UserRepository que nos permita acceder a los datos de los usuarios y hacer que la dependencia de UserList sea de la interfaz en lugar de la implementación concreta de la API. De esta manera, podemos cambiar fácilmente la implementación de la interfaz sin tener que cambiar el código del componente UserList.

import React, { useState, useEffect } from 'react';

interface User {
  id: number;
  name: string;
  email: string;
}

interface UserRepository {
  getUsers(): Promise<User[]>;
  deleteUser(id: number): Promise<void>;
}

interface UserListProps {
  userRepository: UserRepository;
}

function UserList({ userRepository }: UserListProps) {
  const [users, setUsers] = useState<User[]>([]);

  useEffect(() => {
    userRepository.getUsers().then((users) => setUsers(users));
  }, [userRepository]);

  function handleDeleteUser(id: number) {
    userRepository.deleteUser(id).then(() => {
      setUsers(users.filter((user) => user.id !== id));
    });
  }

  return (
    <ul>
      {users.map((user) => (
        <li key={user.id}>
          <span>{user.name}</span>
          <button onClick={() => handleDeleteUser(user.id)}>Delete</button>
        </li>
      ))}
    </ul>
  );
}

export default UserList;

En este ejemplo, el componente UserList utiliza la interfaz UserRepository para acceder a los datos de los usuarios y eliminar usuarios. Ahora podemos proporcionar diferentes implementaciones de UserRepository dependiendo de nuestra necesidad, como una API de usuarios o una simulación de datos en memoria, y el componente UserList funcionará sin cambios en su código.

En resumen, la aplicación de los principios SOLID en React ayuda a crear componentes más cohesivos, flexibles y fáciles de mantener. Cada principio SOLID tiene un propósito específico que ayuda a mejorar la calidad del código y a reducir errores. La correcta aplicación depende del contexto del proyecto, pero su uso puede marcar una gran diferencia en la calidad del software.

Flutter y el patrón Provider

Asiel Alonso — Fri, 25 Jun 2021 21:39:06 +0000

Hola mundo!!

Introducción

Tanto si desarrolla una aplicación nativa como una híbrida, el manejo del estado es un problema que debemos enfrentar y tener bajo control. Para administrar el estado global de una aplicación en Flutter existen varias maneras, en este post abordaremos Provider, una biblioteca bastante popular que nos ayudará con este trabajo.

Aplicación de ejemplo

Para ver el funcionamiento de Provider, vamos a realizar una sencilla aplicación que nos ejemplifique.
Esta app muestra una pantalla con un AppBar y su título, en el centro un Text, y dos botones flotantes en la esquina inferior derecha, que tendrán como función cambiar el valor del texto que será mostrado tanto en el título del AppBar como en el Text del body de la app.
Tenemos en cuenta que el valor del texto será administrado de manera global.

Dejo el link del ejercicio para quien desee descargarlo:
https://github.com/hextiandro/flutter_provider_pattern

Manos a la obra

Primeramente instalaremos la biblioteca: provider: ^5.0.0 (En el momento que escribí el post esta era la versión).
La podemos encontrar en: https://pub.dev/packages/provider

Dentro de lib creamos una carpeta llamada widgets y dentro un archivo llamado floating_actions.dart, lib/widgets/floating_actions.dart para crear el widget con los dos botones flotantes:

import 'package:flutter/material.dart';

class FloatingAction extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
 (context);
    return Column(
      mainAxisAlignment: MainAxisAlignment.end,
      children: <Widget>[
        FloatingActionButton(
            child: Icon(Icons.wifi),
            backgroundColor: Colors.orange,
            onPressed: () {}),
        SizedBox(
          height: 10.0,
        ),
        FloatingActionButton(
            child: Icon(Icons.bluetooth),
            backgroundColor: Colors.blue,
            onPressed: () {})
      ],
    );
  }
}

Notemos que el onPressed lo tenemos sin acción, más adelante agregaremos su funcionalidad.

Ahora dentro de lib/widgets crearemos otro archivo llamado body, lib/widgets/body.dart para crear el widget con el texto centralizado.

import 'package:flutter/material.dart';

class Body extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    (context);
    return Center(
      child: Text("",
        style: TextStyle(fontSize: 20),
      ),
    );
  }
}

El texto mostrado por ahora es la cadena vacía.
Crearemos otro widget dentro de lib, llamado home lib/Home.dart:

import 'package:flutter/material.dart';

class Home extends StatelessWidget {
  @override
  Widget build(BuildContext context) {

    return Scaffold(
      appBar: AppBar(
        title: Center(child: Text("")),
      ),
      body: Body(),
      floatingActionButton: FloatingAction(),
    );
  }
}

Aquí estamos renderizando un Scaffold, con un AppBar y su título vacío por el momento, además renderizamos los widgets Body y FloatingAction creados anteriormente.
Nada de Provider aún, solo vamos armando la interfaz gráfica de la app, pasemos a modificar el main.dart.

Nuestro archivo main.dart debería lucir así por el momento:

import 'package:flutter/material.dart';
import 'package:provider_pattern/home.dart';

void main() => runApp(MyApp());

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Provider',
      home: Home()
    );
  }
}

Con esto tenemos todo listo para comenzar a construir nuestro Provider; hagamos lo siguiente:

Dentro de lib creamos otro directorio llamdo provider y dentro un archivo llamado signal_mode.dart, lib/provider/signal_mode.dart

import 'package:flutter/material.dart';

class SignalMode extends ChangeNotifier {
  String _signalMode = 'Wifi mode';

  String get signalMode => _signalMode;

  set signalMode(String mode) {
    this._signalMode = mode;
    notifyListeners();
  }
}

Listo, este es nuestro Provider, es la clase que se ocupa de centralizar el valor de la variable privada _signalMode de tipo String que es el texto que se mostrará tanto en el título del AppBar como en el centro de la pantalla.

Notemos el primer detalle que extiende de ChangeNotifier clase encargada de exponer los eventos de notificación,
veamos que tenemos un método get para obtener el valor de _signalMode, y un método set para modificarlo, dentro de este método vemos la llamada a notifyListeners() que es quien va a notificar a todos los widgets que escuchen a este provider del cambio, para asi actualizar su estado.

Es momento de encapsular aquellos widgets que van a escuhar los cambios.
Como queremos tener el control del estado en todos los niveles de la aplicación lo haremos en el main.
Tenga en cuenta que no necesariamente se debe envolver en el nivel más alto de la aplicación en caso que desees compartir determinado estado para determinado nivel.
Si modificamos nuestro main quedaría de la siguiente forma:

import 'package:flutter/material.dart';
import 'package:provider/provider.dart';
import 'package:provider_pattern/home.dart';
import 'package:provider_pattern/provider/signal_mode.dart';

void main() => runApp(MyApp());

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return ChangeNotifierProvider(
      create: (_) => SignalMode(),
      child: MaterialApp(
          title: 'Provider', 
          home: Home()),
    );
  }
}

De esta manera toda la app está en condiciones de escuchar los cambios de la clase SignalMode

Desde ahora ya podemos integrar los distintos widgets de nuestra app. Modifiquemos la clase FloatingAction para conectarla con nuestro Provider quedando de la siguiente forma:

import 'package:flutter/material.dart';
import 'package:provider/provider.dart';
import 'package:provider_pattern/provider/signal_mode.dart';

class FloatingAction extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    final signal = Provider.of<SignalMode>(context);

    return Column(
      mainAxisAlignment: MainAxisAlignment.end,
      children: <Widget>[
        FloatingActionButton(
            child: Icon(Icons.wifi),
            backgroundColor: Colors.orange,
            onPressed: () {
              signal.signalMode = "Wifi mode";
            }),
        SizedBox(
          height: 10.0,
        ),
        FloatingActionButton(
            child: Icon(Icons.bluetooth),
            backgroundColor: Colors.blue,
            onPressed: () {
              signal.signalMode = "Bluetooth mode";
            })
      ],
    );
  }
}

Notemos aquí en la siguiente línea:

  final signal = Provider.of<SignalMode>(context);

de esta manera obtenemos una instancia de nuestro Provider especificando que es de tipo SignalMode.

El otro punto a notar aquí es en el onPressed de los botones, cada uno hace una llamada modificando el valor de signalMode

onPressed: () {
 signal.signalMode = "Wifi mode";
})

onPressed: () {
 signal.signalMode = "Bluetooth mode";
})

De esta manera podemos modifcar el estado global, ahora solamente debemos mostrar los valores, veamos como:

import 'package:flutter/material.dart';
import 'package:provider_pattern/provider/signal_mode.dart';
import 'package:provider_pattern/widgets/body.dart';
import 'package:provider_pattern/widgets/floating_actions.dart';
import 'package:provider/provider.dart';

class Home extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    final signal = Provider.of<SignalMode>(context);

    return Scaffold(
      appBar: AppBar(
        title: Center(child: Text(signal.signalMode)),
      ),
      body: Body(),
      floatingActionButton: FloatingAction(),
    );
  }
}

En la clase Home igualmente obtenemos la instancia del Provider y leemos la propiedad signalHome.

De la misma forma lo hacemos en la clase Body:

import 'package:flutter/material.dart';
import 'package:provider/provider.dart';
import 'package:provider_pattern/provider/signal_mode.dart';

class Body extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    final signal = Provider.of<SignalMode>(context);
    return Center(
      child: Text(
        signal.signalMode,
        style: TextStyle(fontSize: 20),
      ),
    );
  }
}

Ya, es todo!!

Hemos finalizado nuestro ejemplo, pero les dejaré una última consideración para la utilización de múltiples providers tendríamos que modificar nuevamente nuestro main de la siguiente forma:

void main() => runApp(AppState());

class AppState extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MultiProvider(
      providers: [
       ChangeNotifierProvider(create: (_) => SignalMode())
       ],
      child: MyApp(),
    );
  }
}

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
     title: 'Provider', 
     home: Home()
    );
  }
}

Percatarse aquí como MultiPorvider admite un arreglo de Provider:

providers: [
 ChangeNotifierProvider(create: (_) => SignalMode())
],

Conclusiones

Hasta aquí este post, espero haberme explicado bien y de alguna manera haberle sido útil, nos vemos en la próxima!!

Chao Mundo!!