Latte and Code

Javascript y Eventos. Todo lo que necesitas saber

Gerardo — Tue, 28 Mar 2023 08:37:16 GMT

En este artículo quiero presentar una guía detallada de cómo funcionan los eventos en Javascript ya que creo que, pese a ser una de las características de Javascript con la que más acostumbrados a trabajar estamos, su comportamiento y la forma en que tienen lugar y son procesados es muchas veces algo por lo que pasamos por alto.

Así que, ¡vamos a ello!

¿Qué son los eventos?

Empecemos por lo fundamental. Los eventos os objetos que implementan la interfaz Event definida dentro del estándar del DOM.

Este tipo de objetos son enviados tanto por el user agent (a menudo el navegador) o por la propia aplicación y son recibidos y procesados por los Event Listeners. Su principal función es permitir responder a las interacciones de los usuarios o cambios en la red.

Pese a haber muchos tipos de eventos (los cuales podéis consultar en la web de MDN) en este artículo me centraré principalmente en los referidos al DOM, ya que son con los que probablemente estemos más familiarizados y los que más usemos en el día a día.

¿Cómo se propagan los eventos?

Para entender la forma en que se propagan los eventos atenderemos al siguiente código:

que presentará la siguiente estructura para el DOM:

Cuando trabajamos con eventos, es posible añadir Event Listeners a cada uno de estos elementos mediante Javascript gracias a que todos ellos implementan la interfaz EventTarget . Para ello, basta con seleccionar el elemento (por ejemplo mediante querySelector ) y a continuación emplear sobre dicho elemento el método addEventListener(type, callback, options) para añadir el listener:

type representa el nombre del evento que queremos escuchar,
callback la función que será invocada cuando se reciba el evento,
options es un objeto para modificar el comportamiento por defecto del listener.

Por ejemplo, podemos añadir el evento click al botón con id dataSender para imprimir por consola el mensaje que queramos:

const button = document.querySelector('#dataSender');
button.addEventListener('click', function(event) { 
  console.log('button clicked');
});

De este modo, cada vez que pulsemos el botón obtendremos en la consola el texto button clicked . ¿Fácil verdad?

La forma en que el evento se propaga cuando realizamos un click consta de 3 fases:

Capture, donde el árbol del DOM es recorrido hacia abajo hasta alcanzar un EventTarget , en nuestro caso el botón dataSender

On Target, fase en la cual se alcanza el Event target
Bubble, en el cual el evento “sube hacia arriba” como si de una burbuja se tratara.

Si por ejemplo, en vez de un solo listener adjuntado al botón dataSender añadiésemos también a los elementos body y container :

const body = document.querySelector('body');
const container = document.querySelector('#container'); 
const button = document.querySelector('#dataSender');body.addEventListener('click', function(event) { 
  console.log('body clicked');
});
container.addEventListener('click', function(event) { 
  console.log('container clicked');
});
button.addEventListener('click', function(event) { 
  console.log('button clicked');
});

El proceso que seguiría el evento sería el siguiente:

De modo que obtendríamos en consola lo siguiente:

"button clicked""container clicked""body clicked"

Es decir, primero el listener del botón dataSender , posteriormente el de container y finalmente el del body , de ahí el nombre de propagación en burbuja.

Por defecto, cuando añadimos un eventListener a un elemento, éste es llamado durante la fase de bubble. Si queremos realizar alguna acción durante las dos fases anteriores deberemos declararlo del siguiente modo:

button.addEventListener('click', function(event) { 
  console.log('button clicked (one)');
}, true);

Por supuesto es posible añadir múltiples eventos (aunque sean del mismo tipo) a un mismo elemento:

const button = document.querySelector('#dataSender');
button.addEventListener('click', function(event) { 
  console.log('button clicked (one)');
});
button.addEventListener('click', function(event) { 
  console.log('button clicked (two)');
});

En este caso los listeners son invocados en el orden en que fueron declarados.

También podemos eliminar un listener si ya no lo necesitamos:

const button = document.querySelector('#dataSender');
function onButtonClicked(event) { 
  console.log('button clicked (one)');
}
button.addEventListener('click', onButtonClicked);
button.removeEventListener('click', onButtonClicked);

Suscríbete ahora

¿Y cómo detenemos la propagación?

En el caso de que queramos detener la propagación del evento en algún punto determinado del DOM podremos emplear los métodos event.stopPropagation() o event.stopImmediatePropagation() . Vamos a ver sus diferencias.

stopPropagation()

El método stopPropagation() lo podemos invocar sobre un objeto evento. Para ver su funcionamiento recurriremos al siguiente ejemplo:

const body = document.querySelector('body');
const container = document.querySelector('#container'); 
const button = document.querySelector('#dataSender');body.addEventListener('click', function(event) { 
  console.log('body clicked');
});
container.addEventListener('click', function(event) { 
  console.log('container clicked');
});
button.addEventListener('click', function(event) { 
  event.stopPropagation();
  console.log('button clicked');
});
button.addEventListener('click', function(event) { 
  console.log('button clicked (two)');
});

En el primer listener del botón dataSender estamos deteniendo la propagación mediante la instrucción event.stopPropagation lo cual provoca el evento no “suba en burbuja” hacia los elementos superiores:

Sin embargo, el segundo listener que tenemos asociado al botón sí se ejecuta.

stopImmediatePropagation()

Sin embargo, si queremos prevenir que se ejecuten otros listener asociados al botón podremos emplear el método stopImmediatePropagation de modo que:

const body = document.querySelector('body');
const container = document.querySelector('#container'); 
const button = document.querySelector('#dataSender');body.addEventListener('click', function(event) { 
  console.log('body clicked');
});
container.addEventListener('click', function(event) { 
  console.log('container clicked');
});
button.addEventListener('click', function(event) { 
  event.stopImmediatePropagation();
  console.log('button clicked');
});
button.addEventListener('click', function(event) { 
  console.log('button clicked (two)');
});

En este caso, el segundo listener ya no recibe el evento:

Oye… ¿Y el famoso preventDefault()?

Cuando trabajamos con eventos en Javascript es muy común ver el siguiente código:

function(event) {
  event.preventDefault();
  event.stopPropagation();
}

El método preventDefault lo que hace es decir al navegador que no ejecute el comportamiento por defecto del evento recibido.

Esto es muy común cuando empleamos por ejemplo etiquetas como botones en vez de como enlaces (ejem) de modo que si tenemos el siguiente HTML:

Link

y añadimos el siguiente código Javascript:

const link = document.querySelector('#myLink');
link.addEventListener('click', function(event) {
  event.preventDefault();
  // do something cool
});

Lo que estaremos haciendo es prevenir que el navegador vaya hacia la url del enlace cuando el usuario haga click sobre él.

Otro caso de uso habitual es para controlar el envío de formularios al pulsar sobre el botón de enviar (por ejemplo, para enviarlos por medio de una llamada AJAX).

Lanzando eventos manualmente

Si bien estamos acostumbrados a que sea el navegador quien se encargue de lanzar los eventos según las interacciones de los usuarios, también es posible crear y lanzar eventos manualmente.

Esto es tan sencillo como crear un nuevo objeto de la clase CustomEvent y lanzarlo mediante la función dispatchEvent . El constructor de la clase CustomEvent presenta la siguiente signature:

event = new CustomEvent(type [, eventInitDict])

El segundo argumento nos permite rellenar la propiedad detail para establecer nuestros propios datos:

const clickedData = document.querySelector('#clickedData');
const anEvent = new CustomEvent('dataSent', {
  detail: { foo: 'bar' },
});
clickedData.dispatchEvent(anEvent);

Cuando lanzamos un evento de esta manera el recorrido es similar al que sucede cuando se lanza desde el navegador salvo por el hecho de que no hay propagación en burbuja, pues por defecto todos los eventos creados mediante la instrucción new CustomEvent tienen puesta la propiedad bubbles a false :

const body = document.querySelector('body');
const container = document.querySelector('#container'); 
const button = document.querySelector('#dataSender');
const clickedData = document.querySelector('#clickedData');body.addEventListener('clickedData', function(event) { 
  console.log('body listener');
});
container.addEventListener('clickedData', function(event) { 
  console.log('container listener');
});
button.addEventListener('clickedData', function(event) {
  console.log('button listener');
});const anEvent = new CustomEvent('clickedData', {
  detail: { foo: 'bar' },
});
clickedData.dispatchEvent(anEvent);

El recorrido del evento es el siguiente:

En el caso de que queramos que el evento se propague deberemos crearlo del siguiente modo:

const anEvent = new CustomEvent('clickedData', {
  bubbles: true,
  detail: { foo: 'bar' },
});

Photo by Mathieu Turle on Unsplash

🙏🏻 Gracias a Garaje de Ideas

Los amigos de Garaje de ideas patrocinan Latte and Code y buscan talento: http://bit.ly/garaje-tech-talento

Conclusiones

Como habéis podido ver detrás de la instrucción addEventListener hay bastante lógica detrás que conviene saber por si en algún momento necesitamos crear nuestros propios eventos o profundizar en su uso para determinados caso.

Además, la posibilidad que tenemos de crear nuestros propios eventos nos permite conectar los distintos componentes de nuestra aplicación y pasar información entre ellos de una forma distinta a la propuesta por otros patrones.

Capítulo 4. Lo que aprendí de DDD. Servicios

Gerardo — Tue, 14 Feb 2023 09:26:44 GMT

Photo by Moritz Mentges on Unsplash

En el capítulo anterior sobre DDD os hablé de las entidades, el elemento fundamental de cualquier aplicación y que bajo la filosofía DDD cobra especial importancia, pues son ellas las que encapsularán nuestra lógica de negocio.

Sin embargo, la forma en que interactúan nuestras entidades y la invocación de sus métodos debe ser orquestada por alguna unidad “lógica” superior. Es aquí donde entran los servicios, tema central de este nuevo capítulo sobre Domain Driven Design.

Tipos de servicio en DDD

En DDD podemos categorizar los servicios en 3 tipos según el alcance y la funcionalidad que encapsulen:

Los servicios de dominio representan aquellas operaciones que pertenecen a nuestro dominio (y que por tanto, sería recomendable que se realizasen dentro de nuestras entidades) pero que por razones técnicas o de otro calado han de extraerse fuera de ellas.
Los servicios de infraestructura. Estos son los servicios que más “lejos” se encuentran de nuestro dominio, es decir, de la lógica que da sentido a nuestra aplicación. Ejemplos de servicios de infraestructura son el servicio de logs o el encargado de enviar emails.
Los servicios de aplicación. Son aquellos encargados de orquestar lo que sucede para lograr que nuestras operaciones sobre el dominio tengan el resultado esperado. Habitualmente también se encargan de transformar a entidades y “value objects” los valores recibidos desde fuera (por ejemplo, un servicio recibirá un float y lo convertirá en un “value object” Money ).

Profundicemos un poco más en cada uno de ellos.

Servicios de dominio

Los servicios de dominio representan operaciones de nuestro dominio que no almacenan estado y que por distintos motivos no pueden ser encapsuladas dentro de nuestras entidades.

Por ejemplo, la creación de un usuario con una contraseña encriptada es probable que necesite una librería externa para cifrar la cadena de texto que representa dicha contraseña. Esto nos impide depositar dicha lógica en nuestra entidad User :

class User 
{ 
  ...  
  public function register(string $email, string $plainPassword)
  {
    // Necesito codificar aquí la contraseña. 
    // ¿Cómo accedo al servicio?
  }
}

En este tipo de casos tiene sentido crear un servicio de dominio que pueda trabajar con esos servicios externos para realizar estas operaciones:

class RegisterUser
{
  
    public function __construct(
        private PasswordEncoderInterface $passwordEncoder
    ) {}  

    public function __invoke(
        string $email, 
        string $plainPassword
    ): User {
        $password = $this->passwordEncoder->encode($plainPassword);
        $user = new User($email, $password);
        return $user;
  }
}

¿Cómo reciben los servicios de dominio sus dependencias?

Si te fijas en el ejemplo anterior, el constructor del servicio RegisterUser recibe un objeto que implementa la interfaz PasswordEncoderInterface. Esto establece un contrato con el exterior para que, sea como sea la forma en que se construya este servicio, reciba un objeto $passwordEncoder sobre el que poder invocar el método encode para codificar la contraseña.

En DDD es habitual recurrir a dos conceptos para construir nuestros servicios:

La inyección de dependencias, es decir, el patrón por el cual se dispone de un contenedor de dependencias encargado de construir los servicios en base a las dependencias que declaren en su constructor. Este contenedor instanciará cada servicio pasándole todas las dependencias que necesite de forma invisible para nosotros.

La inversión de dependencias. Extraída de los principios SOLID, la inversión de dependencias establece lo siguiente:

Las clases de alto nivel no deberían depender de las clases de bajo nivel. Ambas deberían depender de las abstracciones.

Las abstracciones no deberían depender de los detalles. Los detalles deberían depender de las abstracciones.

En el caso de DDD, al aplicar la inversión de dependencias definiremos esos contratos en nuestros servicios de dominio mediante la declaración de interfaces abstractas en sus constructores y serán los servicios de infraestructura quienes proporcionarán la implementación concreta de esos contratos.

❗️ Entidades de dominio anémicas

Que exista la posibilidad de declarar servicios de dominio que complementen a nuestras entidades no significa extraer toda la lógica a ellas.

Recuerda, son nuestras entidades las que idealmente deben encapsular la lógica de negocio. Extraer de ellas dicha lógica para convertirlas en meros contenedores de propiedades es considerado un anti-patrón y deberíamos evitar caer en él. Si trabajamos bajo un enfoque orientado a objetos, queremos que sean los objetos los que encapsulen su propia lógica de comportamiento.

Además, cuanta más lógica extraigamos a los servicios de dominio, más posibilidades existen de que nuestras entidades acaben en estados inválidos.

Por ejemplo, supongamos que cambiar el estado de un artículo a “publicado” supone también actualizar su fecha de actualización. Si esta lógica está extraída a un servicio de dominio llamado PublishArticle, realizar la siguiente operación en cualquier otro sitio de nuestra aplicación:

$article->setStatus('PUBLISHED');

supondrá que no se actualice su fecha de modificación. Por tanto, estaremos obligados a acordarnos de invocar el servicio de dominio asociado para realizar la operación, o a conocer los detalles concretos de las entidades:

$article->setStatus('PUBLISHED');
$article->setUpdatedAt(new DateTime());

Lo correcto es dejar que nuestras entidades gestiones su propio comportamiento:

class Article
{
  
  ...  public function publish(): self
  {
    $this->status = 'PUBLISHED';
    $this->updatedAt = new DateTime();
    return $this;
  }
}

Suscríbete ahora

Servicios de infraestructura

Los servicios de infraestructura son aquellos servicios que implementan aspectos concretos de determinada funcionalidad definida en nuestro dominio.

Por ejemplo, si nuestro dominio define que las contraseñas deben ir encriptadas, los servicios de dominio y aplicación expondrán una interfaz / contrato que será implementada por los servicios de infraestructura, tal y como vimos en el caso del servicio RegisterUser .

Lo mismo sucede con la base de datos. Si nuestro dominio establece que las entidades deben ser almacenadas en una base de datos, serán los servicios de infraestructura los encargados de definir la implementación concreta del mecanismo de persistencia. Dicho más claro, a nuestro dominio le debería dar igual que usemos MySQL o Postgres, un ORM u otro. Esos detalles son específicos de la capa de infraestructura.

// Dominio
interface ArticleRepository
{
    public function save(Article $article): void;
}

// Infraestructura

class DoctrineArticleRepository implements ArticleRepository
{
    public function save(Article $article): void
    { 
        $this->em->persist($article);
        $this->em->flush();
    }
}

Servicios de aplicación

Los servicios de aplicación representan el pegamento entre las dos capas que ya he mencionado: dominio e infraestructura.

Los servicios de aplicación son los encargados de conectar el mundo exterior con la lógica de nuestro dominio, es decir, con los casos de uso definidos para nuestra aplicación.

Personalmente me gusta ver los servicios de aplicación como la sala de mandos de nuestra aplicación:

Reciben unos argumentos de entrada que todavía no tienen ningún valor semántico.
Transforman dichos valores en entidades y “value objects” con significado real para nuestro dominio.
Encadenan llamadas a otros servicios o métodos de entidades para procesar el caso de uso.
Publican eventos de dominio para que otros servicios puedan reaccionar a la operación que se acaba de realizar.

class CreateUser
{  

    public function __construct(
        private UserRepository $userRepository,
        private EventDispatcherInterface $eventDispatcher
    ) {}

    public function __invoke(
        string $name,
        string $email,
        string $locale
    ): void {
        $user = User::create(
            UserId::generate(),
            Name::create($name),
            Email::create($email)
        );
        $this->userRepository->save($user);
        foreach ($user->pullDomainEvents() as $event) {
            $this->eventDispatcher->dispatch($event);
        }
    }
}

Además, los servicios de aplicación son los encargados de invocar las comprobaciones de seguridad definidas por nuestro negocio, por ejemplo, la regla que establece que un artículo sólo puede ser eliminado por su creador.

Finalmente, los servicios de aplicación no deberían devolver entidades de nuestro dominio, sino que es recomendable encapsular su valor de retorno en DTO’s (data transfer objects) para evitar que las entidades puedan ser modificadas por las capas superiores.

🙏🏻 Gracias a Garaje de Ideas

Los amigos de Garaje de ideas patrocinan Latte and Code y buscan talento: http://bit.ly/garaje-tech-talento

Conclusión

Los servicios representan una pieza fundamental de cualquier aplicación. Cuando adoptamos un enfoque DDD es muy importante aprender a identificar a la capa a la que pertenecen y evitar caer en antipatrones como el ya mencionado “entidades anémicas”.

A medida que vayamos ganando soltura con estas ideas veremos como nuestras aplicaciones se sienten mucho más ordenadas, desacopladas y testeables.

Suscríbete ahora

React Portals. Construyendo agujeros de gusano

Gerardo — Thu, 02 Feb 2023 09:49:46 GMT

Photo by Ivan Diaz on Unsplash

Hace poco estuve trabajando en una aplicación que empleaba los React Portals y me pareció una característica muy interesante. Los portales nos permiten de forma nativa renderear componentes en un nodo del DOM que exista fuera de la jerarquía del componente padre.

Los React Portals son una API que nos permite renderear componentes “saltándonos” la jerarquía del DOM

Según la documentación oficial los portales resultan útiles cuando un componente padre tiene una propiedad del estilo z-index o overflow: hidden pero su hijo tiene que “romper” el contenedor, como por ejemplo en el caso de los tooltips, ventanas modales o menús flotantes.

Como de primeras todo esto puede sonar muy abstracto, voy a mostraros dos casos de uso para que podáis ver su funcionamiento.

¡Vamos a ello!

Creando una ventana modal con React Portals

El primer caso es bastante sencillo y es, seguramente, el más típico para explicar los React Portals. Lo que haremos será desarrollar una aplicación que nos permita mostrar una ventana modal pulsando un botón.

Partiremos de un proyecto creado desde cero. Dentro de él, abriremos el archivo index.html y añadiremos el elemento que contendrá las ventanas modales de nuestra aplicación. Sobre este elemento crearemos posteriormente el portal.

Como veis, el elemento modalContainer se encuentra al mismo nivel que el elemento react (que es donde se montará nuestra aplicación). La magia de los React Portals nos permitirá renderear componentes en el elemento del DOM modalContainer saltándonos la jerarquía de componentes de React que creemos en nuestra aplicación.

Para ello, el siguiente paso será crear nuestro componente Modal , que tendrá el siguiente aspecto

import ReactDOM from "react-dom";
import { CSSTransition } from "react-transition-group";
import "./Modal.css";

const modalContainer = document.querySelector("#modalContainer");

export default function Modal({ title, children, isOpened, onClose }) {
  if (!isOpened) {
    return null;
  }
  return ReactDOM.createPortal(
    
      
        
          
            
              {title}
              
            
            {children}
          
        
      
    ,
    modalContainer
  );
}

Este componente recibe 4 propiedades pero lo que realmente nos interesa es que es aquí donde aparece el uso de ReactDOM.createPortal . Esta función recibe dos argumentos:

El JSX que queremos “renderizar” como haríamos en un componente “normal”.
El elemento del DOM donde queremos “renderizarlo”. Como el elemento se encuentra fuera de la jerarquía que define nuestra aplicación, necesitamos recurrir a document.querySelector para seleccionar nuestro
que añadimos en el archivo index.html .

Hecho esto, tan sólo quedará añadir nuestro componente dentro del archivo App.js y la “magia” de los React Portals hará el resto:

import { useState } from "react";
import "./App.css";
import Modal from "./components/Modal";

function App() {
  const [isOpened, setOpened] = useState(false);

  const openModal = () => setOpened(true);
  const closeModal = () => setOpened(false);

  return (
    
      
        
        Counter: {counter}
        
          This is a modal
        
      
    
  );
}

export default App;

Lo realmente interesante es que, desde el punto de vista de React, la estructura de componentes es la que vemos representada en nuestros archivos. Sin embargo, al hacer click sobre el botón Open Modal la estructura del DOM que obtenemos es la siguiente:

Repositorio

En el caso de que queráis ver en más detalle el código podéis ver el siguiente repositorio:

https://github.com/ger86/react-portals-modal

Propagación de eventos

Otra de las cosas curiosas al trabajar con los React Portals es la forma en que se propagan los eventos. Aunque el contenido del portal se pinte en otra parte del DOM, el componente a nivel interno se sigue comportando como si de un hijo del componente padre se tratase.

Un evento activado desde dentro de un portal se propagará a los ancestros en el árbol de React, incluso si esos elementos no son ancestros en el árbol DOM.

Veámoslo modificando un poco el ejemplo anterior:

import { useState } from "react";
import "./App.css";
import Modal from "./components/Modal";

function Child() {
  return ;
}

function App() {
  const [isOpened, setOpened] = useState(false);
  const [counter, setCounter] = useState(0);

  const openModal = () => setOpened(true);
  const closeModal = () => setOpened(false);
  const handleClick = () => setCounter(counter + 1);

  return (
    
      
        
        Counter: {counter}
        
          
        
      
    
  );
}

export default App;

El componente , que pintamos dentro de nuestro componente Modal posee un botón capaz de recibir clicks. Además, hemos añadido un onClick de modo que cada click dentro del componente App incremente el contador.

Lo interesante es que, aunque hagamos click en el botón pintado dentro de la modal (recuerda que en el DOM del navegador está dentro del elemento modalContainer ), el componente App sigue recibiendo los clicks. Esto es gracias a que React mantiene la jerarquía de los componentes.

Suscríbete ahora

Agujeros de gusano y React Portals

Veamos ahora un ejemplo algo más interesante: crear un agujero de gusano con React. Según la teoría:

En física, un agujero de gusano, también conocido como puente de Einstein-Rosen, es una hipotética característica topológica de un espacio-tiempo, descrita en las ecuaciones de la relatividad general, que esencialmente consiste en un atajo a través del espacio y el tiempo.

Para simular el comportamiento de un agujero de gusano empleando los portales de React crearemos un nuevo proyecto e instalaremos la librería react-draggable que nos permitirá mover nuestra nave espacial por el espacio:

yarn add react-draggable

La idea del proyecto será tener dos “portales” que nos permitan conectar una nave espacial entre el espacio A (donde se encuentra el root de nuestra aplicación de React) y el espacio B.

Para comenzar, crearemos el componente que representará nuestra nave espacial:

export default function Starship({ className, ...rest }) {
  return (
    
      
        🚀
      
    
  );
}

Después, añadiremos a nuestro archivo index.html el elemento que contendrá el espacio B de nuestra aplicación:

Ahora es donde comienza la parte interesante. Queremos poder desplazar nuestra nave por el espacio A hasta el agujero de gusano para que, al entrar, se traslade automáticamente al espacio B.

Para ello, dentro de nuestro componente principal escribiremos lo siguiente:

import { useState, useRef } from "react";
import ReactDOM from "react-dom";
import Draggable from "react-draggable";
import overlaps from "utils/overlaps";
import Starship from "./components/Starship";
import "./App.css";

const spaceB = document.querySelector("#spaceB");

function App() {
  const [isInSpaceA, setIsInSpaceA] = useState(true);
  const wormholeARef = useRef();
  const wormholeBRef = useRef();

  function checkInsideWorkmholeA(event) {
    if (
      overlaps(
        event.target.getBoundingClientRect(),
        wormholeARef.current.getBoundingClientRect()
      )
    ) {
      setIsInSpaceA(false);
    }
  }

  function checkInsideWorkmholeB(event) {
    if (
      overlaps(
        event.target.getBoundingClientRect(),
        wormholeBRef.current.getBoundingClientRect()
      )
    ) {
      setIsInSpaceA(true);
    }
  }

  return (
    
      {isInSpaceA && (
        
          
        
      )}
      
      {!isInSpaceA &&
        ReactDOM.createPortal(
          
            
          ,
          spaceB
        )}
      {ReactDOM.createPortal(
        ,
        spaceB
      )}
    
  );
}

export default App;

Mucha tela que cortar aquí, ¿no? Vayamos por partes.

Primero obtenemos el elemento #spaceB donde se encuentra el espacio B.

const spaceB = document.querySelector("#spaceB");

Definimos un estado interno mediante el hook useState que almacenará en qué espacio se encuentra nuestra nave.

const [isInSpaceA, setIsInSpaceA] = useState(true);

Guardamos dos referencias a los “divs” por los que se desplazará la nave mediante el hook useRef. Así podremos comprobar si la nave ha llegado a ellos cuando se lance el evento onStop del componente Draggable.

const wormholeARef = useRef();
const wormholeBRef = useRef();

La función checkInsideWormholeA se encarga de comprobar si la nave ha llegado al agujero de gusano obteniendo el boundingRect de la nave y del agujero de gusano. Usaremos la función overlaps para realizar esa comprobación.

const overlaps = (rect1, rect2) =>
  !(
    rect1.right < rect2.left ||
    rect1.left > rect2.right ||
    rect1.bottom < rect2.top ||
    rect1.top > rect2.bottom
  );

export default overlaps;

Dentro del JSX, añadimos dos portales sobre el espacio B. Uno para añadir el Draggable cuando la nave aparezca allí, y otro con el agujero de gusano que le permitirá volver al espacio A.

{!isInSpaceA &&
  ReactDOM.createPortal(
    
      
    ,
    spaceB
  )}

--- Agujero de gusano B ---
{ReactDOM.createPortal(
  ,
  spaceB
)}

Finalmente, la función checkInsideWormholeB comprueba si la nave se encuentra en el agujero de gusano del espacio B para poder volver al A.

Si quieres, puedes ver el código en el siguiente repositorio:

https://github.com/ger86/react-portals-wormhole

🙏🏻 Gracias a Garaje de Ideas

Los amigos de Garaje de ideas patrocinan Latte and Code y buscan talento: http://bit.ly/garaje-tech-talento

Conclusiones y referencias

Como habéis podido comprobar, la API ReactDOM.createPortal abre un mundo de posibilidades a la hora de poder manipular la estructura del DOM. Estos dos ejemplos son solo la punta del iceberg de algunas de las cosas que se pueden llegar a lograr gracias a esta característica; por ejemplo, empleando los React Portals podemos incluso mover elementos entre ventanas:

https://medium.com/hackernoon/using-a-react-16-portal-to-do-something-cool-2a2d627b0202

Además, podéis profundizar más en la documentación oficial y ver más ejemplos como el de este artículo.

Espero que este artículo os haya gustado y os anime a profundizar más en esta funcionalidad de React tan desconocida.

React. A vueltas con los "rerenders" (II)

Gerardo — Tue, 17 Jan 2023 09:22:51 GMT

Photo by Milad Fakurian on Unsplash

Si has llegado hasta aquí de “casualidad”, te recomiendo que leas la primera parte de este artículo antes de continuar :)

Latte and Code

React. A vueltas con los "rerenders" (I)

En mi opinión, entender los conceptos clave de una librería es fundamental si queremos sentirnos a gusto trabajando con ella. Por eso he querido escribir un artículo centrado en la piedra angular sobre la que React fue creada: los “renders”. Pese a la evolución que está experimentando en los últimos meses, React no …

4 years ago · 7 likes · 2 comments · Gerardo

Nos habíamos quedado viendo algunas de las técnicas básicas para evitar que un componente vuelva a renderizarse. Recuerda, que un rerender en React es cualquier renderizado de un componente que ya se encuentra en el DOM y que no corresponda al “render” inicial.

Las principales causas de que esto suceda se encuentran en:

Un cambio en el estado interno declarado mediante useState.
Un cambio en el valor del contexto (si lo estamos consumiendo).
Un render del componente padre.

Además, vimos cómo la composición de componentes puede ayudarnos a optimizar nuestras aplicaciones para evitar rerenders innecesarios.

Hoy quiero repasar patrones algo más avanzados que involucran el uso de hooks como useMemo o useCallback así como algunas cosas que tenemos que tener en cuenta cuando trabajamos con contextos.

¡Vamos allá!

Suscríbete ahora

Cómo evitar “rerenders” en React

Memorizar componentes con React.memo

La función memo de React nos permite envolver un componente y evitar que este vuelva a renderizarse cuando lo hace el padre siempre y cuando sus propiedades no hayan cambiado con respecto al render anterior.

Para los más antiguos del lugar, funciona de forma muy similar a como lo hacía la función shouldComponentUpdate de los componentes creados con clases de JavaScript.

Veamos cómo funciona memo con algunos ejemplos.

Componente sin propiedades

Este es el ejemplo más fácil de todos. En el caso de que el componente que memoricemos no reciba propiedades, este no volverá a renderizarse por mucho que el componente padre lo haga.

Componente con propiedades

En el caso de que el componente que memoricemos reciba propiedades, éste volverá a renderizarse siempre y cuando éstas cambien. De lo contrario, evitaremos el resto de renders

¿Te está gustando este artículo?

Si te está gustando este artículo y quieres aprender más, ¡tengo buenas noticias! He preparado un webinar especial para este 26 de enero donde explicaré más en detalle los rerenders, las técnicas para evitarlos y cómo podemos emplear los hooks useMemo y useCallback para optimizar nuestras aplicaciones.

Tienes toda la información en el siguiente enlace. ¡Te espero!

https://latteandcode-webinar-rerenders.carrd.co

Combinar useMemo / useCallback con memo

Ya hemos visto cómo la función memo nos puede ayudar para evitar que un componente vuelva a renderizarse. ¿Pero qué sucede si las propiedades son valores no escalares como funciones, objetos o arrays?

En este caso, si no tenemos cuidado, memo no tendrá ningún efecto a la hora de evitar renders. Veámoslo con un par de ejemplos.

En este trozo de código, ParentComponent crea la función handleClick para pasársela a MemoizedChild. Sin embargo, en cada render de ParentComponent estaremos creando una nueva función que, hace lo mismo, pero en memoria es distinta. Esto provoca que el componente memorizado reciba en cada “render” un nuevo valor para su propiedad onClick y, por tanto, la memorización no surte efecto.

El siguiente ejemplo es muy similar al anterior pero en este caso el problema lo tendremos al pasar un objeto como propiedad. ParentComponent crea el objeto pet para pasárselo a MemoizedChild. Sin embargo, en cada render de ParentComponent estaremos creando un nuevo objeto que, contiene la misma información, pero en memoria es distinto. Esto provoca que el componente memorizado reciba en cada “render” un nuevo valor para su propiedad pet y, por tanto, la memorización no surte efecto.

Por suerte disponemos de los hooks useMemo y useCallback para poder obtener la misma instancia de objetos y funciones render tras render.

useMemo recibe dos argumentos:

Una función que devuelve el valor que debe ser memorizado.
Un array de dependencias que funciona de la misma forma que el del hook useEffect. La función pasada como primer argumento será ejecutada siempre y cuando las dependencias especificadas cambien.

useCallback, por su parte, recibe dos argumentos:

La función que debe memorizarse.
Un array de dependencias que funciona de la misma forma que el del hook useEffect. Siempre y cuando las dependencias listadas no cambien, se devolverá, render tras render, la misma instancia de la función pasada como primer argumento

Sabiendo esto, los anteriores ejemplos podemos “arreglarlos” de la siguiente manera.

Para el caso de la función onClick, podemos memorizarla mediante el hook useCallback para que su valor nunca cambie:

En el caso del objeto pet, podemos memorizar dicho objeto mediante useMemo, de modo que obtengamos siempre la misma instancia. Esto permitirá que el componente memorizado reciba siempre el mismo valor y evitemos los renders.

En el caso de que el nombre llegase como propiedad del componente ParentComponent, podríamos seguir memorizando el objeto y evitar todos los renders en los que name mantenga su valor.

useMemo para componentes pesados

useMemo puede ser empleado para memorizar cualquier valor, también componentes. Esto significa que podemos emplearlo para memorizar aquellos componentes que sepamos que son costosos de renderizar de un modo similar a como hacemos con la función memo.

Lo importante es que sepas que memorizar cualquier cosa tiene un costo ya que consume memoria e impacta negativamente en el primer render. Por tanto, no deberías abusar de este tipo de optimizaciones salvo que tengas claro que los beneficios superarán a los contras.

Algunos casos donde podría tener sentido memorizar elementos sería en listas largas o, como decía al principio, cuando tengamos componentes muy pesados.

Suscríbete ahora

Propiedad `key` en listas

Y hablando de listas. Como sabrás, cuando pintamos una lista de elementos empleando el método map, React te pide que establezcas una key única y consistente para cada uno de sus elementos.

Aunque establecer una key no impide que los elementos vuelvan a renderizarse cuando lo hace el componente padre, sí que permite a React realizar una serie de optimizaciones a la hora de trasladar la lista al DOM: si hemos identificado cada elemento con su correspondiente clave, React podrá reutilizar los elementos que ya se encuentren disponibles en el DOM.

En el caso de que queramos optimizar el renderizado de una lista, podemos hacer como en el ejemplo anterior o aplicar la función memo al componente que empleemos para pintar los elementos.

❗️ Recuerda que lo que nunca debes hacer es emplear como clave un valor aleatorio, por ejemplo, generándolo mediante Math.random(). Esto puede provocar un rendimiento muy pobre y puede provocar errores a la hora de gestionar campos en un formulario.

Optimización de contextos

Si recuerdas, una de las causas que pueden provocar un nuevo render es un cambio de valor en el contexto que estemos consumiendo. Es por ello, que conviene conocer los principales patrones para evitar que nuestros contextos afecten negativamente al rendimiento de nuestra aplicación.

Memorizar el valor del contexto

Si el valor que vas a pasar al contexto es un objeto o función, como norma general es mejor que lo memorices mediante el hook useMemo.

De este modo, si el componente que pinta el Context.Provider experimenta un render debido a que su padre se renderizó, no estaremos generando un nuevo valor y provocando que todos los componentes que consuman el contexto vuelvan a renderizarse.

Por suerte, podemos evitar esto empleando useMemo para memorizar el valor del contexto, de modo que en cada render obtengamos siempre la misma instancia salvo que las dependencias que establezcamos cambien:

Separar los contextos

Supongamos ahora un contexto que expone tanto el valor como la función para actualizarlo.

En estos casos, puede ser buena idea separar en dos el contexto:

Un contexto proveerá del valor name.
El otro de la función setName.

De este modo, cuando el valor cambie, los contextos que sólo necesiten la función setName no se verán afectados, mejorando así el rendimiento de nuestra aplicación.

Esta misma técnica puede aplicarse a contextos cuyo valor este compuesto de varias propiedades, de modo que necesitemos un objeto para representarlo:

Si un componente sólo necesita la propiedad surname, se verá obligado a renderizarse cuando name cambie, lo cual es ineficiente.

El caso anterior podríamos llegar a optimizarlo de la siguiente forma:

Selectores de contexto

React no cuenta con selectores para el contexto. Es decir, si, como en el ejemplo anterior, nuestro contexto es un objeto con varias propiedades, todos los componentes que lo consuman se renderizarán cuando el valor cambie, aunque no estén consumiendo la propiedad que ha cambiado.

Sin embargo, podemos recurrir a un “truco” para simular los selectores gracias a la combinación de React.memo con los “higher order components”.

La idea es declarar un “higher order component” que consuma el contexto y pase como propiedad el valor que el componente necesita. Este componente lo dejaremos memorizado mediante React.memo.

Es decir, pasaríamos de esto:

A esto:

La idea de este trozo de código es la siguiente:

Declaramos un higher order component que recibirá un componente que sólo debe renderizarse cuando la propiedad someProperty del contexto cambia.
El higher order component memoriza el componente recibido mediante React.memo.
El componente devuelvo por el higher order component consume el contexto y accede a someProperty.
El valor de someProperty es pasado al componente memorizado como propiedad. Como lo hemos memorizado, este componente sólo se renderizará si el valor de la propiedad cambia. Justo lo que queríamos conseguir.
Por supuesto, el componente original deberá pasar a recibir ese valor como propiedad en vez de consumirlo directamente del contexto como hacíamos antes.

🙏🏻 Gracias a Garaje de Ideas

Los amigos de Garaje de ideas patrocinan Latte and Code y buscan talento: http://bit.ly/garaje-tech-talento

Conclusiones

Y aquí concluye este artículo sobre React y las diferentes técnicas para evitar renders innecesarios.

Mi consejo es que te familiarices primero con las distintas causas que pueden provocar un render y que aprendas a identificar aquellos componentes que son susceptibles de ser optimizados con cualquiera de las técnicas que te he contado. Muchas de ellas te ayudarán además a entender mejor React y cómo funciona su sistema de renderizado.

💛 ¡Muchas gracias por leerme!

Suscríbete ahora

Capítulo 3. Lo que aprendí de DDD. Entidades

Gerardo — Thu, 29 Dec 2022 09:49:34 GMT

Photo by blocks on Unsplash

En el capítulo anterior repasé el patrón Value Object para modelar los elementos de nuestro dominio que representan valores, como un precio o un rango de fechas.

Sin embargo, otros elementos de nuestro dominio pueden tener un carácter único, como una persona, una orden de compra o una factura, es decir, representan entidades únicas de nuestra aplicación.

Simplificando mucho esta idea, una entidad vendría a ser una tabla de nuestra base de datos (si estamos empleando un sistema relacional). Yo prefiero entender el concepto entidad como un elemento que posee identidad propia por sí mismo junto con una serie propiedades que pueden variar a lo largo del tiempo.

Identidad

Supongamos que tenemos definida la siguiente clase básica de PHP para representar a la entidad Person de nuestro dominio:

class Person
{
  public function __construct(
      private int $id,
      private string $name,
      private string $surname 
  ) {}

  // ...
}

Lo que diferencia a un objeto de la clase Person de otro es su campo $id , el cual tiene un valor único a lo largo de toda la aplicación. Da igual que este campo sea, como en el ejemplo, un número, lo importante es que posee un carácter único que sirve para identificar inequívocamente al objeto que representa.

❗️ Importante. Puede que estemos acostumbrados a especificar los identificadores como números, pero también pueden ser sin problema cadenas de texto como uuids o cosas más concretas como el ISBN de un libro o el DNI de una persona. Lo crucial es que estemos seguros de que no se producirán colisiones.

Y ahora que conocemos el poder de los Value Objects, ¿por qué no representarlos mediante ellos?

class Person
{
  public function __construct(
      private PersonId $id,
      private string $name,
      private string $surname 
  ) {
  }

  // getters and setters
}

De este modo, será el Value Object PersonId el encargado de:

Proveer de la unicidad de cada identificador generado (segregación de responsabilidades).
Encapsular la idea de “identificador de una persona” dentro de un objeto.

Recuerda, con DDD trataremos de explotar el paradigma de la programación orientada a objetos.

Generación de identificadores

Para generar estos identificadores existen 3 formas diferentes de hacerlo. Vamos a verlas.

Delegación en la base de datos

Probablemente esta forma sea la más común y habitual en la mayoría de aplicaciones. Nuestras entidades son construidas sin identificador y no es hasta el momento en que se insertan en base de datos cuando reciben su identificador único (el típico número incremental de MySQL, por ejemplo).

Sin embargo esta aproximación presenta dos problemas:

Algo tan fundamental de nuestro dominio como la generación de identificadores para nuestras entidades lo hemos delegado en un servicio externo sobre el cual no tenemos control.
Además, nuestras entidades son construidas en un estado intermedio o incompleto. Necesitamos insertarlas en base de datos para que sean realmente entidades de nuestro dominio.

class Person
{
  public function __construct(
      // 🙁 no sé mi identificador private int $id,
      private string $name,
      private string $surname 
  ) {}

  // getters and setters
}

Sé que este punto puede resultar demasiado filosófico, pero, si estamos adoptando un enfoque DDD, no tiene sentido que a las primeras de cambio nuestro dominio pase a girar en torno a la infraestructura (concretamente nuestra base de datos) cuando debería ser al revés.

Delegación en el cliente

Otro enfoque es delegar en el cliente que consume nuestra aplicación la generación de esos identificadores.

Es decir, el identificador procede de fuera de nuestra aplicación, llegándonos por medio de la petición (por ejemplo):

{
  "id" => "a8325530-c925-11eb-b8bc-0242ac130003",
  "name" => "Gerardo",
  "surname" => "Fernández"
}

Ahora sí podríamos construir nuestro objeto de la clase Person en un estado “completo”, pues dispondríamos de todos los campos para crearlo:

class Person
{ 
  public function __construct(
      private PersonId $id,
      private string $name,
      private string $surname 
  ) {}

  // getters and setters
}

$person = new Person(
    new PersonId($post['id']), 
    $post['name'],
    $post['surname']
);

Sin embargo, a mí personalmente me resulta raro delegar esta tarea en el cliente. Es cierto que en contextos muy concretos como por ejemplo el de modelar un “libro” podemos emplear el ISBN proporcionado por el cliente de nuestra aplicación, pero no sé si es aplicable en todo tipo de aplicaciones.

La aplicación genera el identificador

La tercera y última opción es que sea la propia aplicación quien se encargue de generar dicho identificador. En mi opinión es la opción que tiene más sentido para la mayoría de casos.

Aquí es donde cobran especial importancia los “identificadores únicos universales”, también conocidos por su abreviatura “uuid”, los cuales nos van a garantizar (casi casi casi al 100% de probabilidad) que cada entidad tendrá un identificador único dentro de nuestra aplicación.

// Ejemplo de uuid
123e4567-e89b-12d3-a456-426614174000

Es decir, en vez de generar números aleatorios para asociarlos a nuestras entidades como identificadores (lo cual podría provocar a la larga colisiones), los “uuids” nos van a garantizar esa unicidad.

Si trabajas con PHP te recomiendo que eches un vistazo a las siguientes librerías para generarlos:

https://github.com/ramsey/uuid

https://symfony.com/doc/current/components/uid.html

Sabiendo esto, podemos modelar el Value Object PersonId de la siguiente forma:

value->equals($userId->value);
    }
}

Ahora, al construir nuestro objeto Person lo haremos del siguiente modo:

$person = new Person(
    PersonId::generate(),
    $post['name'],
    $post['surname']
);

Si lo deseas, puedes ver cómo migro un proyecto de ids generados en base de datos a uuids en mi curso gratuito de Symfony:

Validación

Otro punto muy interesante sobre las entidades es su validación. Es decir, ¿cómo asegurarnos de que creamos entidades válidas para nuestro dominio?

Os hablaré de los dos tipos de validación que podemos considerar.

Validación de valor

Este tipo de validación es la que realizamos para asegurarnos de que no nos “cuelan” un email inválido o un teléfono de 3 dígitos.

Como su propio nombre indica, una validación valor debería ser acometida dentro del “Value Object” que representa dicho valor. ¿Tiene sentido no? Esto es lo que más me gusta del enfoque DDD: encontrar las cosas allí donde se las espera sin rebuscar por distintas carpetas o clases.

Por tanto, la validación de si un email es válido la realizaremos dentro del Value Object Email , de forma que impidamos crear emails que no son válidos:

class Email
{
    public function __construct(private string $value)
    {
        $this->ensureValid($value);
    }    

    private function ensureValid(string $value): void
    {
        // lanza una excepción si es inválido
    }
}

Aplicando esto, terminaremos con un constructor similar a éste para nuestra entidad Person en el que cada propiedad es representada por un ValueObject:

class Person
{
  // ...  
  public function __construct(
      private PersonId $id,
      private Name $name,
      private Surname $surname,  
      private Email $email 
  ) {}
  
  // ...
}

Validación de integridad

Por otra parte, puede haber validaciones que requieran comprobar propiedades relacionadas entre sí. Por ejemplo, una regla de negocio que impida que un usuario pueda completar su teléfono si ya tiene un email establecido.

Este tipo de validaciones las podríamos realizar en dos lugares:

Dentro del constructor de la propia entidad.
En un servicio de dominio que se encargue de realizar dicha validación.

Ambos enfoques tienen sus ventajas e inconvenientes.

Si validamos dentro del constructor, es posible que terminemos con una clase gigantesca según el número de validaciones que haya que realizar. Sin embargo, nos estaremos asegurando de que cualquier objeto que construyamos lo hará en un estado válido.

Por otra parte, si lo hacemos en un servicio externo, nos veremos obligados a recordar que cada vez que construyamos nuestras entidades, deberemos invocar ese servicio para asegurarnos de que son realmente válidas.

¿Mi consejo? Yo apostaría por validar dentro del constructor siempre y cuando podamos mantener dicha complejidad.

Suscríbete ahora

Eventos de dominio

Hablemos finalmente de los eventos de dominio, otro punto clave del enfoque “Domain Driven Design” y que nos permitirá reaccionar a los sucesos que tengan lugar dentro de nuestra aplicación.

Pese a que dedicaré un capítulo completo a este concepto, me parece interesante reseñarlo ahora que estamos hablando de entidades.

La idea clave de los eventos de dominio es publicar todo lo que sucede con respecto a nuestras entidades.

Por ejemplo, cuando construyamos nuestra entidad Person , no sólo crearemos el objeto sino que registraremos un evento que simbolice la creación de este objeto:

class Person
{
  // ...  
  private array $domainEvents = []

  public function __construct(
      private PersonId $id,
      private Name $name,
      private Surname $surname,  
      private Email $email 
  ) {
      // ... 
      $this->recordDomainEvent( 
          new PersonCreated($id) 
      );
  }  

  public function recordDomainEvent(DomainEvent $event): self
  {
      $this->domainEvents[] = $event;
      return $this;
  }  

  public function pullDomainEvents(): array
  {
      $domainEvents = $this->domainEvents;
      $this->domainEvents = [];
      return $domainEvents;
  }  // ...
}

Sabiendo esto, el servicio o clase que creó este objeto Person deberá publicar (empleando por ejemplo un Event Dispatcher como el que proporciona Symfony) los eventos que la entidad haya registrado:

personRepository->save($person);

        foreach ($person->pullDomainEvents() as $event) {
            $this->eventDispatcher->dispatch($event);
        }
        return $person;
    }
}

🙏🏻 Gracias a Garaje de Ideas

Los amigos de Garaje de ideas patrocinan Latte and Code y buscan talento: http://bit.ly/garaje-tech-talento

Repositorios de entidades

Si te fijas en el código anterior, estoy empleando la clase PersonRepository para persistir en base de datos el recién creado objeto $person .

En el próximo capítulo repasaré el concepto de “repositorio” para concluir con la gestión de entidades de nuestro proyecto.

Hasta entonces, espero que hayas disfrutado este capítulo.

¡Muchas gracias por leerme!

Suscríbete ahora

React. A vueltas con los "rerenders" (I)

Gerardo — Tue, 13 Dec 2022 09:18:51 GMT

Photo by Sebastian Svenson on Unsplash

Comprender este proceso que conocemos como “renderizado” y los eventos que lo desencadenan es clave si queremos diseñar aplicaciones optimizadas a la vez que sentamos las bases para seguir mejorando. De un modo o de otro, cuando trabajamos con React terminamos hablando de “renders”, así que, ¿por qué no aprender bien cómo funcionan?

He decidido dividir en dos partes el contenido de este artículo sobre React y los “rerenders” para que así no quede excesivamente largo y tengáis tiempo de procesar la información. Para recibir la siguiente parte cuando la publique puedes quedarte suscrito con el siguiente botón:

Suscríbete ahora

¿Qué es un “render” en React?

Empecemos por el principio y veamos lo que significa el concepto de “render”. Para mí, un “render” es el proceso por el cual React envía al DOM el JSX devuelto por un componente . El componente calcula este JSX a partir de 3 elementos:

Las propiedades recibidas.
Su estado.
El valor de los contextos que consuma procedentes la API Context.

Un componente es renderizado siempre y cuando aparezca en algún lado del árbol de componentes que hayamos generado.

Vayamos al principio. Cuando el navegador carga por primera vez nuestra aplicación, React genera un árbol de componentes que irán devolviendo trozos de JSX hasta definir la estructura entera de la vista de la aplicación. A medida que el usuario interactúe con esta vista, este árbol se irá modificando de distintas maneras:

Añadiendo nuevos componentes.
Eliminando componentes existentes.
O modificando el estado de los ya existentes.

Lo más importante aquí es que cuando un componente aparece por primera vez en el árbol experimenta un primer renderizado que podemos identificar como “render inicial”. En este render inicial el componente definirá los valores de partida de su estado. A partir de aquí es cuando entra en juego el concepto de “rerender” y todo se vuelve mucho más interesante.

Qué son los “rerenders”

Un “rerender” es cualquier renderizado de un componente que ya se encuentra en el DOM y que no corresponda al “render” inicial.

Un “rerender” sucede cuando se produce un cambio en el estado de la aplicación, bien por la acción del usuario sobre un elemento, bien por la llegada de datos desde fuera como una llamada fetch.

Podemos clasificar los “rerenders” en dos grandes tipos:

Los necesarios, es decir, aquellos en los que el componente se ve afectado directamente por el cambio y, en consecuencia, generará un JSX distinto del anterior. Por ejemplo, si estamos modelando un contador, cuando el usuario pulse el botón que permite incrementarlo, necesitaremos un nuevo render para mostrar el nuevo valor del contador.
Y, los inncesarios, es decir, aquellos en los que el componente se ve obligado a renderizarse de nuevo pese a que el cambio no le afectaba y, por tanto, devolverá el mismo JSX que la vez anterior. Esto habitualmente está motivado por una estructura deficiente de nuestra aplicación.

Por suerte, React está lo suficientemente bien optimizado como para que los “rerenders” innecesarios no penalicen en exceso. Sin embargo, si descuidamos por completo este punto, terminaremos creando aplicaciones imposibles de usar. Lo cual nos lleva directos al siguiente punto… ¿qué provoca un “rerender”?

¿Qué provoca un “rerender”?

Un componente puede volver a renderizarse por alguna de las siguientes razones:

Un cambio en el estado interno declarado mediante useState como consecuencia de una acción del usuario, por ejemplo, pulsar un botón.
En el caso de consumir un contexto, un cambio en el valor del mismo.
Su componente padre vuelve a renderizarse.

Veámoslas en detalle.

Cambios en el estado

Cuando declaramos una pieza de estado dentro de un componente por medio del hook useState, cualquier cambio en el mismo como consecuencia de la invocación de setState provocará un nuevo render del componente.

Cambio en el contexto

Cuando el valor del contexto cambia, todos aquellos componentes que estén consumiendo ese contexto por medio del hook useContext volverán a renderizarse para así actualizar la vista de acuerdo al cambio producido.

Render del componente padre

Por defecto, un componente vuelve a renderizarse siempre que su componente padre lo haga. Dicho de otro modo, cuando un componente se renderiza, esto supone que todos sus componentes hijos también lo hagan.

Cómo evitar “rerenders” en React

Ahora que ya hemos visto las 3 razones por las que un componente puede volver a renderizarse, veamos algunas de las técnicas que pueden ayudarnos a evitar “rerenders” innecesarios, de modo que podamos optimizar nuestra aplicación lo máximo posible.

Lo bueno de estas técnicas que veremos a continuación es que se pueden aplicar sin importar el nivel que tengas, de modo que si estás comenzando a familiarizarte con los mundos de React te animo a que pierdas el miedo y las pongas en práctica.

Estas técnicas las dividiremos en 3 grandes bloques:

Técnicas mediante composición.

Composición

Situar el estado lo más abajo posible

Esta técnica podemos aplicarla si estamos trabajando con componentes pesados que definen multitud de estados, ya que puede que alguno de ellos sólo se esté usando en una parte muy específica del árbol de componentes.

En la imagen, el estado número 4 sólo se usa en el componente 4. Sin embargo, con esa estructura, un cambio en el estado 4 provocará un render de todo el árbol de componentes (recuerda, un render en un componente provoca el render de todos sus hijos), lo cual es muy ineficiente.

Este problema podemos evitarlo definiendo el estado 4 en Component4 , de modo que sus cambios no afecten a todo el árbol.

Pasar componentes como propiedades

Esta técnica es muy similar a la anterior. Supongamos que estamos pintando un componente que es muy costoso de renderizar dentro de un componente que sufre renders frecuentemente (por ejemplo, un componente que está gestionando un input):

Esta estructura supone que cada render de FormComponent provoque el renderizado de los inputs y el componente SlowComponent.

La forma de evitar un posible problema de rendimiento es aprovecharnos de la propiedad children, ya que al ser eso, una propiedad, no se verá afectada por los renders que se provoque en el componente FormComponent: es como si ya llegase renderizada y por tanto React no necesita renderizarla cada vez que FormComponent lo haga.

Esta técnica se conoce como “envolver el estado alrededor de los hijos” y es muy útil para resolver problemas de rendimiento como el que estamos viendo.

Además, esto no sólo funciona con la propiedad children, sino que podemos definir tantas propiedades en nuestro componente como necesitemos.

¡Cuidado! Crear un componente dentro de otro

Finalmente, tenemos que tener cuidado con un antipatrón que puede ocasionarnos graves problemas de rendimiento: definir un componente dentro de otro.

Hacer esto supone que React remonte en cada render el componente OtherComponent, es decir, destruya su anterior versión y vuelva a crearla desde cero. Esto es mucho más costoso a nivel de rendimiento que un simple render. De este antipatrón se derivan problemas como:

“Flashazos”,
La reinicialización del estado de OtherComponent en cada render.
La ejecución de los efectos declarados por OtherComponent en cada render, aunque no tengan dependencias.
Pérdida del foco de los inputs declarados dentro de OtherComponent.

Vamos, ¡una fiesta!

🙏🏻 Gracias a Garaje de Ideas

Los amigos de Garaje de ideas patrocinan Latte and Code y buscan talento: http://bit.ly/garaje-tech-talento

Para aprender más

https://www.developerway.com/posts/react-re-renders-guide

Conclusiones

Y hasta aquí la primera parte del artículo que he preparado sobre React y los rerenders. Espero que te haya servido para entender mejor cómo funciona este proceso y de paso te de ayude a resolver algún que otro problema de rendimiento.

Si te animas a contarme tus experiencias con algunos de los patrones propuestos o te has quedado con alguna duda, soy todo oídos.

💛 ¡Que tengas muy buen día!

Capítulo 2. Lo que aprendí de DDD. Value Objects

Gerardo — Tue, 22 Nov 2022 09:10:10 GMT

Photo by Colton Sturgeon on Unsplash

Una de las ideas que más me han gustado del enfoque DDD son los “Value Objects”, los cuales nos permiten encapsular los elementos de nuestra aplicación que representan un valor por sí mismos.

La idea en la que se basan es realmente sencilla y de hecho cobra gran sentido si estamos trabajando con un lenguaje que admita Programación Orientada a Objetos. Presta atención.

Imagina una clase User con el siguiente constructor:

public function __constructor(string $email, string $fullname) 
{
...
}

Sí, está claro que $email representa una dirección de correcto electrónico, pero, ¿quién nos asegura que es un email válido? Declarando el argumento como un string plano estamos perdiendo mucho contenido semántico de ese argumento, es decir, su significado dentro de nuestra aplicación.

Sin embargo, si tuviéramos creada una clase Email a la que perteneciesen todos los objetos de tipo email que creamos en nuestra aplicación:

class Email
{
    private string $value;    public function __construct(string $value)
    {
        $this->ensureIsValid($value); 
        $this->value = $value;
    }    public function value(): string
    {
        return $this->value;
    }    private function ensureIsValid(string $value): void
    {
        // checks and throw exception if it is not valid
    }
}

El constructor de la clase User adquiriría verdadero significado cuando lo leamos:

public function __constructor(Email $email, string $fullname) 
{
...
}

Y no tendríamos que hacerla responsable de asegurar que el email es válido, sino que dicha comprobación se realizaría donde más sentido tiene: al construir un objeto de la clase Email.

Para mí esta es la mayor ventaja de la que nos proveen los Value Objects: acercar lo máximo posible las responsabilidades y la integridad de nuestros objetos al lugar donde el sentido común nos diría que deben realizarse.

¿No os da la sensación de que ésta es la verdadera programación orientada a objetos?

Suscríbete ahora

Citas famosas

Ahora dejemos a gente que sabe bastante más que yo hablar de los “Value Objects”.

Ward Cunningham

Examples of value objects are things like numbers, dates, monies and strings. Usually, they are small objects which are used quite widely. Their identity is based on their state rather than on their object identity. This way, you can have multiple copies of the same conceptual value object.

Martin Fowler

A small Object such as a Money or the date range object. Their key property is that they follow value semantics rather than reference semantics. You can usually tell them because their notion of equality isn’t based on identity, instead two Value Objects are equal if all their fields are equal. Although all fields are equal, you don’t need to compare all fields if a subset is unique — for example currency codes for currency objects are enough to test equality. A general heuristic is that Value Objects should be entirely immutable.

Características

Las definiciones anteriores ilustran muy bien las principales características de los Value Objects.

Dos “value objects” son iguales si poseen el mismo valor, independientemente de que sean “objetos” distintos en memoria.
Los “value objects” son preferiblemente inmutables, es decir, si queremos modificar su valor crearemos uno nuevo con el resultado de la operación en vez de modificar el valor interno del “value object” que ya tenemos.
Los “value objects” son reemplazables, en el sentido de que podemos reemplazar un value object por otro sin temor a que se produzcan efectos secundarios.
Los “value objects” pueden tener varias propiedades. Un ejemplo sencillo es el “value object” Price , compuesto de “cantidad” y “moneda” o el “value object” RangeDate compuesto de las propiedades “desde” y “hasta”.

En definitiva, los “value objects” nos permiten modelar los valores de nuestra aplicación que no representan una entidad por sí mismos.

Diferencia con las entidades

Los “value objects” se distinguen de las entidades en un aspecto fundamental: sólo representan un tipo de valor dentro nuestra aplicación pero no tienen identidad por sí mismos, es decir, no representan un concepto como puede ser un “Usuario” o un “Artículo”.

Por esa razón, los value objects no son almacenados en tablas individuales de nuestra base de datos, sino que sus datos pertenecen a las entidades que los usan, los intercambian y realizan operaciones sobre ellos.

Me gusta mucho el ejemplo que menciona la propia Wikipedia para explicar la diferencia:

Example: Most airlines distinguish each seat uniquely on every flight. Each seat is an entity in this context. However, Southwest Airlines, EasyJet and Ryanair do not distinguish between every seat; all seats are the same. In this context, a seat is actually a value object.

Te dejo otro en español:

Un teléfono es un ejemplo muy tontorrón de “value object” en casi cualquier aplicación. Sin embargo, si imaginamos un sistema de gestión de una empresa telefónica, los teléfonos tendrán entidad propia, pues gozarán de sus propias propiedades como “está Asignado” o “fecha de vencimiento”.

¿Preocupado por el consumo de memoria?

Igual te estás preguntando si esto de los “value objects” no empeorará el rendimiento de la aplicación al crear objetos extra para representar strings. La respuesta es no, el impacto es mínimo, pues realmente la huella en memoria la sitúa el propio valor y no el value object por sí mismo, que actúa como un mero contenedor.

Persistiendo en base de datos

Y terminamos con la parte más interesante. ¿Cómo trabajar con ellos cuando necesitamos persistir información en base de datos?

A día de hoy sigo trabajando con Symfony para el backend, por lo que esta respuesta gira en torno al ORM Doctrine. Si usas otro framework / ORM te recomiendo que busques en su documentación porque es posible que exista una alternativa parecida a la que voy a describir.

Desde la versión 2.5 de Doctrine es posible emplear lo que se conocen com Embeddables, los cuales son perfectos para trabajar con Value Objects. Volvamos al ejemplo de la clase User y el value object Email . Para integrar los “embeddables” de Doctrine lo único que tenemos que hacer es lo siguiente:

use Doctrine\ORM\Mapping as ORM;/**
* @ORM\Embeddable
*/
class Email
{
    /** @ORM\Column(type="string", name="email", length=255) */   
    private string $value;    public function __construct(string $value)
    {
            $this->ensureIsValid($value); 
            $this->value = $value;
    }    ...
}class User
{
    /**
    * @ORM\Embedded(class="App\Entity\Email", columnPrefix=false))
    */
    private Email $email;    ...
}

Gracias al par de anotaciones Embeddable / Embedded podremos emplear nuestros Value Objects para persistirlos en base de datos mediante Doctrine.

Como veis, es posible añadir un prefijo a la columna creada en base de datos en el caso de que, por ejemplo, estemos usando el mismo “valor” varias veces en nuestra entidad (por ejemplo, “teléfono móvil” y “teléfono de casa”).

En este vídeo de mi curso gratuito de Symfony también hablo de ellos y así podéis verlo en directo:

🙏🏻 Gracias a Garaje de Ideas

Los amigos de Garaje de ideas patrocinan Latte and Code y buscan talento: http://bit.ly/garaje-tech-talento

Conclusiones

Y hasta aquí el artículo de hoy. Creo que el concepto detrás de los “value objects” es muy muy potente y que representa a la perfección la filosofía de la programación orientada a objetos y de la separación de conceptos.

¡Hasta el siguiente capítulo!

Capítulo 1. Lo que aprendí de DDD. Conceptos básicos

Gerardo — Tue, 08 Nov 2022 08:28:49 GMT

Photo by Lance Anderson on Unsplash

Uno de los propósitos del año 2020 fue profundizar en el enfoque DDD y arquitectura hexagonal empleando mi framework favorito (Symfony) como punto de partida. Algunas de las ideas que extraje ya las he mencionado en el curso de Symfony que tenéis disponible en mi canal de Youtube.

Hoy comienzo una serie de artículos en los que daré forma a todas las notas que tomé durante el año pasado con el objetivo de acercaros un poco más las ideas fundamentales en las que se basa DDD.

¿Me acompañas?

¿Qué es DDD?

La idea del enfoque DDD (siglas de Domain — Driven — Design) es muy sencilla: alinear a todos los equipos involucrados en el desarrollo de un producto:

Lograr una comunicación fluida y bidireccional entre el equipo de negocio y el de desarrollo.
Asegurar que el producto desarrollado responde a las expectativas de negocio.
Facilitar la iterabilidad y mantenibilidad del producto.

Esta es la razón de que en DDD el “lenguaje ubicuo” tenga tanta importancia. Definirlo al comienzo del desarrollo de un producto de largo alcance es el que nos permitirá que software y negocio trabajen bajo el mismo dominio de ideas.

Un ejemplo “tontorrón” en el desarrollo de un blog: el lenguaje ubicuo nos servirá para evitar que la parte de negocio hable de “artículos” mientras que el software tenga entidades llamadas “posts”.

¿Es DDD “el bálsamo de fierabrás”?

No, DDD no siempre es la solución óptima: este enfoque implica mucho más tiempo y una mayor implicación de todo el equipo que un desarrollo normal. Además, trasladar el dominio de negocio al software obliga a seguir determinados estándares que permitan portar esas ideas a las entidades y servicios de la aplicación. Quédate con esta idea:

DDD nos anima a acercar lo máximo posible la lógica de negocio a nuestras entidades de dominio.

Por tanto, antes de lanzarte a implementar un proyecto con una aproximación basada en dominio asegúrate de que dispondrás del tiempo y la involucración adecuadas.

Arquitecturas recomendadas

A continuación os dejo 4 arquitecturas que os permitirán en mayor o menor medida darle un enfoque DDD a vuestros proyectos.

La idea subyacente cuando implementamos DDD es conseguir separar lo máximo posible el dominio de nuestro aplicación de la infraestructura que empleamos para implementar el proyecto (“separation of concerns”). Es decir, si estamos empleando Symfony para desarrollar el proyecto, lo deseable será que nuestras entidades de dominio desconozcan por completo la existencia del ORM Doctrine o de cualquiera de los componentes que nos ofrece Symfony para implementar funcionalidad.

Patrón MVC

El archiconocido patrón modelo-vista-controlador permite separar en 3 capas un proyecto:

El modelo, que es dónde reside la lógica de nuestra aplicación.
La vista, es decir, la representación de dicho modelo.
El controlador, encargado de recibir la petición y trasladarla al modelo para generar la vista.

Este patrón es el que yo estoy siguiendo (de momento) en el curso de Symfony que os enlacé al principio. Es cierto que su adopción obliga al modelo a conocer detalles de la infraestructura (por ejemplo, los repositorios). Sin embargo, si lo organizamos adecuadamente y nos esforzamos en abstraer lo máximo posible el uso del framework, creo que podemos lograr un buena aproximación sin recurrir a la dosis extra de tiempo que requieren el resto de arquitecturas propuestas.

Arquitectura hexagonal

La idea de la arquitectura hexagonal es separar por completo la infraestructura del dominio.

En este caso, cada círculo sólo puede ver aquello que queda dentro de él:

La capa de dominio es dónde se encuentra la lógica de negocio.
La capa de aplicación se encarga de orquestar el dominio, decidiendo las llamadas que es necesario hacer a cada entidad de negocio.
La capa es la que provee de la “chicha”: ORM, controladores… Es decir, la implementación de las operaciones y acciones que hemos definido en nuestro dominio.

Además, en arquitectura hexagonal cobran especial importancia los eventos de dominio, que representan acciones que han ocurrido dentro de nuestro sistema.

CQRS

CQRS (Command-Query-Reponsability-Segregation) da una vuelta más a la arquitectura anterior: no sólo se separan las capas de nuestro proyecto sino que divide en dos las operaciones que nuestro sistema puede procesar:

Una petición (devuelve un resultado).
Un comando (produce una mutación, es decir, un cambio en el sistema).

Por tanto, CQRS promueve la idea de tener dos bases de batos distintas:

la de escritura, que actúa como fuente de verdad de nuestro sistema.
la de lectura, que modelará las diferentes vistas de nuestra aplicación.

El proceso por el cual la “base de datos” de escritura se comunica con la de lectura se conoce como proyección.

Event Sourcing

La última vuelta de tuerca a las arquitecturas que promueven una mejor implementación del enfoque DDD es la conocida como event sourcing.

Aquí, los “eventos de dominio” cobran vital importancia, pues son los que van a guardarse en base de datos para reconstruir el estado de una entidad.

Dicho de otro modo, si estamos creando un blog bajo el enfoque “event sourcing”, no dispondremos de una tabla “article”, sino que tendremos una tabla dónde aparezcan todos los eventos que se han producido en torno a los artículos de nuestro sistema:

ArticleCreated
ArticleTitleEdited
ArticleImageEdited
ArticleMovedToDraft

Como supondréis, este enfoque es bastante complicado de implementar, pero a cambio obtendremos el registro de todo lo ocurrido en nuestro sistema, facilitando su depuración y mantenibilidad.

🙏🏻 Gracias a Garaje de Ideas

Los amigos de Garaje de ideas patrocinan Latte and Code y buscan talento: http://bit.ly/garaje-tech-talento

Conclusiones

Y hasta aquí el artículo de hoy. Sé que me he dejado en el tintero ideas como los “bounded contexts” y que el resumen de las distintas arquitecturas es eso, un resumen.

En posteriores capítulos seguiré profundizando en estos y nuevos conceptos. ¡Tengo material para aburrir!

Feliz cumpleaños, TypeScript

Gerardo — Thu, 13 Oct 2022 08:30:51 GMT

Photo by Annie Spratt on Unsplash

El 1 de octubre de 2012, Microsoft lanzó la primera versión de TypeScript, un lenguaje construido sobre JavaScript que revolucionaría la forma en que creamos aplicaciones gracias a su sistema de tipado.

Dos años más tarde, el 7 de octubre de 2014, quedó liberada la primera versión estable, bajo el código 1.1.0.1. Desde entonces, la adopción de TypeScript ha crecido de forma exponencial hasta posicionarse entre los 5 lenguajes más usados.

https://octoverse.github.com/#top-languages-over-the-years

Una mirada atrás

TypeScript fue concebido en una época en la que JavaScript era considerado demasiado frágil como para desarrollar aplicaciones grandes con él. En la presentación de TypeScript Anders Hejlsberg, perteneciente a su equipo de desarrollo, enunciaba las limitaciones que JavaScript presentaba por aquel entonces:

Ser un lenguaje enfocado en el “scripting”.
La carencia de tipado estricto.
Y la ausencia de elementos como interfaces y clases.

En lo que respecta a aplicaciones web, NodeJS todavía estaba dando sus primeros pasos y Bootstrap y JQuery dominaban el panorama front. Si cogemos la máquina del tiempo nos encontraremos con tweets como estos:

Pero, ¿por qué esta desconfianza en JavaScript? Para entenderlo, debemos retroceder unos cuantos años más. En 2007, Microsoft, Yahoo, Opera y otras empresas fracasaron a la hora de ponerse de acuerdo en el rumbo que debía adoptar JavaScript. La especificación ES4, que incluía clases, interfaces e incluso tipado estricto fue desechada tras largos debates y se impuso un camino más conservador que se traduciría en ECMAScript 5 (originalmente ECMAScript 3.1). Esto supuso que muchas de las novedades previstas quedaran aparcadas y JavaScript siguió siendo visto como un lenguaje enfocado en el desarrollo de scripts pequeños.

TypeScript es el resultado de esa profecía autocumplida en la que JS nunca sería lo suficientemente robusto. Podemos agrupar sus ventajas en 3 grandes bloques.

Suscríbete ahora

🕵🏼‍♂️ TypeScript y tipado estricto

Así las cosas, TypeScript fue presentado como un superconjunto de JavaScript que incorporaba tipado estricto. Para ello, se desarrolló en paralelo un compilador encargado de convertir código escrito en TypeScript a JavaScript puro, analizando durante el proceso el tipado correcto de las variables:

Compilador TypeScript

La diferencia entre el tipado dinámico y estricto reside en la forma en que las variables referencian valores. Los lenguajes del primer grupo, como JavaScript, permiten este tipo de sentencias:

let myVar = 2;
myVar = 'hola';

Por el contrario, el tipado estricto establece el tipo de valor que almacenará una variable durante su declaración, no pudiendo modificarlo posteriormente:

let name: string = 'Simba';
name = 2; ❌

La pérdida de flexibilidad que introduce este sistema de tipado es compensada por la garantía de que el código desplegado funcionará. Es decir, nuestra preocupación se centrará exclusivamente en comprobar si realmente funciona como queremos, no en si también funciona.

Otro superpoder: los genéricos

Desde sus inicios, TypeScript también incorporó en su sistema de tipado los genéricos, una herramienta muy poderosa para trabajar con patrones de diseño y fomentar la reusabilidad de los elementos que desarrollamos.

La idea detrás de los genéricos es permitir que una función o clase de nuestra aplicación acepte múltiples tipos sin que por ello tengamos que perder el tipado por el camino.

Pensemos en la función identidad, aquella que devuelve el argumento recibido sin operar ningún cambio sobre él. Si TypeScript careciera de genéricos, estaríamos obligados a declararla del siguiente modo:

function identity(arg: any): any {
  return arg;
}

De modo que cuando la usásemos, el tipo de retorno sería `any`:

const name = 'Simba';

const dev = identity(name); 

dev // any

Gracias a los genéricos, podemos preservar el tipo del valor de retorno:

function identity(arg: Type): Type {
  return arg;
}

const name = 'Simba';
const dev = identity(name); 
dev // string

const age = 9;
const dev = identity(age); 
dev // number

🔦 Linter

Contar con un sistema de tipado estricto también vitamina automáticamente a nuestros editores de código. El autocompletado funcionará mucho mejor al conocer el editor los tipos de cada variable y escribiremos muchos menos bugs. Especialmente aquellos relacionados con ese viejo amigo: “Resolving TypeError: Cannot Read Property of Undefined in JavaScript”.

📑 Documentación

Una de las cosas que más pereza dar a la hora de escribir librerías o aplicaciones es la documentación. En JavaScript esto es especialmente tedioso: debido al carácter dinámico de su tipado, es necesario proporcionar bien mediante comentarios, bien mediante los Readme’s apropiados, información acerca de:

Los tipos de retorno y argumentos que reciben las funciones.
La forma de los objetos.
El tipo de ciertas variables modificadas a lo largo del curso del programa.

El sistema de tipos de TypeScript permite escribir código autodocumentado, es decir, el propio código expresa la forma de los objetos, el tipo de sus variables y los argumentos y valores de retorno de las funciones.

Esto es especialmente útil cuando trabajamos con librerías de terceros: de un vistazo podemos consultar los métodos y propiedades disponibles de los objetos que proporcionan.

🥇 La revolución ha comenzado

En 2007, Jeff Atwood enunció una frase que es conocida como la Ley de Atwoord:

Any application that can be written in JavaScript, will eventually be written in JavaScript.

Vista la adopción de TypeScript en los últimos años, como cada vez más empresas comienzan a escoger este lenguaje para sus desarrollos y la aparición de herramientas como Copilot (para las cuales un sistema de tipado es realmente útil), puede que tenga más sentido enunciarla del siguiente modo:

Any application that can be written in JavaScript, will first be written in TypeScript, and then compiled to JavaScript.

🙏🏻 Gracias a Garaje de Ideas

Los amigos de Garaje de ideas patrocinan Latte and Code y buscan talento: http://bit.ly/garaje-tech-talento

Mi experiencia personal

Como CTO de Legit.Health, hace dos años decidí migrar todo el código de nuestra aplicación a TypeScript. A día de hoy puedo decir que es una de las mejores decisiones que he tomado.

Su primera versión la escribimos con React y JavaScript. Dado que preveíamos que iba a crecer muy rápidamente, nos esforzamos por incluir la librería PropTypes en todos los componentes. Aunque fuera en tiempo de ejecución, al menos teníamos información relevante acerca de las propiedades. Sin embargo, esto no nos aseguraba que los hooks u otros elementos trabajasen con los valores correctos.

Conforme la aplicación crecía, resultaba cada vez más difícil trabajar en equipo y asegurar la consistencia de ciertas funcionalidades. Los bugs comenzaban a aparecer a medida que la demanda de funcionalidades crecía. Ya sabéis el ritmo de una start-up.

Fue en ese momento cuando decidí liarme la manta a la cabeza y migrar a TypeScript. El proceso fue sorprendentemente sencillo. Dado que es posible tener aplicaciones en donde convivan ambos lenguajes, pude ir migrando poco a poco cada una de las vistas y sus componentes.

Al poco tiempo de convertir el último archivo .js , las ventajas se hicieron evidentes:

El equipo creció en productividad, pues no era necesario consultar lo que recibía cada componente o si los tipos eran correctos.
Muchos bugs que teníamos gestionando eventos e interacciones desaparecieron y jamás han vuelto.
Pudimos exprimir al máximo librerías como React Query o React Router.

Y la consistencia entre backend y frontend creció enormemente, al poder declarar cada valor de respuesta.

Desde entonces, todas las aplicaciones que creamos en Legit.Health están escritas con TypeScript y, gracias a ello, mantener cada proyecto resulta muchísimo más cómodo gracias a ese beneficio inherente a TypeScript que es la autodocumentación.

Mi recomendación es la siguiente. Si vais a comenzar un proyecto que prevéis que alcanzará cierto tamaño, no os lo penséis: TypeScript es el camino.

Una historia de JavaScript (III)

Gerardo — Thu, 22 Sep 2022 07:52:26 GMT

Photo by Austin Chan on Unsplash

Por si te los perdiste, aquí tienes los enlaces a los otros dos artículos que componen esta serie:

Latte and Code

Una historia de JavaScript (I)

Se dice pronto, pero ya van más de 14 años sumergido en el desarrollo web. Esto significa que he podido vivir de primera mano la evolución que ha experimentado; desde los tiempos en que definíamos la estructura con tablas (sí, etiquetas table tal y como lo oyes) hasta la aparición de…

4 years ago · 10 likes · Gerardo

Latte and Code

Una historia de JavaScript (II)

Nuestra primera parte de la historia de JavaScript terminó con la llegada de los primeros frameworks para crear aplicaciones web. Pese a las mejoras que introdujeron, todavía tenían que lidiar con las complicaciones inherentes al lenguaje y a la ausencia de librerías que permitiesen llevar a cabo algo más que automatizaci…

4 years ago · 2 likes · Gerardo

Estamos a comienzos de 2017. React, Vue y Angular marcan el paso del desarrollo web y la forma en que creamos aplicaciones para navegador. Ya sólo es cuestión de tiempo que comiencen a aparecer frameworks basados en estas tecnologías. ¿Por qué es este el paso natural? Más allá de las diferencias que podemos encontrar entre cada uno de los frameworks de los que hablaremos, todos comparten un rasgo en común: estandarizan la forma en la que trabajamos con un conjunto de librerías, de modo que los proyectos creados con ellos parten de una base común. Esto resulta especialmente útil para empresas que gestionan varios proyectos a la vez y no pueden permitirse el lujo de plantear cada proyecto de una forma distinta.

Así que, los años 2017 y 2018 supusieron el inicio de esta última etapa, cuando Next.JS, Gatsby o Nuxt.js irrumpieron con fuerza dentro del panorama web. Por aquel entonces ya todos coincidíamos en que los componentes debían ser el núcleo primitivo de cualquier aplicación, de modo que era el momento de estandarizar otras partes: el enrutador, la estructura de carpetas, la gestión de llamadas asíncronas, etc.

Cada uno de estos frameworks recogieron los patrones de diseño más habituales en su ecosistema y comenzaron a ofrecer soluciones “todo en uno” que permitían abordar distintos proyectos bajo un mismo estándar.

Pero no se quedaron ahí.

A medida que los entornos en el servidor como NodeJS reducían la brecha con la ejecución de código JavaScript en el cliente, los frameworks vieron la oportunidad de llevar la optimización de las aplicaciones web a un nuevo nivel: el server side rendering.

Photo by CHUTTERSNAP on Unsplash

Server side rendering

El server side rendering es el conjunto de técnicas que permiten renderizar una página web completa en el servidor, de modo que el cliente recibe un HTML completo y no un mero un contenedor donde levantar la SPA. Salvando las distancias, es como funcionaban las páginas web antes de la llegada de Angular, React y el resto de librerías: el servidor es quien genera el HTML de la página y lo envía al navegador para que éste lo muestre.

Los frameworks de esta generación llevaron el SSR al siguiente nivel explotando las ventajas de generar el HTML en el lado del servidor: ocultar las claves de la API para ciertas solicitudes, modificar las cabeceras al devolver una página y, por supuesto, mejorar el eterno problema del SEO con las SPA’s. Un mundo de posibilidades acababa de abrirse y los grandes beneficiados fuimos nosotros, los desarrolladores. Por ejemplo, gracias al SSR es posible devolver páginas que funcionen independientemente de si el usuario tiene JavaScript activado. ¿Hace cuánto no os planteabais esto?

¿Hacia dónde vamos?

Si habéis hecho alguna página con Next.js o cualquiera de los frameworks que he mencionado, habréis visto lo sencillo que es no sólo crear aplicaciones, sino también desplegarlas. De hecho, ya ni tan siquiera es necesario disponer de conocimientos relacionados con las devops, pues soluciones como Vercel son capaces de correr una aplicación basada en estos frameworks con tan sólo tener acceso al repositorio.

Asimismo, año tras año los frameworks liberan funcionalidad que está sentando las bases para la llegada de una nueva forma de entender el desarrollo web. Hace apenas 3 meses (mayo de 2022), NextJS lanzó la versión 12.2 que, en sus propias palabras, establece el marco de referencia para el futuro de este framework: layouts anidados, server components, mejoras a la hora de obtener datos asíncronos y la adopción de las novedades introducidas por React 18 a la hora de trabajar con código asíncrono.

Viendo todo esto, creo sinceramente que vamos en la dirección correcta. Poco a poco las aplicaciones web están equiparándose a sus homólogas de escritorio y los entornos de desarrollo actuales no tienen nada que envidiar a los SDK’s que proporcionan los sistemas operativos para desarrollar aplicaciones nativas.

Retos como la accesibilidad o la recuperación de información del lado del servidor todavía tienen margen de mejora, pero gracias a la maduración del ecosistema, la comunidad está lista para abordarlos.

Tampoco podemos olvidarnos de los web components o WebAssembly, soluciones cuya validez sólo el tiempo determinará, pero que nos hablan de las posibilidades que se han abierto actualmente.

La buena noticia es que los tiempos en los que cada mes aparecía un nuevo framework o librería parecen estar tocando a su fin. Si antes teníamos 20 opciones a elegir para desarrollar un proyecto, la maduración que ha experimentado el entorno web en los últimos años ha reducido estas opciones permitiendo asegurar, a su vez, ciertos niveles de calidad y rendimiento que antes eran impensables.

En definitiva. Creo que estamos viviendo un periodo de transición hacia una nueva concepción del desarrollo web, donde los programadores tendremos un conjunto de opciones más reducidas en la forma de frameworks, pero que nos permitirán trabajar de una forma mucho más eficaz, óptima y seguro que divertida.

¡El futuro suena apasionante!

Suscríbete ahora

🙏🏻 Gracias a Garaje de Ideas

Los amigos de Garaje de ideas patrocinan Latte and Code y buscan talento: http://bit.ly/garaje-tech-talento

Manual de productividad para la vida diaria

Gerardo — Mon, 29 Aug 2022 13:10:42 GMT

Aprovechando el final de las vacaciones hoy he decidido escribir un artículo algo diferente a los que habitualmente publico por aquí. En él encontrarás una serie de consejos sobre productividad agrupados en los diferentes ámbitos que componen nuestras vidas.

Me he animado a escribir este artículo porque creo que es muy habitual asociar productividad a trabajo sin caer en la cuenta de que también podemos integrarla en nuestra vida personal con el fin de descubrir que el día tiene muchas más horas de las que pensábamos para disfrutar de nuestra familia, amigos y aficiones.

Como verás más adelante, en el artículo he recopilado un gran número de consejos. La lista comienza hablando de aquellos que creo que te pueden ayudar a ser más productivo en tu entorno laboral para poco a poco ir profundizando en el terreno personal, tema que es la verdadera razón de ser de este artículo.

Igual de primeras puedes pensar que la cantidad de consejos que menciono es abrumadora. De hecho, creo que sería de locos pensar que es posible seguir todos y cada uno de ellos (pareceríamos robots más que otra cosa). Por eso te animo a verlos como lo que son: consejos, no obligaciones. De ti dependerá escoger aquellos que te pueden servir de ayuda y cuales descartar porque sencillamente “no van contigo”.

Así que dicho esto, ¡comencemos!

Trabajando con el ordenador

Aquí encontrarás consejos que te ayudarán a ser más productivos cuando trabajes con un ordenador, algo que ya es un denominador común en gran cantidad de puestos de trabajo.

¿Un apartado para ésto? La verdad es que sí. Te sorprendería la cantidad de tiempo que perdemos por no estar familiarizados con el ordenador o por no conocer todas las herramientas de las que disponemos cuando trabajamos con él.

Incrementa la velocidad del ratón. Yo la tengo a casi el tope en mi Mac y la diferencia es abismal (aquí puedes ver como modificarlo si usas MacOS o Windows).
Apréndete los atajos de teclado de las aplicaciones con las que trabajes más a menudo. Photoshop, los entornos de desarrollo e incluso Office tienen gran cantidad de atajos de teclado que permiten realizar acciones de forma mucho más rápido sin tener que navegar por diversos menús.
Familiarízate con el buscador de tu ordenador o con el sistema de etiquetas. Encontrar las cosas más rápido siempre se agradece sin sentir que el desorden ha comenzado a invadir tu disco duro.
El escritorio vacío, por favor. Siempre que veo un escritorio abarrotado de archivos se me viene a la cabeza esas mesas llenas de papeles, archivadores y cajoneras repletas en el que buscar algo se convierte en misión imposible.
Si el ordenador es tu principal herramienta de trabajo, invierte en un buen ordenador que no tarde 2 minutos en arrancar o que se cuelgue cada vez que abres más de 3 pestañas en el navegador.
Asegúrate de tener una buena conexión a Internet, especialmente si eres autónomos o necesitas rapidez. Que las páginas se abran casi antes de pedirlas.
Un segundo monitor siempre es bien. Sobre todo si trabajas con un portátil. En cuanto veas las posibilidades de tener dos pantallas con sus distintas aplicaciones abiertas no querrás volver a trabajar con una solo.
Google es tu amigo. Diría que el 90% de los problemas comunes que se pueden presentar en un día de trabajo a alguien ya le ha pasado y ha tenido a bien de publicarlo. Por tanto, aprende a buscar en Google para encontrar soluciones rápidas a los problemas.
Y por favor, tener Whatsapp, Telegram, Twitter o cualquier otra red social abierta mientras intentas sacar adelante una tarea es como intentar trabajar en medio de una verbena de pueblo. Prográmate ventanas de tiempo para consultarlas pero evitar dejarlas en segundo plano sonando y distrayéndote.

Vida laboral

En este apartado he recopilado una serie de consejos de carácter general que te ayudarán a mejorar tu productividad en el trabajo sin importar a qué área o sector pertenezcas.

Estos consejos que encontrarás a continuación los he ido recopilando en base a mi experiencia desde que comencé a trabajar. Todos ellos los he puesto en práctica en algún momento u otro por lo que te puedo asegurar que la mejora que obtendrás es considerable y te dará la sensación de avanzar mucho más rápido.

Así que te propongo que escojas los que más compatibles veas con tu día a día y durante un mes los llevas a cabo, los resultados te sorprenderán (y no, prometo que no es un clickbait).

Haz pausas cortas cada hora. Trata de darte un paseo de 5 minutos, estira tus piernas. 6 horas seguidas sentado no es bueno para nadie y muchas veces esos mini descansos te permitirán aclarar tu mente si estabas enfrascado en algún problema.
Adiós a las reuniones interminables y planifica lo que hablaréis en ellas de cara no divagar e ir al grano. En mi opinión, más de una hora suele ser a menudo excesivo y la gente pierde la concentración.
¡Las tareas difíciles las primeras! Creo que este es el mejor consejo que te puedo ayudar. Comienza a trabajar primero en las tareas más duras ya que ahí es cuando estás repleto de energía y deja las sencillas para el final de la jornada (así de paso no te empantanarás en una tarea que te oblique a quedarte más tiempo del que debieras en la oficina).
Planifica tu día antes de empezarlo. Para mí es imprescindible tener claro lo que tengo que hacer cada día.
Evita los “¿tienes un segundo?”. Esto creo que es uno de los principales ladrones de productividad que existen y lo peor es que no somos conscientes.
Invierte en una buena silla si eres autónomo y aprende a coger una postura ergonómica. Yo estoy encantado con la Markus de Ikea pero para gustos los colores.
Come bien. He decidido añadir este consejo aquí porque de un tiempo a esta parte he comenzado a valorar la dosis de energía extra que provee una buena alimentación. Si no tienes tiempo (en mi caso casi nunca) existen opciones de tuppers preparados a buen precio y que se encargan de semana en semana.
El trabajo, cuanto más cerca de casa mejor. 2 horas de desplazamiento al día son 10 horas a la semana lo que en un mes nos lleva hasta las 40 horas, es decir, casi dos días de desplazamiento obligatorio (esta es la clave, por mucho que leas en el tren o veas series sigues estando obligado a invertir ese tiempo). Imagina la cantidad de tiempo que ganarías para ti trabajando cerca (de hecho, ésta es uno de las razones principales por las que prefiero trabajar como autónomo).
De nuevo, mantén tu escritorio organizado, pero esta vez el físico. Creo que no hay nada más anti-motivacional que sentarte a trabajar en un escritorio donde reina el desorden.
Familiarízate con el método de productividad “Gettings things done” o cualquier otro. Aprenderás a elaborar listas de tareas útiles y vaciarás la cabeza de información innecesaria como la típica: “me tengo que acordar de escribir a X”.
Y por favor, hazte un favor a ti mismo y cumple tu horario.

Suscríbete ahora

¡En movimiento!

Pasamos ahora a temas más mundanos. Porque no todo va a ser trabajo como te prometí al comienzo del artículo. En esta sección encontrarás consejos sobre cómo puedes mejorar tu desplazamientos o por lo menos aprovecharlos para que no sean “tiempo perdido”.

Salvo que seas un hombre de las cavernas lo más normal es que al día tengas que realizar 3/4 desplazamientos por la ciudad. Este tiempo como comentaba antes suele ser “tiempo perdido” pues al final se trata de ir un sitio a otro, ¿no? Sin embargo, creo que es posible aprovecharlo para realizar una tarea secundaria que nos permita enriquecernos. Aquí te dejo algunas ideas.

Acostúmbrate a caminar rápido y tómatelo como una dosis extra de ejercicio.
Muévete en transporte público, bicicleta o andando. Estas son mis 3 formas habituales de moverme por Madrid (de hecho no tengo coche) y estoy encantado. Tardo menos a los sitios, me ahorro el agobio de aparcar y de paso me sirven para estirar las piernas. ¿Se puede pedir más? Se que tendrás la tentación de incluir aquí el monopatín eléctrico pero soy de la opinión de que es más saludable una pequeña caminata que ir sobre ruedas sin hacer nada.
Dile adiós a los ascensores o escaleras mecánicas. Puesto que suele ser difícil sacar tiempo para practicar una hora al día de ejercicio, ¿qué tal aprovechar los tramos de escaleras para al menor ejercitar un poco el corazón y darle algo de actividad a cambio de las 8 horas que pasamos sentados?
Si por la razón que sea estás obligado a desplazarte en coche no intentes aparcar siempre al lado. Aparcar a diez minutos del sitio tampoco está mal y probablemente es el tiempo que inviertas en encontrar el sitio adecuado.

Un poco más de tiempo, por favor

Probablemente como a ti, una de las cosas que más me irritan es tener que hacer cola. Ese tiempo en el que tan sólo puedes mirar el móvil mientras miras a izquierda o derecha pensando si la otra cola es la más rapida…

Habiendo recordado este “placentero” momento aquí te dejo unos consejos con lo que igual puedes evitarte tener que esperar colas o realizar actividades a determinadas horas en donde todo transcurra de forma mucho más ágil.

Nota. Como habrás ido viendo, muchos de los consejos que ya he mencionado van destinados a combatir eso que yo llamo roba-tiempos, es decir, situaciones en las que caemos involuntariamente y que nos van quitando una cantidad de minutos lo suficientemente apreciable como para que, si pudiéramos evitarlos, tuviésemos de una hora más al día.

Aprovecha que muchas empresas ya tienen formas de pago alternativas para evitar esperar colas. Por ejemplo, los Día&Go ya poseen cajas automáticas al igual que Ikea. Además Starbucks ya permite comprar el café desde la aplicación y recogerlo al llegar la tienda sin tener que esperar o el mismo McDonalds posee tablets desde donde realizar tu pedido. En este tipo de casos cuanto menos tengamos que interactuar más rápido iremos.
Intenta hacer las cosas pensando como un outsider. Por ejemplo, ve a hacer la compra o al banco a horas distintas a las que va el grueso de la población. Menos gente, menos colas (de nuevo), más tiempo libre para ti.
También os podéis ahorrar algún que otro paseo gracias a Amazon / Amazon Prime o los servicios de riders que te traen a casa prácticamente cualquier cosa sin tener que moverte tú. En mi caso, todos los artículos de Simba los encargo online y me ahorro algún que otro paseo al veterinario.
Prescinde del coche. No hay nada más frustrante que un atasco matinal o la búsqueda de aparcamiento por lo que aprovecha las nuevas formas de desplazamiento y dales una oportunidad. Además, como comenté ya antes te servirá además para hacer un poco de ejercicio.

Suscríbete ahora

Productividad en casa

Otro de los ámbitos en los que podemos mejorar nuestra productividad es en las tareas de casa. Planchar, fregar, barrer… son actividades que generalmente nos resultan tediosas y habitualmente entran en la categoría de “roba-tiempos”.

A continuación podrás encontrar unos cuantos consejos que yo mismo he seguido desde que me independicé para que aprendas a gastar menos tiempo del necesario en este tipo de tareas. Desde mi experiencia te puedo asegurar que adoptarlos en tu rutina de limpieza y mantenimiento de tu casa te ayudará a disponer de más tiempo para otras actividades. Y sí además trabajas desde casa al igual que yo hago sentirás que tu espacio de trabajo está igual de limpio y ordenado que el de una oficina al uso (algo que para mí es imprescindible).

Mantén un orden. Asegúrate de que las cosas se encuentren donde se las espera y no tengas que pasar tiempo buscándolas.
Si puedes permitírtelo, delega aquellas tareas que a ti te cueste más realizar. Esto fue una de las primeras cosas que asumí cuando me independicé. Generalmente facturo por horas a las empresas con las que trabajo por lo que haciendo cuentas me resulta “más rentable” contratar a alguien que me ayude con las tareas básicas en vez de invertir yo mi tiempo en realizarlas. Esa “rentabilidad” de hecho no es necesario que la midáis en dinero sino que también podéis valorarla en tiempo libre para vosotros.
No vayas a hacer la compra cuando estés hambriento. Seguramente gastes más dinero y tiempo escogiendo productos que tu estómago está deseando digerir cuando realmente muchos de ellos ni siquiera los tenías apuntados en tu lista.
No dejes la televisión encendida durante las cenas (salvo que vivas sólo). Acostúmbrate a hablar con tu familia o personas con las que compartes piso en vez de dejar que Netflix te resuelva esa tarea.
Intenta acostumbrarte a no posponer la alarma. Generalmente esos minutos extra no son tan beneficiosos como a veces pensamos y te ayudarán a formar una rutina.
Acostúmbrate a terminar las duchas con agua fría, te ayudará a despejarte y activará tu circulación (se que en invierno es más difícil).
Adquiere productos que automaticen ciertas tareas. Hace poco le regalamos a mi madre una Rumba y está encantada y yo estoy planteándomelo para tener el suelo más despejado de pelos de mi perro.
No te obsesiones con la limpieza. Se requiere de mucho esfuerzo y dedicación tener una casa limpia y lo más probable es que al día siguiente aparezca de nuevo polvo. Mi consejo es que te marques un mínimo asumible y te acostumbres a mantenerlo. En mi caso es evitar que haya pelos de mi perro en el suelo, tener el fregadero limpio antes de terminar el día y bajar la basura cada dos días.

¡Fórmate!

Una de las actitudes que nunca deberíamos perder es la de seguir aprendiendo cosas, pues sólo de esa manera seguiremos progresando en nuestros objetivos personales a la vez que sentimos que progresamos como personas.

Me considero una persona muy curiosa. Amenudo leo libros sobre campos que nada tienen que ver con mi especialidad (por ejemplo, recientemente terminé uno que me encantó sobre la evolución humana de Juan Luis Arsuaga) y me encanta seguir formándome en mi área de especialidad (desarrollo de webs y aplicaciones). Y cada vez que adquiero un nuevo conocimiento siento que he progresado un poco más, por lo que desde aquí te animo a que nunca dejes de formarte.

A continuación te dejo algunos consejos que te pueden ayudar para que tú también puedas seguir aprendiendo.

Fórmate en lo que realmente te interesa. Muchas veces la sociedad nos “impone” aquello que debemos aprender, pero no hay peor alumno que el que no tiene interés por lo que está aprendiendo.
Si necesitas aprender algo para mejorar tu posición laboral no te lances de cabeza al máster que ahora mismo es tendencia sino escoge aquello que mejor equilibra tu motivación con los supuestos beneficios laborales que te reportará. De otro modo acabarás quemado.
Reserva un espacio de estudio donde aprender aquello que hayas escogido. Puede ser un rincón tranquilo de tu casa o una cafetería, pero asócialo en tu mente como tu “rincón de aprendizaje”.
Relaciona todo aquello que vas aprendiendo. Muchos campos están relacionados de maneras que no imaginamos y conocer estas relaciones ayudan a tener una visión más global de cómo funciona el mundo.
Mantén un diario de aprendizaje en donde vayas recopilando aquellas cosas que vas aprendiendo. Esto generalmente sirve para mantener la motivación a medida que vas rellenando hojas.
Intenta contactar con expertos en lo que estás aprendiendo. Mucha gente está deseando compartir sus conocimientos con otros por lo que pierde la vergüenza y anímate a escribirles un correo con tus dudas (o incluso agredicimientos).
Trata de aprender siempre algo nuevo. Poco más que decir. Para mí es el principal consejo que puedo darte sobre este tema.

Productividad en el día a día

Y finalmente llegamos al punto más importante de este artículo ya que como decía al principio del artículo, la productividad no sólo debemos verla como una forma de rendir en el trabajo, sino que también nos puede ayudar a mejorar en nuestro día a día.

Por eso a continuación he hecho una pequeña mezcla tanto de consejos puramente de productividad como de otros que están relacionados con el bienestar pero que, si los seguimos, nos harán estar más despejados y motivados para cumplir con todo aquello que nos propongamos.

Espero que os resulten interesantes y que os ayuden a crecer y a mejorar en vuestro día a día.

Viaja dos veces al año a sitios que no conozcas. Nada inspira más que salir de la zona de confort de vez en cuando y descubrir sitios nuevos. Las buenas ideas generalmente surgen cuando no estamos metidos de lleno en la rutina diaria.
Encuentra tu “reason why”, “ikigai” o como quieras llamarlo pero establece tu propio proyecto vital y decide hacia donde vas a dirigir tus pasos. El verano suele ser una buena época para tratar de averiguarlo.
Aprende a meditar. Reserva 10 minutos al día para estar contigo mismo sin ningún tipo de estímulo externo. Lo agradecerás y más ahora que estamos imbuidos en un constante bombardeo de notificaciones.
Practica algún deporte o yoga. Ya sabes eso de “mens sana in corpore sano”. Creo que nada ayuda más a ser productivo que estar en una aceptable condición física. Además también te permitirá liberar todo el estrés acumulado.
¡¡¡¡¡¡Prioriza!!!!!!!! Por desgracia el día tiene 24 horas y es imposible prescindir del sueño así que escoge aquello a lo que te quieres dedicar y aprende a renunciar a aquellas actividades que te encantaría hacer pero para las que no tienes tiempo en ese momento de tu vida.
Reserva los últimos 15 minutos antes de dormir sin móvil ni pantallas. A mí personalmente me cuesta más conciliar el sueño si voy directo del ordenador o el iPad a la cama.
Aprende a delegar. Confía en los demás y no trates de hacerlo tú todo siempre.
Tómate un descanso de vez en cuando. Además de los fines de semana siempre es necesario desconectar y liberarnos del “peso” de la rutina del día a día. Tener una mente clara es imprescindible si queremos seguir mejorando tanto en nuestra vida personal como en la laboral. Y bueno, el cuerpo también necesita descansar de vez en cuando.
Queda con gente. Trata de hacer planes, expandir tu grupo de amigos… Por suerte las redes sociales y aplicaciones como Meetup ayudan mucho en esta tarea y ayudan a compartir tus intereses con gente como tú.
Escucha a ese gente. No te cierres en banda en tus opiniones. Por mucho que digan no hay verdades absolutas sobre ningún tema. Aprende a debatir y enriquecerte con la opinión de aquellos que no piensan como tú. No crees tu “campana de eco”.
Cuida tu salud. Como sospecharás, en un mal estado de salud o físico es imposible acometer nada. Cuídate de estar en plena forma y reserva un día al año para ese chequeo físico que siempre te da pereza hacerte.
Lee. Quiero terminar el artículo animándote a que no pierdas el interés por la lectura. No hay nada mejor en mi opinión para desconectar y descubrir nuevos mundos.

🙏🏻 Gracias a Garaje de Ideas

Los amigos de Garaje de ideas patrocinan Latte and Code y buscan talento: http://bit.ly/garaje-tech-talento

Y recuerda…

Señor, dame fuerza para cambiar lo que puedo cambiar, la serenidad necesaria para aceptar lo que no puedo cambiar, y la sabiduría para distinguir entre ambas.

Una historia de JavaScript (II)

Gerardo — Mon, 18 Jul 2022 09:14:25 GMT

Photo by Ross Findon on Unsplash

Nuestra primera parte de la historia de JavaScript terminó con la llegada de los primeros frameworks para crear aplicaciones web. Pese a las mejoras que introdujeron, todavía tenían que lidiar con las complicaciones inherentes al lenguaje y a la ausencia de librerías que permitiesen llevar a cabo algo más que automatizaciones (Grunt, Gulp…).

Esta situación dio un giro de 180 grados entre 2013 y 2015. Si tuviéramos que preguntarnos qué provocó la revolución del desarrollo web, deberíamos dirigir sin dudar la mirada a esos años. Webpack, la especificación ES6 de JavaScript y ReactJS los cambiaron todo.

Webpack

Hasta la publicación de Webpack, no había forma de entender los recursos de una web como un todo. Las imágenes, fuentes, archivos CSS y, por supuesto, JavaScript eran compartimentos estancos. Por ejemplo, si queríamos usar una imagen dentro de un archivo JavaScript, era nuestra responsabilidad especificar su path dentro del proyecto.

document.getElementById("myImg").src = "happy-dog.jpg";

Y si un archivo CSS estaba asociado específicamente a un widget de JavaScript, teníamos que asegurarnos de que ambos archivos eran cargados en el HTML final.


...

...

El caos estaba servido. Si a eso le sumamos que cada archivo de JavaScript incluido en el DOM compartía variables con el resto de archivos, la fiesta estaba servida.

// first.js
var colorCodes = {
  back  : "#fff",
  front : "#888",
  side  : "#369"
};

// second.js
alert(colorCodes.back); // alerts `#fff`

Sí, había “task runners” como Gulp o Grunt que nos permitían automatizar ciertas tareas (minificar, generar el HTML, …), pero eran incapaces de ver los componentes como parte de un un todo.

Y entonces llegó Webpack para, por fin, permitirnos relacionar elementos, independientemente del tipo que fuesen. Su idea era muy sencilla: entender cada elemento (ya fuera una fuente, un archivo CSS, una imagen o un archivo JavaScript) como un módulo y generar a partir de ellos los “assets” finales de la aplicación.

Webpack era capaz de ver las dependencias entre los diferentes elementos y generar un árbol de dependencias que permitiese optimizar la generación de los estáticos. Y gracias a la sintaxis import de ES6, las variables definidas dentro de cada uno de los archivos permanecía aislada del resto.

En resumen, algo tan habitual en 2022 como:

import bg from './bg.jpg';
import styles from 'Component.module.css';
import View from './View';

no fue posible hasta que apareció esta librería.

ES6

Para que Webpack pudiese mostrar todo su potencial necesitó que JavaScript estandarizase la forma de definir módulos, es decir, compartimentos estancos dentro de la aplicación cuyas variables fueran invisibles para el resto.

No sólo eso. Hasta 2015 JavaScript todavía vivía anclado en una sintaxis antigua que ponía enormes dificultades a la hora de trabajar con objetos, cadenas de texto o código asíncrono.

La publicación de ES6 o ECMAScript 2015 resolvió todos estos problemas de golpe:

Aparecieron las arrow functions para facilitar la creación de funciones de una línea y simplificar el uso de this.
La clases fueron incorporadas al lenguaje.
Aparecieron los template strings, los cuales nos permitían interpolar variables sin necesidad de recurrir al operador + para concatenar strings.
Se añadieron let y const como una nueva forma de definir variables.
Las promesas llegaron por fin al lenguaje (y sí, también los generadores).
Se incluyeron azucarillos sintácticos como la desestructuación, el operador rest/ spread,. etc para trabajar con objetos.
Y se permitió la creación de módulos mediante la sintaxis import / export.

Si a estas alturas es imposible resumir lo que significaron cada una de estas novedades por separado, imaginad lo que supuso la llegada de todas ellas de golpe. El lenguaje y la forma en que lo usábamos para escribir aplicaciones había cambiado para siempre.

Babel

Todas estas características molaban mucho. El problema es que los navegadores no las acogieron inmediatamente, sino que se tomaron su tiempo en integrarlas o directamente prefirieron no hacerlo (ejIEm). Teníamos un Ferrari en nuestras manos limitado a 80 km/h.

Para resolver este problema apareció Babel, una librería que transpilaba código “nuevo” a código antiguo, de modo que teníamos que preocuparnos de si la “build” final sería compatible con los navegadores donde iba a correr.

Por supuesto, se integraba a la perfección con Webpack, por lo que ambas formaron un dúo que nos permitieron aprovechar al máximo todas las novedades que ES6 trajo consigo.

ReactJS

Webpack y ES6. Ahora sí teníamos todas las herramientas para crear sistemas que exprimieran el lenguaje. Podíamos importar archivos CSS dentro de JavaScript, declarar promesas para librarnos de los callbacks y ya no teníamos que lidiar con los problemas de la declaración de variables con var.

El problema era que por aquel entonces no teníamos muy claro dónde debía vivir el estado de nuestra aplicación. O más bien. No nos importaba. Que levante la mano quien no haya recurrido a los atributos data- para dejar valores en el DOM que luego pudiera leer JavaScript.

Resulta curioso, porque algo tan importante como es tener claro dónde consultar el valor de un elemento no nos preocupaba. Bueno, al menos a mí 🫣. Por ejemplo, el estado de un campo en el formulario vivía a veces en el DOM, otras veces en JavaScript y otras… pues a la vez.

ReactJS llegó para poner orden a esto. Su propuesta fue la siguiente: "A partir de ahora, el estado vivirá exclusivamente en JavaScript, y siempre que cambie, pintaremos de nuevo la interfaz”. En resumen, sólo había un camino de ida para el estado, de JavaScript hacia el HTML. Nunca de vuelta.

La vista pasó a ser una función del estado. f(s) = v.

Tras esta idea aparecieron dos elementos que conformarían los pilares básicos sobre los que se asentó React:

Los componentes, que permitían partir una interfaz en elementos más pequeños con su propio estado y ciclo de vida.
El Virtual DOM, encargado de optimizar el proceso de “repintado” de la vista en función de los cambios producidos.

Es cierto que frente a la idea propuesta por React, frameworks como Angular 2 siguieron apostando por el estado de doble sentido. Sin embargo, tener un único sentido para las modificaciones del estado simplificaba enormemente los casos de uso, motivo que puede estar detrás de la espectacular acogida que tuvo la librería.

Componentes y vistas

El camino que abrió React motivó la aparición de otros frameworks y librerías que apostaron por la idea de partir una interfaz en componentes.

La idea básica detrás de ellos era enfocarse en resolver el problema de la representación de la vista de una forma óptima.

Esa fue la razón de que ReactJS, por ejemplo, no incorporase ningún elemento adicional como un enrutador o su propio sistema para gestionar peticiones asíncronas. Acotar el alcance del problema a la vista permitía centrar los esfuerzos en mejorar el rendimiento que suponía pintar interfaces dinámicas con un estado sujeto a cambios.

Esta misma simplicidad permitió que fuese mucho más fácil adoptar estas librerías. Si querías crear un widget o web con una sola vista el desarrollo a partir de ellas era extremadamente simple.

En el otro extremo de la balanza, dejar el resto de elementos de una web a la decisión del desarrollador provocó que cada proyecto estuviera organizado de una forma y usase sus propios “estándares”. No era raro abrir dos proyectos de React y encontrarnos con dos estructuras de carpetas, librerías de enrutado o estándares de código distintos.

Además, pese al auge de estas librerías, había otro gran problema. El SEO. Las webs construidas sobre ellas delegaban por completo la generación de la vista a JavaScript. Esto significaba que las arañas de Google y compañía veían al llegar una página en blanco, dado que no ejecutaban sus scripts. Podías tener la mejor web del mundo, que si Google no te veía no eras nadie.

Estos dos problemas dieron pie a la última parte de nuestra historia: la aparición del Server Side Rendering y de una nueva generación de frameworks que, desarrollados sobre estas librerías, establecían un patrón común para crear aplicaciones.

🙏🏻 Gracias a Garaje de Ideas

Los amigos de Garaje de ideas patrocinan Latte and Code y buscan talento: http://bit.ly/garaje-tech-talento

Continuará…

En el siguiente y último episodio hablaremos de la aparición de Next, Nuxt , y el resto de frameworks para el desarrollo de aplicaciones web que están llamados a marcar el paso en los próximos años.

💛 ¡Muchas gracias por leerme! Suscríbete gratis para recibir nuevas publicaciones y apoyar mi trabajo.

Una historia de JavaScript (I)

Gerardo — Mon, 27 Jun 2022 08:43:08 GMT

Photo by Osman Rana on Unsplash

Se dice pronto, pero ya van más de 14 años sumergido en el desarrollo web. Esto significa que he podido vivir de primera mano la evolución que ha experimentado; desde los tiempos en que definíamos la estructura con tablas (sí, etiquetas table tal y como lo oyes) hasta la aparición de frameworks que nos permiten hacer cosas que eran impensables unos años atrás.

Por el camino también he vivido intensos debates. ¿Dónde debe ir el CSS? ¿Y el estado? ¿Angular, React o Vue? Y, por supuesto, el vértigo de sentir que desde hace unos años es imposible mantenerse 100% al día.

Recuerdo que uno de mis proyectos serios lo desarrollé con Drupal (PHP). Eran los tiempos de los grandes monolitos, en los que el servidor se encargaba de procesar la petición y generar el correspondiente HTML con todo el CSS y JS necesario.

Técnicas como las que usaba Tuenti para permitir navegar sin recargar la página parecían magia; el común de los mortales nos contentábamos con usar las llamadas AJAX (Asynchronous JavaScript And XML) para a enviar formularios y filtrar listas.

Y entonces apareció AngularJS. Y todo cambió. Al menos pa mí.

Hoy quiero repasar contigo el proceso de cambio que nos ha llevado hasta aquí. Ninguno de nosotros creo que podamos adivinar el futuro del desarrollo web, pero conocer el pasado puede que nos ayude a tomar consciencia de los cambios que impulsaron los grandes saltos.

JavaScript. Los inicios

JavaScript fue lanzado en 1995 con el objetivo de proporcionar un lenguaje que permitiese definir interacciones complejas con el navegador.

En sus primeros años JavaScript tuvo que enfrentarse a las distintas implementaciones que hacían los navegadores de este lenguaje así como a las limitaciones que presentaba a la hora de trabajar con los elementos del HTML.

Sin embargo, dos cambios le devolvieron la popularidad y el interés de la comunidad:

La estandarización del DOM y su adopción por la European Computer Manufacturers 'Association (ECMA).
La aparición del objeto XMLHttpRequest que definía una manera común de realizar llamadas al servidor sin recargar la página (AJAX).

A partir de ese momento surgieron librerías que simplificaron enormemente el uso de JavaScript. JQuery, como imaginarás, es la más famosa. No sólo proporcionaba multitud de métodos que hacían más fácil interactuar con el DOM, también resolvía el problema de incompatibilidades entre navegadores. Cosas tan básicas como la gestión de eventos eran tratadas de forma distinta en Internet Explorer y Netscape, lo que obligaba a adaptar manualmente el código al navegador en donde se iba a ejecutar.

Sin embargo, el uso de JavaScript se reducía a la implementación de widgets y elementos de interfaz. La lógica de la aplicación y otros aspectos como el enrutado o la generación del HTML mostrado todavía vivían en el lado del servidor. Tampoco existía el concepto de módulos lo que significaba que todo el JavaScript era global (salvo que recurrieras a patrones como los módulos basados en IIFE’s). Y, por supuesto, tampoco contábamos con herramientas para empaquetar el código, realizar tareas sobre él (minificarlo, por ejemplo) o gestionar paquetes. Grunt, Bower o NPM tardaron bastantes años en aparecer. De Webpack ni hablamos.

Esta situación contrastaba con la que permitían las aplicaciones móviles. Objective-C en iOS y Java para Android proporcionaban las herramientas necesarias para definir la lógica de la interfaz en el lado del cliente. También aseguraban un sistema de navegación que no implicaba múltiples recargar y, lo más importante, la comunicación entre la aplicación y el servidor se reducía al intercambio de información para generar las vistas. El servidor quedaba liberado de generar la parte de la vista.

Para cuando entramos en la segunda década del siglo XXI algo cambió. Google demostró que era posible construir aplicaciones de escritorio usando páginas web (Google Docs, GMail…) y redes sociales como Facebook o la ya mencionada Tuenti comenzaron a implementar funcionalidades más complejas como chats o el uso intensivo de llamadas AJAX para gestionar la vista y el enrutado de la aplicación.

No obstante, la mayoría de las aplicaciones webs seguían limitadas a tener una carpeta assets donde depositar el JavaScript y las librerías. No había una forma estandarizada de manejar el estado de la vista ni los datos que mostraban.

Hasta que aparecieron los primeros frameworks.

Los primeros frameworks

La llegada de 2010 supuso la aparición de distintos frameworks que permitían escribir aplicaciones web completas en el navegador. El listado es bastante amplio aunque, probablemente, casi ninguno de ellos te suene si llevas menos de 5 años dentro de este mundo:

Estos frameworks fueron los encargados de abrir el camino para todo lo que vendría después. Su principal objetivo era popularizar el concepto de SPA (Single Page Applications), es decir, webs donde, al igual que ya sucedía en las aplicaciones nativas para móviles, la comunicación con el servidor se limitaría al intercambio de información.

Recibieron numerosas críticas, muchas de ellas fundamentadas. Eran los tiempos en los que el SEO era una piedra angular de cualquier proyecto y, desarrollar aplicaciones basadas por completo en JavaScript, suponía que los crawlers no pudieran inspeccionar la página. Además, los navegadores no eran tan veloces como pueden serlo ahora, de modo que el rendimiento era significativamente peor comparado con el sistema tradicional basado al 100% en el servidor.

Estos años también supusieron el lanzamiento de herramientas que revolucionaron la forma en que construíamos la carpeta assets que albergaba el CSS y JavaScript de la aplicación.

NodeJS fue liberado en 2009. Al año siguiente se publicó la primera versión de NPM, el famoso gestor de paquetes que vino a terminar de un plumazo con la descarga manual de librerías y el problema que suponía el control de versiones. CommonJS y AMD competían para establecerse como la manera estándar de definir módulos en las aplicaciones y así evitar que todo fuera global. Aparecieron los primeros preprocesadores de CSS como SASS y LESS. Y, herramientas como Grunt o Gulp nos permitían definir tareas para construir la versión final de nuestros assets; ambos serían a la postre los precursores de WebPack.

De esta época creo que todos aprendimos muchísimo. Siempre digo que a día de hoy puedo llamarme fullstack gracias a que viví este periodo de innovación en el que poco a poco backend y frontend se iban separando. Aún así, todavía lidiábamos con numerosas limitaciones:

JavaScript no era un lenguaje maduro como puede serlo a día de hoy. Por ejemplo, carecía de una forma óptima para lidiar con todo ese código asíncrono que poco a poco comenzaba a ser el núcleo de las aplicaciones.
Como ya he comentado, el rendimiento de las SPA’s todavía no era el esperado. Sin herramientas como WebPack, estábamos obligados a enviar la gran parte del código en la primera carga, lo que suponía mayores tiempos de espera hasta que el usuario podía comenzar a usar nuestra aplicación.
HTML también comenzaba a mostrar sus limitaciones al no implementar un sistema de plantillas que permitiera separar en componentes cada una de las partes de la interfaz.
Y, pese a la aparición de Grunt o Gulp, se hacía necesario herramientas más poderosas que permitiesen trabajar de forma conjunta con los distintos tipos de assets que componen una aplicación.

Pese a todo, fue una época increíble, llena de avances que permitieron vislumbrar el potencial que encerraban los navegadores y la separación de conceptos.

Entonces, alguien redescubrió el átomo. Apareció la primera versión ReactJS.

🙏🏻 Gracias a Garaje de Ideas

Los amigos de Garaje de ideas patrocinan Latte and Code y buscan talento: http://bit.ly/garaje-tech-talento

Continuará…

En el siguiente episodio hablaremos de la aparición de React, la revolución que supuso entender las interfaces como un conjunto de componentes y el desarrollo de la segunda generación de frameworks para construir aplicaciones web.

💛 ¡Muchas gracias por leerme!

Paginación: todo lo que necesitas saber

Gerardo — Thu, 02 Jun 2022 08:09:30 GMT

Photo by Ben White on Unsplash

Cuando en un proyecto nos piden que paginemos los elementos de una lista generalmente no solemos tardar mucho, ¿verdad? Lo primero que hacemos es escribir una consulta de este estilo:

SELECT .... LIMIT limit, offset

Y, a continuación, diseñar una UX que a todos nos sonará:

Sin embargo, tengo una mala noticia: este tipo de paginación no resuelve todos los casos de uso que tienen lugar dentro de un mundo plagado de scrolls infinitos y actividad en tiempo real.

Hoy quiero explicarte las limitaciones de la paginación “de andar por casa” y los sistemas alternativos que podemos emplear para superarlas.

Paginar con “limit, offset”: quizás una mala idea

Supongamos que tenemos una lista de fotos (al más puro estilo Instagram) que queremos mostrar de manera paginada con scroll infinito y con las más recientes al principio.

Seguramente la solución que se nos venga a la cabeza para mostrar la primera página sea una consulta de este tipo:

SELECT * FROM photo ORDER BY createdAt DESC LIMIT 0, 10

La cual nos devolverá las 10 primeras imágenes más recientes. Hasta aquí todo bien.

Ahora supongamos que el usuario baja hasta el final de modo que tendremos que cargar las 10 siguientes imágenes. Nuestra consulta para obtener las siguientes 10 fotos será:

SELECT * FROM photo ORDER BY createdAt DESC LIMIT 10, 10

¿Qué sucede si entre medias un usuario B añadió una nueva foto? Pues que el usuario verá una imagen duplicada: la nueva foto estará en la primera posición y empujará la décima foto a la posición undécima. Es decir, volveremos a obtenerla en la consulta:

La situación sería incluso peor si se pueden eliminar elementos de la lista. Si el usuario B elimina un elemento de la primera página y el usuario A solicita a continuación la segunda página el elemento undécimo no será visible pues la paginación lo saltaría. Imaginad que esto sucede en una aplicación de mensajería: desastre al canto.

Así que, cuando nos veamos tentados de emplear este tipo de paginación, deberemos de valorar tanto la concurrencia como la gravedad que supone para nuestra aplicación que estos casos sucedan. Por ejemplo, quizás para en un blog básico sea muy improbable que suceda y en el caso de darse no sería muy dramático, por lo que podemos beneficiarnos de la rapidez con que se implementa el anterior sistema.

Sin embargo, si no podemos asumir estos inconvenientes, deberemos implementar una paginación más estable.

Paginación estable

El problema que hemos visto radica en que el sistema de paginación anterior depende de los valores volátiles limit y offset, los cuales provocan cierto grado de inestabilidad cuando añadimos concurrencia. Una posible solución pasaría por escoger un valor que sea estable a lo largo del tiempo y emplearlo para paginar a través de él. En nuestro ejemplo de las fotos podría ser la fecha de creación de la foto.

A partir de ahí, cuando queramos recorrer las páginas, en vez de pasar a la consulta el número de página que queremos extraer, pasaremos la fecha de la último foto que se ha devuelto:

SELECT * FROM photo WHERE createdAt < previousDate LIMIT 10

De este modo estaremos seguros de que el usuario siempre verá el conjunto de fotos posteriores a la última que vio…

Salvo que dos fotos tengan la misma fecha.

Una forma de resolver este problema sería modificar la consulta para obtener todas las fotos con fecha igual o anterior a la que recibamos y luego filtrar las repetidas (🚨ñapa del 15 y lo sabes).

SELECT * FROM photo WHERE createdAt <= previousDate LIMIT 10

Otra solución sería emplear el id de la foto (siempre que sea incremental) como elemento sobre el que paginar, lo cual nos aseguraría no tener elementos repetidos tras la consulta.

👉 Uno de los inconvenientes que tiene este método (así como el que describiré a continuación) es que no vamos a poder tener paginadores de este estilo:
[<<] [<] [1] 2 [3] ... [>][>>]
No obstante, si estamos implementando una paginación por scroll infinito en la que el usuario no puede saltar entre páginas esto no es un problema.

Este tipo de paginación se denomina paginación basada en cursor y es en la que se va a centrar el resto del artículo.

Paginación basada en cursor

Si observas este esquema:

El problema de mostrar elementos duplicados o perderlos cuando en paralelo se añade o se eliminan elementos quedaría resuelto si pudiéramos especificar a partir de qué elemento queremos obtener los resultados. De este modo, no importaría cuántos elementos se añadiesen al comienzo de la lista ya que nosotros dispondríamos de un cursor estable apuntando exactamente al lugar desde donde queremos seguir obteniendo resultados.

Este tipo de paginación se basa en un elemento denominado cursor que es una especie de identificador que representa una ubicación dentro de una lista paginada.

Por tanto, cuando queramos obtener datos, necesitaremos especificar dos parámetros:

El cursor desde donde empezar
Y el número de datos que queremos obtener.

Como por ejemplo:

// Front page
https://myapi.com/// Siguiente...
https://myapi.com/?after=t3_49i88b&limit=30// Siguiente...
https://myapi.com/?after=t3_49kej9&limit=30

En este caso, el parámetro after indicaría el cursor desde dónde queremos seguir obteniendo datos y limit haría las veces de LIMIT , es decir, el número de resultados que queremos obtener.

Implementación de paginación basada en cursor

La forma más sencilla de implementar una paginación estable es escoger un cursor invariante a lo largo del tiempo y extraer los datos mediante consultas de este tipo:

SELECT * FROM posts
WHERE created_at < $after
ORDER BY created_at LIMIT $page_size;

Para posteriormente devolver los resultados de este modo (en el caso de que, por ejemplo, estemos implementando una API REST):

{
  cursors: {
    after: 23492834 // cursor que "representa" el último elemento
  },
  posts: [ ... ]
}

Analicemos esta respuesta:

La propiedad post contiene el array de posts.
La propiedad cursors contiene una propiedad llamada after con el valor del cursor que tendremos que pasar en la siguiente llamada para obtener la siguiente tanda de resultados.

Ejemplo de paginación en Twitter

Como sabéis, en Twitter el feed se va rellenando conforme la gente a la que seguimos publica sus tweets, por lo que parece claro que deben emplear un sistema de paginación similar al de cursores.

De hecho, para realizar búsquedas de tweets a través de su API, las llamadas tienen esta forma:

https://api.twitter.com/1.1/search/tweets.json?q=php&since_id=24012619984051000&max_id=250126199840518145&result_type=recent&count=10

Es decir, empleamos el parámetro count para delimitar el número de resultados que queremos y el parámetro since_id para especificar a partir de qué tweet queremos obtener los resultados.

Para esa consulta, el resultado devuelto incluye el campo search_metadata con la siguiente información:

"search_metadata": {
    "completed_in": 0.047,
    "max_id": 1125490788736032770,
    "max_id_str": "1125490788736032770",
    "next_results": "?max_id=1124690280777699327&q=from%3Atwitterdev&count=2&include_entities=1&result_type=mixed",
    "query": "from%3Atwitterdev",
    "refresh_url": "?since_id=1125490788736032770&q=from%3Atwitterdev&result_type=mixed&include_entities=1",
    "count": 2,
    "since_id": 0,
    "since_id_str": "0"
  }

Si te fijas, en el objeto aparece una url que podemos consumir para obtener la siguiente página ( next_results ) así como el max_id de los resultados devueltos. La llamada completa podéis verla en este enlace.

Relay cursor connections

Con la llegada de GraphQL, apareció una especificación genérica para realizar este trabajo con cursores. La librería Relay de Facebook nos proporciona una implementación: los Relay Cursor Connections.

https://facebook.github.io/relay/graphql/connections.htm

Esta especificación es verdaderamente útil. Se encarga de generalizar el concepto de cursor y establece un estándar para llevar a cabo las peticiones paginadas y el formato de las respuestas. Para que os hagáis una idea, aquí tenéis el aspecto de una query en GraphQL:

{
  allNews(first: 3, after: "YXJyYXljb25uZWN0aW9uOjI=") {
    pageInfo {
      startCursor
      endCursor
      hasNextPage
    }
    edges {
      node {
        id
        title
        body
      }
      cursor
    }
  }
}

Las principales características de este formato son las siguientes:

Usa la clave pageInfo para obtener información acerca de la página actual, por ejemplo si hay más páginas. Sin embargo, no se devuelve el número total de elementos ya que teóricamente los clientes de Relay no necesitan esa información.
Usa la clave edges para obtener el array de resultados, conocidos como nodos.
Cada resultado posee la información del nodo y su propio cursor. Es decir, cada elemento es devuelto junto con su propio cursor de cara a facilitar la navegación por páginas (por ejemplo, podríamos realizar la siguiente consulta partiendo desde el medio).

Finalmente, pese a que esta especificación surgió para trabajar con GraphQL, no necesariamente tenemos que ceñirnos a este lenguaje por lo que podemos portarla a una API Rest fácilmente. Es decir:

Relay tan solo generaliza el concepto de cursor y nos presenta un contrato entre cliente y servidor acerca del modo en que se paginan los resultados.

💛 Gracias a Garaje de Ideas

Los amigos de Garaje de ideas patrocinan Latte and Code y buscan talento: http://bit.ly/garaje-tech-talento

Conclusiones

Tras analizar los distintos métodos de paginación, mi opinión es que debemos escoger el que mejor se adapte a la aplicación que estemos desarrollando.

Las principales diferencias entre ellos son las siguientes;

En la paginación por offset, la ordenación podemos realizarla a través de cualquier columna. En la paginación por cursor, los resultados son ordenados siempre en función del campo empleado para crear el cursor.
La paginación por offset contiene tanto los números de páginas como los enlaces al anterior y al siguiente. En la paginación con cursores no es posible saltar entre páginas debido a la naturaleza dinámica de los datos a devolver.
La paginación por offset permite la navegación es ambos sentidos (la dirección es la misma 🤓 ). En la navegación por cursores lo más habitual es emplearla para ir hacia delante.

En resumen, para un MVP nos basta con adoptar el sistema basado en números de página ( LIMIT y OFFSET ) pues la rapidez en implementarlo es un claro punto a su favor.

Por el contrario, para aplicaciones más complejas que involucren mucho dato en tiempo real, la paginación mediante cursores es una mejor opción; no en vano es la que emplean aplicaciones como Twitter y Facebook.

💛 Muchas gracias por leerme!

Los nombres tienen poder

Gerardo — Tue, 10 May 2022 08:43:57 GMT

Photo by Alex Moiseev on Unsplash

Desde hace un par de años, una de las cosas a las que más atención presto mientras programo es a la elección de nombres. Cada vez soy más consciente de que trabajar en equipo implica, entre otras muchas cosas, facilitar la vida al siguiente desarrollador que tenga que trabajar con mi código. Y eso pasa por encontrar nombres descriptivos para funciones, variables y el resto de elementos de la aplicación.

Existe un momento en la vida de cualquier programador en el que una idea crece dentro de él: “lo breve y comprimido es mucho mejor”. Es decir, que esto:

const finalValue = (cond1 && cond2) ? ( v > 0 ? 1 : 2) : 
    (c ? 3 : 4);

Es mucho mejor que esto:

let finalValue = null;

if (cond1 && cond2) {
  if (v > 0) {
    finalValue = 1;
  } else {
    finalValue = 2;
  }
} else {
  finalValue = c ? 3 : 4;
}

Por no hablar de nombres imposibles como:

const turic = 2;

Que son acrónimos de conceptos como “total of users registered in company”.

Salvo que nos cobren por línea o caracter escrito, creo que no hay motivos para cometer esta clase de atropellos. El siglo XXI llegó hace más de 20 años y con él una cosa tan maravillosa como es el autocompletado, que justo se inventó para ahorrarnos esas pulsaciones que tanta pereza nos dan.

Pasado un tiempo, habitualmente cuando nos cansamos de leer nuestros propios haikus, el péndulo interno se desplaza en la otra dirección, y comenzamos a emplear nombres larguíiiiiiiiisimos. ¡Como si esa fuera la solución!

Esto también representa un problema. Por ejemplo, un método con un nombre gigante provocará saltos de línea adicionales y evitará que de un vistazo podamos entender lo que hace. Lo mismo aplica para clases, variables o nombres de archivos.

🥷🏼 Para mí, un nombre tiene que ser todo lo largo que sea necesario pero no más. Tampoco menos.

Déjame darte algunos trucos que te ayuden a cumplir con la regla anterior.

Cómo escoger un buen nombre

Un nombre debe tener dos características:

Precisión: expresar lo que hace el elemento al que se lo hemos asignado.
Claridad: mostrar a lo que se refiere.

En el momento en que escojamos un nombre que cumpla estas dos cualidades, cualquier caracter adicional no aportará nada.

No añadas información extra

Por ejemplo, si estamos trabajando con un lenguaje tipado como TypeScript o las últimas versiones de PHP, la notación húngara es redundante:

function fn(nameString: string) {

El tipo de la variable es inherente a su propia declaración, por lo que no es necesario expresarlo también en su nombre. Aunque vayamos a trabajar con esa variable durante toda la función, no requerirá más de un scroll encontrar su tipo (si es que el editor no te lo proporciona ya al situar el cursor encima).

Psss. Entre tú y yo. Tus funciones no son de 500 líneas, ¿verdad? Ya hablaremos de eso en otra publicación.

Otro ejemplo sucede con las colecciones. Si queremos almacenar en una variable una lista de mascotas, es preferible usar el plural antes que recurrir a sufijos como List o Collection:

// 🥲
const petList = [];

// 😍
const pets = [];

Finalmente, si tu código está bien organizado tampoco es necesario provocar una sensación “eco” cuando escribimos métodos:

function orderUsers(users) {
    // ..
}

// 🔈
orderUsers(users)

Aprovecha el contexto

El lenguaje tiene una característica muy poderosa (y de hecho, muy difícil de describir para una inteligencia artificial) que es el contexto. Esto es lo que permite este tipo de conversaciones:

¿Mañana llueve?

Sí.

¿Y pasado?

El significado de la segunda pregunta se infiere del contexto en el que tiene lugar la conversación.

En programación podemos aprovecharnos de él para escoger nombres que cumplan con nuestra promesa de claridad y precisión.

// 🥲
class Pet
{
    function movePet() {
        //
    }

    function feedPet() {
        //
    }
}

// 😍
class Pet
{
    function move() {
        //
    }

    function feed() {
        //
    }
}

Prescinde de palabras genéricas

Un truco que suele funcionar para saber si podemos eliminar una palabra del nombre que hemos asignado es tratar de borrarla mentalmente.

Por ejemplo, si nuestra variable se llama userInstance, ¿qué sucede si nos cargamos ese sufijo tan rimbombante que es “Instance”? Nada, ¿verdad? Eso es porque no está aportando ningún tipo de significado más allá de que, cuando leamos el código en el futuro pensemos algo así como:

Uuuuuuh, una instancia!

data, state, amount, value, object o entity son ejemplos de este tipo de palabras que tan sólo aportan ruido a nuestro código. Pero valor, lo que se dice valor, muy poco.

Son identificadores, no libros

Al igual que debemos evitar el uso de abreviaturas ingeniosas a la hora de nombrar variables, tampoco es necesario escribir relatos cortos sobre lo que hace la variable.

Por ejemplo, partamos de una variable nombrada como commonProductsChoosenByUsersInCrossSelling . Te prometo que he tenido que coger algo de aire para pronunciarla de carrerilla. Como idea inicial está bien, ya que no deja nada a la imaginación. La variable en cuestión representa los productos que los usuarios escogen durante el proceso de venta cruzada.

Pero no nos paremos ahí. Vamos a hacernos las siguientes preguntas:

¿Hay otra clase de participantes en nuestro sistema que puedan escoger productos? En caso negativo, choosenByUsers sobra completamente; no hay otro actor que pueda escoger productos en nuestra aplicación.
¿Dónde se está usando esta variable? ¿Quizás en un componente llamado CrossSelling? En ese caso, InCrossSelling no es necesario ya que el contexto donde se define la variable proporciona esa información.
Y lo mismo sucede con el prefijo common. ¿Existe otra lista con productos no tan comunes?

Como ves, quizás no sea necesario un nombre tan largo. Entre cpcbuic y commonProductsChoosenByUsersInCrossSelling existe una amplia gama de nombres que harán nuestro código mucho más legible.

🏅 Recuerda la regla de oro. Un nombre tiene que ser todo lo largo que sea necesario pero no más. Tampoco menos.

Caso práctico

Como todo siempre se ve mejor con un ejemplo, partamos de la siguiente clase a la que aplicaremos un buen refactor en lo que a nombrado se refiere:

class LovelySephardDogClass {
  public function moveLovelySephardDogThroughPoints(
      array pointList
  ) {  }
}

Como el argumento que recibe la función ya sabemos que es un array, podemos modificar su nombre a algo menos repetitivo:

class LovelyAndCuteDogClass {
  public function moveLovelySephardDogThroughPoints(
      array points
  ) {  }
}

Lo mismo sucede con el sufijo “Class” que hemos añadido al nombre de nuestra clase. Ya sabemos que es una clase, ¿es necesario remarcarlo con 5 caracteres extra? No creo.

class LovelyAndCuteDog {
  public function moveLovelySephardDogThroughPoints(
      array points
  ) {  }
}

Ahora toca hacernos la siguiente pregunta. ¿Existen en nuestra aplicación otro tipo de perros además de los “lovely and cute”? Si la respuesta es “no”, todos esos adjetivos que hemos añadido sobran:

class Dog {
  public function moveDogThroughPoints(
      array points
  ) {  }
}

Por último, prestemos atención al método moveDogThroughPoints. Puesto que se invocará sobre un objeto de la clase Dog, no es necesario repetir el tipo de objeto que estamos moviendo. Recuerda: contexto, contexto, contexto:

class Dog {
  public function moveThroughPoints(
      array points
  ) {  }
}

Y dado que el argumento que recibe el método moveThroughPoints es una lista de puntos, creo que está claro que cuando invoquemos dog→move, el objeto recorrerá la lista de puntos especificados. No es necesario hacer eco con “points”.

class Dog {
  public function move(array points) {  }
}

Ahora sí, podemos descansar tranquilos. 😌

Si estás pensando, "Gerardo, menudo ejemplo tan evidente me has puesto” te animo a que cojas una aplicación medio grande y le eches un vistazo. Quizás no encuentres una clase LovelyAndCuteDogClass, pero me apuesto un café a que entre la maleza habrá nombres que han pecado de ser demasiado autoexplicativos.

Busca sustituirlos por otros que sean precisos y claros.

Tu yo del futuro lo agradecerá. 👨🏼‍💻👩🏼‍💻

Las palabras son pálidas sombras de nombres olvidados. Los nombres tienen poder, y las palabras también. Las palabras pueden hacer prender el fuego en la mente de los hombres. Las palabras pueden arrancarles lágrimas a los corazones más duros. Existen siete palabras que harán que una persona te ame. Existen diez palabras que minarán la más poderosa voluntad de un hombre. Pero una palabra no es más que la representación de un fuego. Un nombre es el fuego en sí.
El nombre del viento. Patrick Rothfuss

🏎 Calentando motores...

Gerardo — Fri, 06 May 2022 10:08:28 GMT

💛 Bienvenido a Latte and Code, una newsletter repleta de código para acompañar tu café. Déjame que te cuente muy rápidamente qué vas a encontrar si decides suscribirte.

Quizás, has llegado hasta aquí siguiendo alguno de mis vídeos en Youtube o a través de mis famosas “recetas javascripteras”. Me encanta crear contenido. Como siempre digo, la comunidad de desarrolladores me ha aportado tanto que considero que es el momento de devolverle algo.

Además, soy un apasionado de React, JavaScript y Symfony. Si has visto alguno de los vídeos que tengo en el canal, sabrás que me encanta hablar sobre estos temas y ayudarte a crecer y mantenerte al día.

He decidido abrir una cuenta en Substack como otra forma de comunicarme contigo. Sin prisa, usando esa herramienta tan magnífica que es la escritura para elaborar contenido que puedas disfrutar tranquilamente cuando te apetezca. Quiero que cada artículo te aporte valor y que esos 10 minutos de lectura hayan merecido la pena.

¡Te espero en tu bandeja de entrada!

Subscribe now

Latte and Code

Javascript y Eventos. Todo lo que necesitas saber

¿Qué son los eventos?

¿Cómo se propagan los eventos?

¿Y cómo detenemos la propagación?

stopPropagation()

stopImmediatePropagation()

Oye… ¿Y el famoso preventDefault()?

Lanzando eventos manualmente

🙏🏻 Gracias a Garaje de Ideas

Conclusiones

Capítulo 4. Lo que aprendí de DDD. Servicios

Tipos de servicio en DDD

Servicios de dominio

❗️ Entidades de dominio anémicas

Servicios de infraestructura

Servicios de aplicación

🙏🏻 Gracias a Garaje de Ideas

Conclusión

React Portals. Construyendo agujeros de gusano

Creando una ventana modal con React Portals

Repositorio

Propagación de eventos

Agujeros de gusano y React Portals

🙏🏻 Gracias a Garaje de Ideas

Conclusiones y referencias

React. A vueltas con los "rerenders" (II)

Cómo evitar “rerenders” en React

Memorizar componentes con React.memo

Componente sin propiedades

Componente con propiedades

¿Te está gustando este artículo?

Combinar useMemo / useCallback con memo

useMemo para componentes pesados

Propiedad key en listas

Optimización de contextos

Memorizar el valor del contexto

Separar los contextos

Selectores de contexto

🙏🏻 Gracias a Garaje de Ideas

Conclusiones

Capítulo 3. Lo que aprendí de DDD. Entidades

Identidad

Generación de identificadores

Delegación en la base de datos

Delegación en el cliente

La aplicación genera el identificador

Validación

Validación de valor

Validación de integridad

Eventos de dominio

🙏🏻 Gracias a Garaje de Ideas

Repositorios de entidades

React. A vueltas con los "rerenders" (I)

¿Qué es un “render” en React?

Qué son los “rerenders”

¿Qué provoca un “rerender”?

Cambios en el estado

Cambio en el contexto

Render del componente padre

Cómo evitar “rerenders” en React

Composición

Situar el estado lo más abajo posible

Pasar componentes como propiedades

¡Cuidado! Crear un componente dentro de otro

🙏🏻 Gracias a Garaje de Ideas

Para aprender más

Conclusiones

Capítulo 2. Lo que aprendí de DDD. Value Objects

Citas famosas

Características

Diferencia con las entidades

¿Preocupado por el consumo de memoria?

Persistiendo en base de datos

🙏🏻 Gracias a Garaje de Ideas

Conclusiones

Capítulo 1. Lo que aprendí de DDD. Conceptos básicos

¿Qué es DDD?

¿Es DDD “el bálsamo de fierabrás”?

Arquitecturas recomendadas

Propiedad `key` en listas