
<LinkToCanonical canonicalUrl="https://tech.cornershop.io/domain-modeling-for-frontend-applications-using-typescript-2bc162fd94a0" />

Una de las cosas más gratificantes de utilizar TypeScript en vez de JavaScript para desarrollar aplicaciones en el frontend, es la habilidad que los tipos nos dan para modelar el negocio en términos de código. De seguro, la contundencia en los tipos y sugerencias en el código - que son dos beneficios que obtenemos al utilizar lenguajes con tipos estáticos -, son de mucha utilidad para mejorar la calidad del código y la experiencia de desarrollo, correspondientemente. En mi experiencia construyendo aplicaciones tanto con JavaScript como TypeScript, en lo que he encontrado más valor al utilizar tipos estáticos, es en el modelado del dominio.

Buen modelado del dominio no solo sirve como excelente documentación: también pone al negocio más cerca de los desarrolladores. Cuando los desarrolladores nos convertimos en expertos del negocio, la complejidad incidental del software se reduce, dado que poseemos un mejor entendimiento de los problemas que queremos resolver por medio de software. Buen modelado del dominio solo es posible cuando los desarrolladores entendemos el negocio.

> Estas ideas alrededor de el modelado de dominio vienen desde el *domain-driven design*. <LinkTo url="https://martinfowler.com/bliki/DomainDrivenDesign.html">Este artículo</LinkTo> de Martin Fowler es un buen punto de partida si quieres aprender más al respecto.

En cuanto a las clásicas aplicaciones de empresa, la mayoría de las veces la lógica de negocio se va a encontrar en el backend, sin embargo hay mucho valor en poder describir como las entidades de negocio interactúan en el frontend.

En mi experiencia en Cornershop by Uber, utilizar TypeScript para proyectos grandes, ha pagado excelentes dividendos en términos de mantenibilidad, que es algo que quieres garantizar en equipos grandes de desarrollo para aumentar la productividad y calidad del código.

En este artículo exploraremos alguna técnicas para hacer modelado del dominio en TypeScript. Sin mucho más preámbulo, vamos!

### La aplicación de pendientes.

Utilizaremos una aplicación de pendientes (también conocida como to-do app) para demostrar las distintas técnicas a presentar en este artículo. El objetivo no es construir una aplicación en sí, sino explorar el dominio de una aplicación con dichas características e intentar modelar su dominio por medio de tipos estáticos.

> Si nunca has visto una aplicación de pendientes, puedes ver una <LinkTo src="https://todomvc.com/">https://todomvc.com/</LinkTo>.

En la mayoría de aplicaciones de tareas en TypeScript, probablemente definiríamos una tarea pendiente de la siguiente forma:

```ts
interface ToDo {
  id: string
  title: string
  completed: boolean
}
```

Además de referirnos a las tareas de forma individual, también lo podemos hacer como un listado. Para esto podríamos usar un tipo literal `ToDo[]` (o `Array<ToDo>`) o mucho mejor, definir un alias para el tipo en sí, ya que oculta los detalles de implementación de qué tipo es utilizado bajo la capota:

```ts
type ToDos = Array<ToDo>
```

Acá utilizamos el tipo `Array` correspondiente a un arreglo nativo en JavaScript, pero podríamos utilizar nuestra propia estructura de datos que represente a una lista, y aún así nos referiríamos a los pendientes como `ToDos` en el resto del código. Por ejemplo, en una aplicación de React: 


```tsx
import React from 'react'
import type { ToDos } from '../path/to/todos'

interface ToDoProps {
  todos: ToDos
}

const ToDoList = (props: ToDoListProps) => {
  return <>{/* etc... */}</>
}

export default ToDoList
```

Independientemente de la semántica de qué tipo de lista estemos utilizando, tener un alias para `ToDos` nos ayuda para mejorar la mantenibilidad del código, y fomenta mantener un lenguaje ubicuo. Hablaremos más al respecto en un minuto.

### Definir tipos según la necesidad del negocio.

Volvamos a nuestra definición de `ToDo`:

```ts
interface ToDo {
  id: string
  title: string
  completed: boolean
}
```

Lo que podemos inferir de esta interfaz es que tenemos dos tipos de pendientes: pendientes completados y pendientes por completar. Si acaso nos referimos a ambos como conceptos diferentes o no, depende de como el negocio lo hace en la realidad.

Si nuestros expertos del negocio se refieren a pendientes completados y por completar como dos cosas concretas distintas, nuestra definición actual de `ToDo` está desalineada con la realidad del negocio. Aquí es donde el concepto del lenguaje ubicuo emerge en *domain-driven design*. No lo voy a explicar en cabalidad, pero en resumen: todos los miembros de una organización deberíamos entender lo mismo cuando nos referimos a un concepto. Cuando un área (desarrollo, por ejemplo) tiene un entendimiento diferente de un concepto al resto de la organización, la comunicación sufre. Tener un lenguaje común para todos resuelve este problema.

Así un `ToDo` es en realidad un `CompletedToDo` o un `UncompletedToDo`. Podemos modelar esto en TypeScript utilizando un tipo de unión (también conocido como tipo de suma):

```ts
type ToDo = CompletedToDo | UncompletedToDo
```

Esta definición de un `ToDo` hace más sentido con nuestra definición hipotética del negocio. ¿Pero cómo lucirían estos tipos?

Hay múltiples formas de implementar estos tipos utilizando TypeScript y voy a mostrar varias formas de hacerlo. Sin embargo, algunas de estas implementaciones no son prácticas para este ejemplo en particular. Mi consejo es escoger lo que te haga más sentido dependiendo del problema que vayas a resolver.

#### Utilizando tipos literales.

La forma más simple de definir nuestros tipos nuevos sería definiendo cada tipo separadamente:

```ts
type ToDo = CompletedToDo | UncompletedToDo
type ToDos = Array<ToDo>

interface CompletedToDo {
  id: string
  title: string
  completed: true
}

interface UncompletedToDo {
  id: string
  title: string
  completed: false
}

export type { ToDo, ToDos, CompletedToDo, UncompletedToDo }
```

Notemos como un `CompletedToDo` siempre tendrá su propiedad `completed` definida como `true`, y `UncompletedToDo` como `false`.

La desventaja de esta implementación es que nos estamos repitiendo con las propiedades en común entre ambas tareas. Podemos resolver esto al extender un tipo base en tres formas diferentes.

#### Utilizando extends.

La palabra reservada `extends` puede ser utilizada para definir una interfaz que utiliza otra interfaz o tipo como base:

```ts
type ToDo = CompletedToDo | UncompletedToDo
type ToDos = Array<ToDo>

interface BaseToDo {
  id: string
  title: string
  completed: unknown
}

interface CompletedToDo extends BaseToDo {
  completed: true
}
interface UncompletedToDo extends BaseToDo {
  completed: false
}

export type { ToDo, ToDos, CompletedToDo, UncompletedToDo }
```

Definimos un tipo `BaseToDo` que tiene todas las propiedades comunes para los pendientes completados y por completar, y luego la utilizamos como base para crear versiones especializadas.

> En este caso el tipo `BaseToDo` debería permanecer privado, dado que solo sirve un propósito auxiliar para definir nuevos tipos.

Notemos como el tipo de `BaseToDo['completed']` es `unknown`. Personalmente, prefiero utilizar `unknown` en este caso en vez de `boolean`, principalmente porque es una forma de indicar que un tipo concreto **debe** ser especificado para cualquier tipo que quiera extender `BaseToDo`. Si extendemos `BaseToDo` y olvidamos especificar un tipo para `completed`, TypeScript nos hará saber que ese tipo es `unknown`. Si bien en la mayoría de los casos utilizar `boolean` sería suficiente, en lo personal prefiero los beneficios que nos da utilizar `unknown`.

El compilador de TypeScript es suficientemente inteligente para entender que el tipo de `ToDo['completed']` corresponde a la unión de `CompletedToDo` y `UncompletedToDo`.

<figure>
  <img
    src="/img/tsmodel/ts01.png"
    alt="Tooltipo de vscode señalando el tipo computado de ToDo[completed] a partir de la unión de CompletedToDo y UncompletedToDo"
  />
  <figcaption>El tipo inferido de completed es la unión de true y false, que corresponde a boolean.</figcaption>
</figure>

### Utilizando un tipo de intersección.

Otra forma de implementar esto es por medio de un tipo de intersección (también conocido como tipo de producto):

```ts
type ToDo = CompletedToDo | UncompletedToDo
type ToDos = Array<ToDo>

interface BaseToDo {
  id: string
  title: string
  completed: unknown
}

type CompletedToDo = BaseToDo & {
  completed: true
}
type UncompletedToDo = BaseToDo & {
  completed: false
}

export type { ToDo, ToDos, CompletedToDo, UncompletedToDo }
```

Existe una diferencia sutil (pero grande) entre utilizar un tipo de intersección y extender una interfaz. Cuando utilizamos un tipo de intersección, intentamos buscar la intersección entre dos tipos, o dos conjuntos, ya que los tipos son solo conjuntos de todos los valores que satisfacen dicho tipo (todos los `number`, todos los `string`, `any`, etcétera). Si algo recordamos de teoría de conjuntos, es que una intersección puede ser vacía (cuando no existe nada en común entre dos conjuntos). Consideremos la siguiente definición del tipo `Nonsense`:

```ts
type Nonsense = { completed: true } & { completed: false }
```

TypeScript nos dice que el tipo de `Nonsense` es en realidad `never`.

<figure>
  <img
    src="/img/tsmodel/ts03.png"
    alt="Tooltip de vscode señalando que el tipo Nonsense es equivalente al tipo never"
  />
  <figcaption>Una intersección vacía.</figcaption>
</figure>

La intersección entre `true` y `false` es vacía: `false` no es un subconjunto de `true`, ni viceversa, por lo tanto nunca existirá un objeto donde `completed` pueda ser `true` Y `false` (aunque Schrödinger podría estar en desacuerdo).

En el caso de `CompletedToDo`, corresponde a la intersección entre el conjunto de objetos donde `completed` es `unknown`, que es equivalente a `any` (en otras palabras, a cualquier tipo) y el conjunto donde `completed` es `true`. Así que la intersección corresponde a todos los objetos donde `completed` es realmente `true`. Lo mismo aplica para `UncompletedToDo`.

Al contrario, cuando extendemos una interfaz, podemos sobrescribir el tipo inicial, así que en realidad no nos importa el tipo inicial de la propiedad que estamos sobrescribiendo en el tipo base. Si bien en nuestro caso, utilizar una interfaz o un tipo de producto nos lleva al mismo resultado, es una diferencia que tenemos que tener en cuenta.

### Utilizando tipos condicionales.

Por último pero no menos importante, podemos utilizar tipos condicionales para modelar lógica al definir nuestros tipos. Para este caso en particular es como matar una mosca con una bazuca, sin embargo es algo que puede sernos útil en un escenario más complejo.

Para demostrar el uso de tipos condicionales, añadiremos un nuevo requerimiento a nuestra aplicación de pendientes. Tras un lapso de tiempo - una hora, un día, lo que sea - un pendiente completado debería mantenerse completado, por lo tanto no puede ser modificado. Digamos que representaremos este estado por medio de un campo de tipo `boolean` en nuestro modelo, llamado `final`, que será `true` cuando un pendiente completado ya no pueda ser editado.

Nuestro modelo de `ToDo` podría verse así:

```ts
interface ToDo {
  id: string
  title: string
  completed: boolean
  final: boolean
}
```

Hay una charla muy famosa por Richard Feldman, llamada <LinkTo url="https://www.youtube.com/watch?v=IcgmSRJHu_8">"Haciendo los estados imposibles, imposibles"</LinkTo> - que recomiendo encarecidamente - que asegura que la forma en la que hemos decidido representar nuestro modelo es defectuosa, ya que ahora existe la chance de caer en un estado imposible: no tiene sentido que un pendiente no haya sido completado y que esté en un estado final. Esto es algo que sucede comúnmente cuando modelamos estados con booleanos, se prestan para combinaciones que no tienen sentido en el mundo real.

Para nuestro requerimiento en particular, tendría más sentido modelar el estado de nuestro quehacer con un tipo de unión o un enumerable, ya que ambos describen un conjunto finito de valores posibles. Podría ser algo por el estilo: 

```ts
enum Status {
  Uncompleted = 'UNCOMPLETED',
  Completed   = 'COMPLETED',
  Final       = 'FINAL',
}
```

Y con ello definimos `ToDo` como:

```ts
type ToDo {
  id: string
  title: string
  status: Status
}
```

> Si bien no es exactamente igual, `Status` podría ser definido como la unión de `'UNCOMPLETED' | 'COMPLETED' | 'FINAL'`.

Para fines demostrativos, digamos que DEBEMOS utilizar booleanos porque cambiar nuestra definición de `ToDo` requeriría una refactorización que no podemos abordar en este momento.

Para ser honesto, cualquiera de los métodos demostrados anteriormente cumplen con el requerimiento:

```ts
type ToDo = CompletedToDo | UncompletedToDo | FinalToDo 
type ToDos = Array<ToDo>

interface BaseToDo {
  id: string
  title: string
  completed: unknown
  final: unknown
}

type CompletedToDo = BaseToDo & {
  completed: true
  final: false
}
type UncompletedToDo = BaseToDo & {
  completed: false
  final: false
}
type FinalToDo = BaseToDo & {
  completed: true
  final: true
}

export type {
  ToDo,
  ToDos,
  CompletedToDo,
  UncompletedToDo,
  FinalToDo,
}
```

Pero por alguna razón queremos utilizar `Status` ya que es es un concepto que queremos introducir en el código base lo antes posible. Al utilizar tipos condicionales, básicamente podemos computar los tipos para `completed` y `final` basado en el tipo de `Status`. Para conseguir esto, es necesario parametrizar la definición de todos nuestros tipos. Podemos lograr esto en TypeScript si utilizamos genéricos.

Queremos que nuestro `ToDo` luzca así:

```ts
type ToDo =
  | UncompletedToDo
  | CompletedToDo
  | FinalToDo
```

Donde:

```ts
type UncompletedToDo = BaseToDo<Status.Uncompleted>
type CompletedToDo  = BaseToDo<Status.Completed>
type FinalToDo = BaseToDo<Status.Final>
```

Básicamente `BaseToDo` depende de un parámetro `S`:

```ts
interface BaseToDo<S> {}
```

¿Recuerdas que habíamos dicho que los tipos son nada más que conjuntos? Para poder parametrizar `BaseToDo` correctamente, `S` tiene que ser un subconjunto de `Status`. En nuestro caso particular, `S` es un subconjunto impropio, pues todos los elementos de `Status` se encuentran en `S`. Para anotar esto, podemos utilizar `extends` al definir el tipo genérico: 

```ts
interface BaseToDo<S extends Status> {}
```

TypeScript ahora sabe que cuando utilizamos el tipo `S` dentro de nuestra definición de `BaseToDo`, estamos hablando de cualquier miembro de `Status`. Dicho esto, ya estamos listos para utilizar tipos condicionales para computar los tipos de `completed` y `final`.

Nuestro `BaseToDo` se vería algo así:

```ts
interface BaseToDo<S extends Status> {
  id: string
  title: string
  completed: S extends Status.Completed | Status.Final
    ? true
    : false
  final: S extends Status.Final
    ? true
    : false
}
```

Comencemos por el tipo de `completed`. Aquí vemos otro uso de la palabra `extends`. En este caso se utiliza para chequear que `S` es un subconjunto de `Status.Completed | Status.Final`, o en otras palabras, cualquier miembro de `Status` menos `Status.Uncompleted`. Si ese es el caso, entonces el tipo de `completed` es `true`. De otra forma, debe ser `false`. Recuerda que estamos hablando de tipos aquí, no de valores.

> Otra forma de expresar la diferencia de `Status` menos `Status.Uncompleted` sería utilizando el tipo utilitario `Exclude` de la siguiente forma `Exclude<Status, Status.Uncompleted>`

Lo mismo aplica a `final`. Si `S` es un miembro del tipo con un solo miembro `Status.Final` (por lo tanto, si `S` es `Status.Final`), luego el tipo de `final` debe ser `true`, de otra forma es `false`.

TypeScript es suficientemente inteligente para entender el tipo computado a partir del uso de `BaseToDo`:

<figure>
  <img
    src="/img/tsmodel/ts04.png"
    alt="Tooltip de vscode mostrando un error al tratar de crear un objeto de tipo CompletedToDo con final igual a true"
  />
  <figcaption>Un elemento de tipo CompletedToDo nunca podrá tener una propiedad final que sea true.</figcaption>
</figure>

Si no te gusta tener estas expresiones en línea dentro de la definición de `BaseToDo`, simplemente podemos extraerlas en más tipos:

```ts
type Completed<S extends Status> =
  S extends Status.Completed | Status.Final
    ? true
    : false

type Finalized<S extends Status> =
  S extends Status.Final
    ? true
    : false

interface BaseToDo<S extends Status> {
  id: string
  title: string
  completed: Completed<S>
  final: Finalized<S>
}
```

Nuestro ejemplo final se vería así:

```ts
type ToDo =
  | CompletedToDo
  | UncompletedToDo
  | FinalToDo 
type ToDos = Array<ToDo>

enum Status {
  Uncompleted = 'UNCOMPLETED',
  Completed   = 'COMPLETED',
  Final       = 'FINAL',
}

interface BaseToDo<S extends Status> {
  id: string
  title: string
  completed: S extends Status.Completed | Status.Final
    ? true
    : false
  final: S extends Status.Final
    ? true
    : false
}

type CompletedToDo = BaseToDo<Status.Completed>
type UncompletedToDo = BaseToDo<Status.Uncompleted>
type FinalToDo = BaseToDo<Status.Final>

export type {
  ToDo,
  ToDos,
  CompletedToDo,
  UncompletedToDo,
  FinalToDo,
}
```

Nuevamente, para nuestro ejemplo en particular, esto es demasiado, pero es un recurso que vale tener para cuando sea necesario.

<PostDetailFooter />


Modelado de dominio para aplicaciones frontend utilizando TypeScript


Hace algunos días mientras revisaba un pull request me encontré con un fragmento de código que se veía algo así:

```jsx
React.useEffect(() => {
  someCondition && doSomething()
}, [someCondition, doSomething])
```

No es necesario que sepas que es lo que hace `React.useEffect`, solo quiero enfocarme en el cuerpo de la función que le pasamos como argumento.

Le sugerí a mi colega reemplazar la expresión de corto circuito para implementar dicha condición por un simple `if`. Cuando mi colega me preguntó por qué sería preferible utilizar un `if`, sinceramente no encontré una respuesta razonable. Solo _se sentía mejor_ para mí.

Pero que algo _se sienta mejor_ no es una razón aceptable, principalmente porque es muy subjetiva. Lo que _se siente mejor_ para mí, no se va a _sentir mejor_ necesariamente para el resto del equipo.

Así que hice lo que cualquier otra persona haría: me obsesioné (😅) e intenté buscar el motivo de por qué _se siente mejor_.

<Disclaimer>Aclaración: Este artículo solo describe mi razonamiento alrededor del tema. No estoy sugiriendo esto como buena práctica ni nada por el estilo.</Disclaimer>

___

Algo que he aprendido tras mirar muchas charlas de Rich Hickey, es siempre comenzar con una definición:

> En ciencias de la computación, una [expresión](https://en.wikipedia.org/wiki/Expression_%28computer_science%29) es una entidad sintáctica en un lenguaje de programación que podría ser evaluada para determinar su valor.

Algunas expresiones en JavaScript:

```js
42                              // 42 
'foo'                           // 'foo'
false                           // false
const nums = [1, 2, 3]          // ??
nums                            // [1, 2, 3]
```

En JavaScript, los valores literales se evalúan a sí mismos, y las variables se evalúan a cualquier valor que _almacenen_.

Veamos la cuarta línea en el fragmento de código anterior: en JavaScript, la asignación de una variable también es una expresión. ¿A qué crees que la expresión `const nums = [1, 2, 3]` se evalúa?

La asignación se evalúa como `undefined`.

En otros lenguajes de programación (como Python) la asignación de variables no son expresiones, sino que una declaración. Aquí está la definición de declaración:  

> En ciencias de la computación, una [declaración](https://en.wikipedia.org/wiki/Statement_(computer_science)) es una unidad sintáctica de un lenguaje de programación imperativo que expresa alguna acción que se ejecutará.

Lo importante aquí es la palabra **acción**. Hablaremos de aquello en un momento.

Algunas declaraciones en JavaScript:

```js
for (let n of nums) { /*...*/ }
while (true)        { /*...*/ }
if (nums.length)    { /*...*/ }
```

Ignorando el hecho de que la asignación es una expresión (una expresión inútil, si me preguntan) sería razonable pensar que las _expresiones_ son a los **valores** como las _declaraciones_ son a las **acciones**.

### Evaluación de corto circuito

Más definiciones, yey:

> [Evaluación de corto circuito](https://en.wikipedia.org/wiki/Short-circuit_evaluation), evaluación mínima, o evaluación de McCarthy (por John McCarthy) se refiere a las semánticas de algunos operadores Boolean en algunos lenguajes de programación en donde el segundo argumento es ejecutado o evaluado solo si el primer argumento no es suficiente para determinar el valor de la expresión completa.

He aquí un ejemplo:

```js
true || false                 // true
```

En el ejemplo anterior, la segunda parte de la expresión no es evaluada ya que el primer argumento es suficiente para determinar el valor de la expresión completa.

Es un poco extraño pensar así al utilizar literales, ya que los literales se evalúan a sí mismos. Lo escribiremos ligeramente distinto para que sea más fácil de razonar al respecto:

```js
const aCondition = true
const anotherCondition = false

aCondition || anotherCondition   // true
```

Dado que `aCondition` es `true`, no hay necesidad de evaluar la variable `anotherCondition`, independiente de cual sea su valor.

Revisemos con otro ejemplo:

```js
const person = {
  get name() {
    console.log('Bayum!')
    return 'Bodoque'
  }
}

true || person.name           // true
```

Al ejecutar este código vemos que `"Bayum!"` no es impreso en la consola, dado que el primer argumento de la expresión es `true`, lo que es genial.

¿Por qué esto es importante?

### Efectos secundarios, programación funcional & Haskell

Haremos un pequeño desvío para continuar con –ya lo adivinaste–, otra definición:

> [Haskell](https://en.wikipedia.org/wiki/Haskell_(programming_language)) es un lenguaje de propósito general, de tipado estático y puramente funcional con inferencia de tipos y evaluación perezosa.

Escribamos una pequeña función en Haskell que imprima `"42"` en la consola:

```hs
doSomething = putStrLn "42"
```

Utilizando `ghci`, el ambiente interactivo del compilador Glasgow Haskell Compiler (algo así como un REPL), podemos verificar el tipo de la función `doSomething`:

```ghci
Prelude> doSomething = putStrLn "42"
Prelude> :t doSomething 
doSomething :: IO ()
```

`doSomething` es una función que no toma ningún parámetro y cuyo tipo de retorno es `IO ()`, o `IO` de _unit_ (el par de paréntesis vacíos se llama _unit_ y es _similar_ a `void` en JavaScript). En Haskell todas las funciones con efectos secundarios tienen un tipo de retorno `IO` de algo. Las funciones puras no pueden invocar funciones con efectos. Si deseas tener un efecto, el tipo retornado siempre debe ser `IO` de algo.

Aunque no es obligación, podemos anotar explícitamente los tipos de nuestras funciones:

```hs
doSomething :: IO ()
doSomething = putStrLn "42"

-- He aquí otra función que toma dos Ints 
-- y retorna otro Int
add :: Int -> Int -> Int 
add a b = a + b
```

Ok, eso es todo lo que debíamos aprender sobre Haskell, de vuelta a nuestro itinerario habitual.

### Expresiones de corto circuito y control de flujo

La invocación de una función siempre puede ser reemplazada por el valor retornado de la función, si este valor depende solo de sus parámetros. En otras palabras, la invocación de una función solo puede ser reemplazada por el valor retornado por la función solo si esta no tiene efectos secundarios.

Esta propiedad se conoce como transparencia referencial. Las funciones referencialmente transparentes también se conocen como funciones puras.

Cuando hacemos programación funcional, nuestro objetivo es maximizar la superficie de código que está implementada con funciones puras: son más fáciles de entender y más fáciles de testear. Así que para la mayor parte de las funciones en un programa, nos van a interesar los valores que retornan: 

```js
const whatIsThis = someCondition && doSomething()
```

Si no nos interesa el resultado de `doSomething`, probablemente no tiene valor guardar el valor de la expresión en `whatIsThis`. Aun así la expresión tiene un valor, aunque sea utilizado o no:

```js
function doSomething() {
  console.log("42")
}

someCondition && doSomething()   // `false` cuando `someCondition` es `false`
                                 // `undefined` cuando `someCondition` es `true`
```

Si nos nos interesa el valor de la expresión, entonces `doSomething` probablemente es una función con efectos. JavaScript no es Haskell así que no hay forma de decir si `doSomething` tiene efectos o no sin mirar su implementación. Incluso haciéndolo, no garantiza que sea algo sencillo de hacer.

Y creo que por esto es que prefiero utilizar un `if` en vez de una expresión de corto circuito para flujo de control en funciones con efectos: para mí es completamente inequívoco que no nos interesa el valor de retorno, y por ende entonces es un efecto secundario.

### ¿Y que hay de las funciones con efectos que sí retornan valores?

No tenemos un compilador como GHC para forzar pureza en nuestras funciones, pero igualmente podemos seguir una convención para invocar funciones con efectos solo dentro de otras funciones con efectos. En Haskell esto es posible por medio de monadas.

Si quieres una explicación más a fondo sobre este tema, te recomiendo el siguiente video:

<Video src="https://www.youtube.com/embed/C2w45qRc3aU" title="The Absolute Best Intro to Mondas For Software Engineers" />

<PostDetailFooter />

Por qué no me gusta utilizar expresiones de corto circuito para control de flujo

Control de flujo, expresiones de corto circuito y programación funcional en JavaScript

CLEAN es una arquitectura por capas que sintetiza varias ideas propuestas en arquitecturas como Arquitectura hexagonal, Arquitectura de cebolla y Barrera de Control de Entidad entre otras, para asegurar separación de responsabilidades y facilidad de realización de pruebas, que son dos conceptos claves para tener una base de código mantenible y escalable. En este artículo te explico las características de las arquitecturas por capas y sus beneficios, y en particular la constitución de la arquitectura CLEAN, y cómo podemos implementarla en una aplicación de React.

Implementando CLEAN en aplicaciones web con React

Arquitectura CLEAN para el frontend


<LinkToCanonical canonicalUrl="https://javascript.plainenglish.io/how-to-solve-the-problem-with-immutability-and-reducers-in-a-declarative-way-10274691b06c" />

Todas hemos escrito _reducers_ de Redux que tienen mil millones de usos del operador _spread_ (`...`). Nos alegramos cuando funcionan pero no podemos evitar sentirnos un poco mal, dada la verbosidad y el exceso de _boilerplate_.

Voy a tomar prestado un ejemplo de [este artículo](https://www.smashingmagazine.com/2020/06/better-reducers-with-immer/) por [Chidi Orji](https://www.smashingmagazine.com/author/chidi-orji/) en Smashing Magazine, para mostrar a qué tipo de _reducer_ me estoy refiriendo, en caso de que seas suficientemente afortunado de nunca haberte encontrado con uno de estos monstruos en código de producción:

```js
const updateReducer = (state = initState, action) => {
  switch (action.type) {
    case 'ADD_PACKAGE':
      return {
        ...state,
        packages: [...state.packages, action.package],
      };
    case 'UPDATE_INSTALLED':
      return {
        ...state,
        packages: state.packages.map(pack =>
          pack.name === action.name
            ? { ...pack, installed: action.installed }
            : pack
        ),
      };
    default:
      return state;
  }
};
```

Este no es tan terrible para ser honesto ¡Créanme, he visto y escrito peores!

¿Cuál es el problema aquí, exactamente? Bueno, si queremos actualizar una propiedad de algún objeto que está muy anidado en nuestro árbol de estado, vamos a tener que copiar mucho estado manualmente para modificarlo y luego retornar nuevo estado. Recordemos: los _reducers_ deben ser funciones puras libres de efectos secundarios, por lo que no podemos realizar mutaciones directamente sobre el estado, sino que retornar una referencia distinta para gatillar una transición.

El problema con usar mucho el operador _spread_ (`...`) en términos de legibilidad y mantenibilidad, es que no nos ayuda a expresar ninguna intención sobre cómo vamos a actualizar nuestro estado. Sólo nos ayuda a copiar cosas, y para cuando llegamos a la propiedad que queremos actualizar, terminamos con un montón de código a nuestro alrededor que no sirve ningún propósito más que replicar la estructura del árbol de estado.

### Haciendo las cosas declarativas

Una de las cosas que los conceptos de programación funcional embebidos en React nos han enseñado, es que expresar intención de forma declarativa hace nuestro código más fácil de entender. Lo hace más fácil para nosotras en el futuro y para nuestras colegas, porque cuando escribimos código lo hacemos para otras personas. Si eso no fuera imporante, escribiríamos _assembly code_ o _byte code_ y los lenguajes de programación de alto nivel no existirían.

Así que en vez de copiar cosas manualmente y luego intentar descifrar qué es lo que el código que escribimos hace supuestamente, es mejor si realmente describimos lo que el código debería hacer. Y la mejor manera de hacerlo de forma declarativa, es utilizando funciones puras.

Démosle un vistazo a cómo la acción `'ADD_PACKAGE'` está actualizando el estado en nuestro ejemplo anterior:

```js
const updateReducer = (state = initState, action) => {
  switch (action.type) {
    case 'ADD_PACKAGE':
      return {
        ...state,
        packages: [...state.packages, action.package],
      };
    // ...etc
  }
};
```

Bastante simple, ¿cierto? Un valor nuevo es asociado a la propiedad `packages`, y obtenemos este valor tras adjuntar un nuevo paquete al listado de paquetes.

Definamos algunas funciones para realizar estas operaciones. Primero, definiremos una función llamada `assoc`, que nos ayude a asociar data a una propiedad:

```js
const assoc = (key, value, record) => ({
  ...record,
  [key]: value
});
```

Y luego una función `append`, para adjuntar un valor al final de una lista (sería una versión inmutable de `Array.prototype.push`):

```js
const append = (element, list) => [ ...list, element ];
```

Podemos usar ambas funciones para actualizar nuestro estado:

```js
const updateReducer = (state = initState, action) => {
  switch (action.type) {
    case 'ADD_PACKAGE':
      return assoc(
        'packages’,
        append(action.package, state.packages),
        state
      );
    // ...etc
  }
};
```

Ahora, para un caso tan simple como el anterior los beneficios no son realmente visibles. Veamos que sucede con la acción `'UPDATE_INSTALLED'`:

```js
const updateReducer = (state = initState, action) => {
  switch (action.type) {
    case 'UPDATE_INSTALLED':
      return {
        ...state,
        packages: state.packages.map(pack =>
          pack.name === action.name
            ? { ...pack, installed: action.installed }
            : pack
        ),
      };
    // ...etc
  }
};
```

En este caso queremos ajustar (o asociar un nuevo valor) la propiedad `installed` de un paquete solo si el nombre del paquete (`pack.name`) es igual a `action.name`. Ahora, si bien podemos utilizar `map` para actualizar el listado de paquetes, esto es conceptuamente erróneo.

Cuando usamos `map`, todos los valores de la colección deberían ser transformados. Decidir si queremos transformar un elemento o no dentro de la colección, es un comportamiento especializado y no particularmente un _mapeo_: estamos realizando una actualización selectiva.

> Hay muchas formas de manejar condicionalidad en el código: la más común es utilizando un `if`. Pero hay mejores formas de manejar condicionalidad, y si la que intentamos modelar implica un cambio de comportamiento, lo que en realidad necesitamos es un comportamiento especializado.

Dicho esto, entonces creemos una función especializada que describa este comportamiento de forma más precisa:

```js
const adjustByWhere = (adjustFn, selectFn, list) => {
  return list.map((acc, item) => {
    return selectFn(item) ? adjustFn(item) : item;
  });
};
```

Probablemente estás pensando: "Trampa! Eso es lo mismo que tienes en el código del _reducer_, solo que genérico". Y sí, es la misma cosa. La diferencia es que ahora tenemos una abstracción que realmente describe la operación que estamos realizando, y ese es todo el punto de hacer programación declarativa: que tu código describa lo que hace, en vez de tener que descifrarlo nosotras cada vez que lo leemos.

Nuestra acción luciría así:

```js
const updateReducer = (state = initState, action) => {
  switch (action.type) {
    case 'UPDATE_INSTALLED':
      return assoc(
        'packages’,
        adjustByWhere(
          package => assoc('installed', action.installed, package),
          package => package.name === 'foo',
          state.packages
        ),
        state
      );
    // ...etc
  }
};
```

Esta solución está lejos de ser perfecta y definitivamente hay mejoras que podríamos aplicar a la API, pero la idea está allí: comenzar a escribir código que te diga lo que está haciendo, en vez de tener que descifrarlo cada vez que lo lees.

### El elefante en la habitación

> Me sentiría sumamente irresponsable si no mencionara `Immer`, porque resuelve este problema de forma brillante. Hablaré de ello brevemente pero si quieres darle un vistazo a fondo, asegúrate de leer la [documentación](https://immerjs.github.io/immer/).

Como diría Miley, `Immer` llegó como una bola de demolición para ofrecer una solución alternativa a este problema: en vez de hacernos copiar manualmente el estado actual de la aplicación para retornar nuevo estado, `Immer` nos proporciona un borrador que podemos actualizar directamente, mutando cualquier propiedad que queramos. Tras finalizar con las mutaciones, `Immer` crea un nuevo estado de forma inmutable usando el borrador que hemos modificado como base. Ese es un truco bastante inteligente, si me preguntas (o si le preguntas a cualquier, es brillante).

El código previo se vería así:

```js
import { produce } from 'immer';

const updateReducer = (state = initState, action) =>
  produce(state, draft => {
    switch (action.type) {
      case 'ADD_PACKAGE': {
        draft.packages.push(action.package);
        break;
      }
      case 'UPDATE_INSTALLED': {
        const package = draft.packages.find(p => p.name === action.name);
        if (package) package.installed = action.installed;
        break;
      }
      default: {
        break;
      }
    }
  });
```

Ahora, esto luce mucho más simple. Sin embargo hay una trampa: cuando usamos `Immer` debemos seguir un par de reglas porque así es como funcionan las cosas mágicas.

En resumen:

- Puedes modificar el estado o retornar un nuevo objet. Si haces ambas cosas, el infierno se desata.
- No podemos asignar directamente un valor al borrador. Podemos cambiar cualquier cosa dentro del borrador (cualquier propiedad de este), pero no el borrador en sí.

Si quieres averiguar más al respecto, checa este inciso en la [documentación](https://immerjs.github.io/immer/return/).

<PostDetailFooter />





Este artículo trata sobre las ventajas de utilizar composición de funciones para describir transiciones de estado en un reducer

Lidiando con reducers e inmutabilidad de forma declarativa


Según wikipedia: 

> El término *servicio* se refiere a una funcionalidad de un *software* o a un conjunto de funcionalidades de un *software* con un propósito que diferentes clientes pueden utilizar para distintos propósitos

Dentro del contexto de una aplicación web, un servicio entonces es un componente de *software* que encapsula ciertas funcionalidades y que puede ser reutilizado en distintos lugares de nuestra aplicación. Cuán abstracto o concreto sea un servicio dependerá de las características de nuestra aplicación y de su arquitectura.

En términos de manejo de estado, podemos clasificar nuestros servicios en dos tipos: los que manejan estado y los que no, o *stateful* y *stateless* respectivamente.

### Características de un servicio

La función principal de un servicio es servir como punto de integración entre nuestro sistema y un sistema externo (o entre dos módulos de nuestro propio sistema). En una aplicación web, el caso más común para utilizar un servicio es cuando queremos comunicarnos con algún *backend*, por ejemplo a través de una API REST.

Una de las mayores ventajas de utilizar un servicio para este propósito es que además nos sirve como una unidad natural de encapsulación y de separación entre las distintas capas de nuestra aplicación.

Imaginemos entonces que estamos construyendo una aplicación de pagos donde para realizar distintas acciones –como autorizar una transacción o cambiar información sensible– requerimos explícitamente autorización del usuario pidiéndole su contraseña para ser validada en el *backend*.

Como queremos validar al usuario solicitándole su contraseña cada vez que quiera realizar una transacción, no tiene mucho sentido almacenar esa información en memoria, ya que **siempre** debemos validar la contraseña con el *backend*.

El servicio de autorización podría verse así:

```ts
// authorization.service.ts
const BASE_URL = "//example.com/api/v100/authorize"

type Password = string;
interface AuthorizationResponse {
  authorized: boolean
}

class AuthorizationService {
  static async authorize(password: Password) {
    const res = await fetch(BASE_URL, {
      method: "POST",
      headers: [
        ["Content-Type", "application/json"]
      ],
      body: JSON.stringify({ password })
    });
    const { authorized }: AuthorizationResponse = await res.json();

    return authorized;
  }
}

export default AuthorizationService;
export type { Password };
```

> En este caso hemos usado una clase con un método estático para implementar nuestro servicio, pero lo podríamos haber implementado de otra manera.

El ejemplo anterior corresponde a un servicio *stateless*, pues no necesita almacenar el estado de la transacción en memoria, solo se encarga de realizar la consulta y exponer el resultado.

Podemos utilizar nuestro servicio en el resto de la aplicación de la siguiente forma:

```tsx
// AuthorizeTransaction.tsx
import React from "react";
import AuthorizationService from "../path/to/authorization.service";

const AuthorizeTransaction = ({ onSucceeded, onRejected }) => {
  const [password, setPassword] = React.useState("");

  const handleAuthorization = async (event) => {
    event.preventDefault();

    // Verifica con el servicio si el usuario está autorizado, de ser así ejecuta
    // `onSucceeded`. En el caso de no estar autorizado, ejecuta `onRejected`.
    const authorized = await AuthorizationService.authorize(password);

    if (authorized) {
      onSucceeded();
    } else {
      setPassword(""); // Reiniciamos el input del password de no ser válido
      onRejected();
    }
  };

  return (
    <form onSubmit={handleAuthorization}>
      <input
        name="password"
        type="password"
        value={password}
        onChange={e=> setPassword(e.target.value)}
      />
      <input type="submit" value="Submit" />
    </form>
  );
}

export default AuthorizeTransaction;
```

> En este caso hemos usado React para implementar la UI, pero esto podría hacerse de cualquier otra forma.

Dado que hemos metido toda la lógica de verificación dentro de un solo lugar, cualquier cambio de implementación de nuestro servicio puede ser transparente para el resto de la aplicación, siempre que respetemos la API pública del servicio.

Por ejemplo, podríamos reemplazar la clase con el método estático simplemente por un objeto con una propiedad `authorize` y el resultado sería el mismo:

```ts
// authorization.service.ts
const BASE_URL = "//example.com/api/v100/authorize"

type Password = string;
interface AuthorizationResponse {
  authorized: boolean
}

const authorizationService = {
  authorize: async (password: Password) => {
    const res = await fetch(BASE_URL, {
      method: "POST",
      headers: [
        ["Content-Type", "application/json"]
      ],
      body: JSON.stringify({ password })
    });
    const { authorized }: AuthorizationResponse = await res.json();

    return authorized;
  }
};

export default authorizationService;
export type { Password };
```

En una aplicación real probablemente tendremos *backends* dedicados para los ambientes de desarrollo, *staging* y producción. Esto puede ser configurado dentro del mismo servicio, así el resto de nuestra aplicación no tiene que precuparse por apuntar al *backend* correcto.

Digamos que en nuestro proyecto tenemos acceso a variables de entorno y podemos configurar una URL distinta para cada ambiente. Luego nuestro servicio se vería de la siguiente manera:

```ts
// authorization.service.ts
import env from "../path/to/env";

const BASE_URL = env.API_URL + "/v100/authorize"; // Donde el valor de API_URL puede cambiar según el ambiente en el que se ejecute nuestro código

// etc...

class AuthorizationService { /* etc */ }
```

Incluso podemos ir un paso más allá y configurar un servicio para nuestras llamadas HTTP que oculte este detalle de infraestructura:

```ts
// http.service.ts
import env from "../path/to/env";

const httpClient = {
  post: (url = "", payload = {}) => fetch(env.API_URL + url, {
    method: "POST",
    headers: [
      ["Content-Type", "application/json"]
    ],
    body: JSON.stringify(payload)
  }),
  get: (url) => fetch(env.API_URL + url),
  // etc...
};

export default httpClient;
```

Y luego:

```ts
// authorization.service.ts
import httpClient from "../path/to/http.service";

// etc ...
class AuthorizationService {
  static async authorize(password: Password) {
    const res = await httpClient.post("/v100/authorize", { password });
    const { authorized }: AuthorizationResponse = await res.json();

    return authorized;
  }
}

export default AuthorizationService;
// etc ...
```

> Como podemos ver al utilizar servicios estamos creando divisiones naturales dentro de nuestra aplicación. Esta es una buena forma de comenzar a pensar en distintas capas y responsabilidades dentro de nuestra arquitectura.

Imaginemos que con afán de aumentar la seguridad en la aplicación, hemos decidido implementar en el *backend* un contador de intentos al ingresar la contraseña. El usuario cuenta con 4 (cuatro) intentos para ingresar su contraseña: de ingresar una contraseña incorrecta 4 veces consecutivas, la cuenta del usuario será bloqueada. Cada vez que enviamos una contraseña errónea, en la respuesta del servicio obtenemos la cantidad de intentos que nos quedan. Si ingresamos la contraseña correcta, el contador se reinicia. Dicho esto, la nueva respuesta del *backend* tendría la siguiente forma:

```ts
interface AuthorizationResponse {
  authorized: boolean;
  attempts_left: number;
}
```

Una forma de almacenar la cantidad de intentos restantes sería haciéndolo en el componente `AuthorizeTransaction`. El problema de esto es que podríamos tener múltiples instancias de este componente y no tenemos forma alguna de coordinar el estado entre todas las instancias. Otra forma sería utilizar una librería para manejo de estado, que está perfectamente bien, pero escapa de la intención del artículo.

¡También podríamos almacenar la cantidad de intentos restantes en el mismo servicio!

En términos de código podría verse así:

```ts
// authorization.service.ts
import httpClient from "../path/to/http.service";

type Password = string;
interface AuthorizationResponse {
  authorized: boolean
}

class AuthorizationService {
  public _authorized?: boolean;
  public _attempts?: number;
  
  get authorized() {
    return this._authorized;
  };

  get attempts() {
    return this._attempts;
  };

  async authorize(password: Password) {
    const res = await httpClient.post("/v100/authorize", { password });
    const { authorized, attempts_left }: AuthorizationResponse = await res.json();

    this._attempts = attempts_left;
    this._authorized = authorized;

    return {
      authorized: authorized,
      attempts: attempts_left,
    }
  }
}

export default new AuthorizationService(); // Exportamos una instancia del servicio!
export type { Password };
```

El ejemplo anterior corresponde a un servicio *stateful*, pues almacenamos el estado de la transacción en memoria a fin de poder acceder a ella en otro momento.

Igualmente hemos exportado una instancia del servicio pues no requiere de dependencias al momento de ser instanciado y además queremos compartir el estado en toda nuestra aplicación. Esta es una forma simple de implementar el patrón *Singleton*. Si bien no es la forma más escalable de hacerlo, para lo que queremos ilustrar basta y sobra.

Utilizaríamos nuestro servicio de la siguiente forma:

```tsx
// AuthorizeTransaction.tsx
import React from "react";
import authorizationService from "../path/to/authorization.service";

const AuthorizeTransaction = ({ onSucceeded, onRejected }) => {
  const [transation, setTransaction] = React.useState(() => ({
    attemptsLeft: authorizationService.attempts,
    latestAttempt: authorizationService.authorized,
  })); // Inicializamos nuestro componente con la cantidad de intentos que quedan y el resultado de la última transacción
  const [password, setPassword] = React.useState("");

  const handleAuthorization = async (event) => {
    event.preventDefault();

    const { authorized, attempts } = await authorizationService.authorize(password);

    setTransaction({
      attemptsLeft: attempts,
      latestAttempt: authorized
    }); // Persistimos la cantidad de intentos restantes a partir de la respuesta de nuestro servicio

    if (authorized) {
      onSucceeded();
    } else {
      setPassword("");
      onRejected();
    }
  };

  const showRemainingAttempts = !latestAttempt && attemptsLeft !== undefined;

  return (
    <form onSubmit={handleAuthorization}>
      <input
        name="password"
        type="password"
        value={password}
        onChange={e=> setPassword(e.target.value)}
      />
      <input type="submit" value="Submit" />
      {showRemainingAttempts && <p>{`You have ${attemptsLeft} attempts left`}</p>}
    </form>
  );
}

export default AuthorizeTransaction;
```

Y voilá, cada vez que utilicemos nuestro componente `AuthorizeTransaction` será inicializado con la cantidad de intentos restantes. Como el estado está almacenado en la instancia del servicio y dicha instancia es única, la fuente de la verdad reside solamente allí.

Nuestra solución está lejos de ser perfecta, porque un componente solo recibe la cantidad de intentos restantes cuando enviamos el formulario. Cuando una instancia del componente llama a `authorize`, por el momento no hay forma de propagar dicho cambio al resto de las instancias. Exploraremos como resolver este problema en la próxima entrada de mi serie **"Técnicas de manejo de estado con RxJS"**.

<PostDetailFooter />


En este artículo aprenderemos sobre qué es un servicio y crear servicios agnósticos a nuestra UI

Servicios, servicios, servicios


La primera parte de este desafío consta en verificar la validez de una secuencia de números (nuestra data de entrada). Una secuencia es válida sólo si un número en la posición `n + 1` de la lista corresponde a la suma de exactamente dos números de los `n` números anteriores.

Consideremos la siguiente data:

```text
35
20
15
25
47
40
62
55
65
95
102
117
150
182
127
219
299
277
309
576
```

Por ejemplo, si `n` es igual `5`, el sexto número en la colección debe ser la suma de dos números entre los cinco primeros. En este caso es correcto, porque el sexto número (`40`) es la suma del tercer y cuarto número (`15` y `25` respectivamente).

Nuetra misión es encontrar el primer número en la secuencia que no cumpla con esta regla.

Nuestra solución quedaría así:

```javascript
const input =
`35
20
15
25
47
40
62
55
65
95
102
117
150
182
127
219
299
277
309
576`;

// Verifica si el número `n + 1` corresponde a la suma entre dos
// números del preámbulo, buscando si la diferencia entre el número
// objetivo y alguno de los números del preámbulo se encuentra en este
const isTargetValid = (preamble, target) =>
  preamble.some((value, _, arr) => arr.includes(target - value));

function findCorruptedNumber(preambleSize, input) {
  const preamble = input.slice(0, preambleSize);
  const target = input[preambleSize];

  // Si el número objetivo es válido, llamamos a la función
  // nuevamente, esta vez con todos los elementos de la data
  // de entrada salvo el primero. Así en la siguiente iteración
  // se chequeará el número siguiente y así sucesivamente hasta
  // dar con un dígito que no sea válido
  return isTargetValid(preamble, target)
    ? findCorruptedNumber(preambleSize, input.slice(1))
    : target;
}

findCorruptedNumber(5, input.split('\n').map(Number)); // 127
```

¡Boom! Con eso hemos resuelto la primera parte del problema.

#### Segunda parte

La segunda parte del desafío consta en encontrar una secuencia de al menos dos números continuos que sumen como total nuestro número corrupto. Debemos retornar la suma entre el número mayor y el número menor de la secuencia.

La forma de resolver este problema es bastante interesante. Comenzaremos sumando los primeros dos número de nuestra secuencia y mientras dicha suma no sea igual al número corrupto, seguiremos sumando números, el tecero, luego el cuarto y así sucesivamente, hasta alcanzar dicho valor.

Si la suma total llegara a superar el valor buscado, lo que haremos será ir restando números del principio de la secuencia. Si nuevamente el valor de la suma de la secuencia pasa a ser menor que el valor buscado, seguiremos sumando números a la derecha, hasta que eventualmente lleguemos al número exacto.

Para esto utilizaremos la siguiente función:

```javascript
const Ordering = {
  Eq: 'Eq',
  Gt: 'Gt',
  Lt: 'Lt'
}

const compare = (a, b) => {
  if (a === b) return Ordering.Eq;
  if (a < b) return Ordering.Lt;

  return Ordering.Gt;
}

function findSequence(target, input) {
  let bottom = 0; // cota a la izquiera
  let upper = 1;  // cota a la derecha

  let sum = input[bottom] + input[upper];

  while (sum !== target) {
    // Comparamos si el valor de la suma es menor, igual o mayor al objetivo 
    const ordering = compare(sum, target);

    // De ser menor, subimos la cota derecha y añadimos dicho número al total
    if (ordering === Ordering.Lt) {
      upper++;
      sum += input[upper];
      continue;
    }

    // De ser mayor, restamos dicho número del total y subimos la cota izquierda
    if (ordering === Ordering.Gt) {
      sum -= input[bottom]
      bottom++;
      continue;
    }
  }

  return input.slice(bottom, upper + 1);
}
```

Nuestra solución final quedaría así:

```javascript
const input =
`35
20
15
25
47
40
62
55
65
95
102
117
150
182
127
219
299
277
309
576`;

const isTargetValid = (preamble, target) =>
  preamble.some((value, _, arr) => arr.includes(target - value));

const Ordering = {
  Eq: 'Eq',
  Gt: 'Gt',
  Lt: 'Lt'
}

const compare = (a, b) => {
  if (a === b) return Ordering.Eq;
  if (a < b) return Ordering.Lt;

  return Ordering.Gt;
}

function findCorruptedNumber(preambleSize, input) {
  const preamble = input.slice(0, preambleSize);
  const target = input[preambleSize];

  return isTargetValid(preamble, target)
    ? findCorruptedNumber(preambleSize, input.slice(1))
    : target;
}

function findSequence(target, input) {
  let bottom = 0; // cota a la izquiera
  let upper = 1;  // cota a la derecha

  let sum = input[bottom] + input[upper];

  while (sum !== target) {
    // Comparamos si el valor de la suma es menor, igual o mayor al objetivo 
    const ordering = compare(sum, target);

    // De ser menor, subimos la cota derecha y añadimos dicho número al total
    if (ordering === Ordering.Lt) {
      upper++;
      sum += input[upper];
      continue;
    }

    // De ser mayor, restamos dicho número del total y subimos la cota izquierda
    if (ordering === Ordering.Gt) {
      sum -= input[bottom]
      bottom++;
      continue;
    }
  }

  return input.slice(bottom, upper + 1);
}

function getEncryptionWeakness(preambleSize, input) {
  const corruptedNumber = findCorruptedNumber(preambleSize, input);
  const sequence = findSequence(corruptedNumber, input);

  const min = Math.min(...sequence);
  const max = Math.max(...sequence);

  return min + max;
}

getEncryptionWeakness(5, input.split('\n').map(Number)); // 62
```

Y listo, con esto hemos resuelto el desafío del noveno día de [#AdventOfCode](https://twitter.com/hashtag/AdventOfCode).

___

Si te ha gustado el contenido, no te olvides de darle una compartida en Twitter y seguirme por [ahí](https://twitter.com/daslaf).

Gracias totales y hasta la próxima.


Advent of Code (o Advenimiento de Código) es un calendario de advenimiento de pequeños desafíos de programación que pueden ser resueltos en cualquier lenguaje de programación.

Resolviendo el desafío Advent of Code (AOC) en JavaScript

AOC Día 9 - Encoding Error


Para este desafío tenemos un listado de instrucciones como data de entrada. Las instrucciones describen la ejecución de un programa y están compuestas de dos partes: la primera parte indica un tipo de comando y la segunda data asociada a ese comando. La ejecución del programa parte en la primera línea y termina cuando llegamos a la última instrucción del listado.

Desafortunadamente una de las instrucciones del programa está mala, por lo que caemos en un *loop* infinito.

Consideremos el siguiente programa de ejemplo:

```text
nop +0
acc +1
jmp +4
acc +3
jmp -3
acc -99
acc +1
jmp -4
acc +6
```

Existen 3 tipos de instrucciones:

- `nop` hace absolutamente nada, solo mueve la ejecución del programa a la siguiente línea.
- `acc` le añade la data asociada a un acumulador (que parte en 0) y mueve la ejecución del programa a la siguiente instrucción.
- Finalmente `jmp` no modifica el acumulador, pero mueve la ejecución del programa según lo indicado en la data asociada.

Para nuestra data de entrada, la ejecución del programa sería algo así:

```text
Init
  pointer     : 0 
  accumulator : 0
-> nop +0
  pointer     : 1
  accumulator : 0
-> acc +1
  pointer     : 2
  accumulator : 1
-> jmp +4
  pointer     : 6
  accumulator : 1
-> acc +1
  pointer     : 7
  accumulator : 2
-> jmp -4
  pointer     : 3
  accumulator : 2
-> acc +3
  pointer     : 4
  accumulator : 5 <-- Resultado
-> jmp -3
  pointer     : 1 ### Duplicado
  accumulator : 5
```

En la primera parte del desafío debemos encontrar el valor del contador inmediatamente antes de que se ejecute una instrucción duplicada. Para la data de prueba el valor es `5`.

En orden de hacer esto de forma programática, vamos a utilizar –redoble de tambores, prrrrr 🥁🥁🥁– *generadores*.

<Disclaimer>Si quieres aprender sobre generadores puedes hacerlo <a href="https://developer.mozilla.org/es/docs/Web/JavaScript/Guide/Iterators_and_generators" target="_blank" rel="noreferrer noopener">aquí.</a></Disclaimer>

> Esta es definitivamente la primera vez en la vida que encuentro un uso práctico para utilizar generadores 🎉

Crearemos un generador que se encargará de recorrer el listado de instrucciones.

```javascript
const input = 
`nop +0
acc +1
jmp +4
acc +3
jmp -3
acc -99
acc +1
jmp -4
acc +6`;

// Para declarar un generador debemos usar un asterisco
function *traverser(instructions) {
  let accumulator = 0;
  let pointer = 0;

  while (instructions.length !== pointer) {
    const [ command, input ] = instructions[pointer].split(' ');

    accumulator = command === 'acc'
      ? accumulator + Number(input)
      : accumulator;
    pointer = command === 'jmp'
      ? pointer + Number(input)
      : pointer + 1;

    yield { accumulator, pointer };
  }
}

// Cuando llamamos a un generador obtenemos de vuelta un iterador
const traverse = traverser(input.split('\n'));

traverse.next(); // { done: false, value: { pointer: 1, accumulator: 0 } }
traverse.next(); // { done: false, value: { pointer: 2, accumulator: 1 } }
traverse.next(); // { done: false, value: { pointer: 6, accumulator: 1 } }
```

Podemos utilizar nuestro generador para ejecutar las instrucciones del programa y llevar un registro sobre qué instrucciones ya se han ejecutado (utilizando `pointer`). Cuando nos encontremos con una instrucción duplicada, retornaremos el valor del acumulador anterior.

Nuestra solución se vería así:

```javascript
const input = 
`nop +0
acc +1
jmp +4
acc +3
jmp -3
acc -99
acc +1
jmp -4
acc +6`;

function *traverser(instructions) {
  let accumulator = 0;
  let pointer = 0;

  while (instructions.length !== pointer) {
    const [ command, input ] = instructions[pointer].split(' ');

    accumulator = command === 'acc'
      ? accumulator + Number(input)
      : accumulator;
    pointer = command === 'jmp'
      ? pointer + Number(input)
      : pointer + 1;

    yield { accumulator, pointer };
  }
}

function getAccumulator(input) {
  const visited = new Set();
  let accumulator = null;

  // Como los generadores retornan iterables, podemos utilzar `for of`
  // para producir los valores sin llamar a .next() manualmente
  for (let value of traverser(input)) {
    if (visited.has(value.pointer)) {
      break;
    }

    accumulator = value.accumulator;

    visited.add(value.pointer);
  }
  
  return accumulator;
}

getAccumulator(input.split('\n')); // 5
```

¡Perfecto! Para la data de entrada provista hemos llegado al resultado esperado.

#### Segunda parte

Uno de los comandos en una de las instrucciones de nuestra data está corrupta. Si la reemplazamos por el commando correcto, nuestro programa puede finalizar exitosamente. Solo los comandos `nop` y `jmp` pueden estar corruptos. En otras palabras, en la data hay un `nop` que debería ser un `jmp` o un `jmp` que debería ser un `nop`.

Nuestra misión es encontrar dicho comando, reemplazarlo, correr el programa exitosamente y obetener el valor del acumulador final.

Para esto podemos utilizar algo de fuerza bruta y probar reemplazando, una por una, las instrucciones que pueden estar corruptas. Cuando una secuencia caiga en un loop infinito, simplemente probaremos reemplazando la instrucción siguiente.

Nuestra solución se vería así:

```javascript
const input = 
`nop +0
acc +1
jmp +4
acc +3
jmp -3
acc -99
acc +1
jmp -4
acc +6`;

function *traverser(instructions) {
  let accumulator = 0;
  let pointer = 0;

  while (instructions.length !== pointer) {
    const [ command, input ] = instructions[pointer].split(' ');

    accumulator = command === 'acc'
      ? accumulator + Number(input)
      : accumulator;
    pointer = command === 'jmp'
      ? pointer + Number(input)
      : pointer + 1;

    yield { accumulator, pointer };
  }
}

function getAccumulator(input) {
  const visited = new Set();
  let accumulator = null;

  for (let value of traverser(input)) {
    if (visited.has(value.pointer)) {
      // En vez de terminar el loop, retornamos null
      return null;
    }

    accumulator = value.accumulator;

    visited.add(value.pointer);
  }
  
  return accumulator;
}

// Cambia una instrucción de `jmp` a `nop` y visceversa
function swap(instruction) {
  const [ command, input ] = instruction.split(' ');

  if (command === 'acc') return instruction;

  return `${command === 'nop' ? 'jmp' : 'nop'} ${input}`;
}

// Obtenemos los índices de las instrucciones que podrían estar corruptas
const findCorruptable = sequence =>
  sequence
    .reduce((acc, entry, index) =>
      (/(jmp|nop)/).test(entry) ? acc.concat(index) : acc,
      []
    );

function getUncorruptedAccumulator(sequence) {
  const corruptable = findCorruptable(sequence);

  let result = null;

  while (result === null) {
    // Obtiene el primer indice en la lista de instrucciones
    // (mutando la secuencia)
    let index = corruptable.shift();

    if (typeof index !== 'undefined') {
      // Reemplazamos una de las instrucciones por su opuesta
      const swapedSeq = [
          ...sequence.slice(0, index),
          swap(input[index]),
          ...sequence.slice(index + 1)
        ]; 

      // `getAccumulator` retorna `null` cuando nos encontramos con
      // una secuencia corrupta, en ese caso volvemos a iterar.
      result = getAccumulator(swapedSeq);
    }
  }

  return result;
}

getUncorruptedAccumulator(input.split('\n')); // 8
```

Y listo, con esto hemos resuelto el desafío del octavo día de [#AdventOfCode](https://twitter.com/hashtag/AdventOfCode).

___

Si te ha gustado el contenido, no te olvides de darle una compartida en Twitter y seguirme por [ahí](https://twitter.com/daslaf).

Gracias totales y hasta la próxima.


AOC Día 8 - Handheld Halting


La data provista para el séptimo desafío describe las capacidades de almacenaje de diversas bolsas de distintos colores. Hay bolsas que pueden aceptar una cantidad determinada de bolsas de uno o varios colores en específico. Igualmente hay bolsas que simplement no pueden contener otras bolsas dentro de ellas.

Nuestra misión es determinar la cantidad de bolsas de distintos colores que podrían contener una bolsa de color `shiny gold`.

Consideremos la siguiente data:

```text
light red bags contain 1 bright white bag, 2 muted yellow bags.
dark orange bags contain 3 bright white bags, 4 muted yellow bags.
bright white bags contain 1 shiny gold bag.
muted yellow bags contain 2 shiny gold bags, 9 faded blue bags.
shiny gold bags contain 1 dark olive bag, 2 vibrant plum bags.
dark olive bags contain 3 faded blue bags, 4 dotted black bags.
vibrant plum bags contain 5 faded blue bags, 6 dotted black bags.
faded blue bags contain no other bags.
dotted black bags contain no other bags.
```

Por ejemplo: si las bolsas de color `bright white` contienen al menos una bolsa `shiny gold`, también debemos buscar qué otras bolsas contienen bolsas `bright white`. En este caso corresponde a las bolsas `light red` y `dark orange`. Así debemos repetir este ejercicio hasta encontrar todas las bolsas que pueden contener (ya sea directamente o dentro de otras bolsas) nuestra bolsa `shiny gold`.

Si representaramos las relaciones entre las bolsas en un sistema de nodos, básicamente tenemos que encontrar todos los nodos ancestros de un nodo en particular.

Pues como ya es costumbre, lo primero que haremos es representar nuestra data en una estructura de datos que nos facilite manipularla.

```javascript
// Retorna una tupla donde el primer elemento tiene el color de la bolsa en cuestión
// y el segundo es un arreglo con todas las bolsas que puede contener
const serializeBag = entry =>
  entry
    .split('bags contain')
    .map((entry, index) => {
      if (index === 0) return entry.trim();

      return entry
        .trim()
        .split(', ')
        .reduce((bagList, bag) => {
          if (bag.includes("no other bags")) return bagList;

          const [ quantity, ...name ] = bag.split(' ');

          return bagList.concat({
            quantity: +quantity,
            name: name.slice(0, -1).join(' ')
          });
        }, []);
    });
```

Con esto es lugar, ya podemos iterar nuestro listado de bolsas e indexar las bolsas padre de cada bolsa:

```javascript
const input =
`light red bags contain 1 bright white bag, 2 muted yellow bags.
dark orange bags contain 3 bright white bags, 4 muted yellow bags.
bright white bags contain 1 shiny gold bag.
muted yellow bags contain 2 shiny gold bags, 9 faded blue bags.
shiny gold bags contain 1 dark olive bag, 2 vibrant plum bags.
dark olive bags contain 3 faded blue bags, 4 dotted black bags.
vibrant plum bags contain 5 faded blue bags, 6 dotted black bags.
faded blue bags contain no other bags.
dotted black bags contain no other bags.`;

function indexParentsByBag(input) {
  const indexedBags = new Map(); // Este Map irá desde "nombre de bolsa" a un Set
                                 // de nombres de bolsas padre

  for (let entry of input) {
    const [ bagName, contents ] = serializeBag(entry);

    for (let bag of contents) {
      // Si la bolsa ya está en el Map
      if (indexedBags.has(bag.name)) {
          // Añadimos la bolsa padre al Set
          indexedBags.get(bag.name).add(bagName);
      } else {
          // Si no, creamos el Set
          indexedBags.set(bag.name, new Set([ bagName ]));
      }

    }
  }

  return indexedBags;
}

indexParentsByBag(input.split("\n")); /*

  Map(7) {
    'bright white' => Set(2) { 'light red', 'dark orange' },
    'muted yellow' => Set(2) { 'light red', 'dark orange' },
    'shiny gold' => Set(2) { 'bright white', 'muted yellow' },
    'faded blue' => Set(3) { 'muted yellow', 'dark olive', 'vibrant plum' },
    'dark olive' => Set(1) { 'shiny gold' },
    'vibrant plum' => Set(1) { 'shiny gold' },
    'dotted black' => Set(2) { 'dark olive', 'vibrant plum' }
  }

*/
```

Y luego solo basta con recorrer de manera recursiva nuestro `Map` hasta llegar a los nodos hojas (que no se encuentran en el Map pues no pueden contener bolsas): 

```text
shiny gold => bright white => light red
                           => dark orange
           => muted yellow => light red
                           => dark orange
```

Si contamos los nodos únicos, obtenemos como respuesta 4 bolsas. Nuestra solución final quedaría así:

```javascript
const input =
`light red bags contain 1 bright white bag, 2 muted yellow bags.
dark orange bags contain 3 bright white bags, 4 muted yellow bags.
bright white bags contain 1 shiny gold bag.
muted yellow bags contain 2 shiny gold bags, 9 faded blue bags.
shiny gold bags contain 1 dark olive bag, 2 vibrant plum bags.
dark olive bags contain 3 faded blue bags, 4 dotted black bags.
vibrant plum bags contain 5 faded blue bags, 6 dotted black bags.
faded blue bags contain no other bags.
dotted black bags contain no other bags.`;

const serializeBag = entry =>
  entry
    .split('bags contain')
    .map((entry, index) => {
      if (index === 0) return entry.trim();

      return entry
        .trim()
        .split(', ')
        .reduce((bagList, bag) => {
          if (bag.includes("no other bags")) return bagList;

          const [ quantity, ...name ] = bag.split(' ');

          return bagList.concat({
            quantity: +quantity,
            name: name.slice(0, -1).join(' ')
          });
        }, []);
    });

function indexParentsByBag(input) {
  const indexedBags = new Map();

  for (let entry of input) {
    const [ bagName, contents ] = serializeBag(entry);

    for (let bag of contents) {
      if (indexedBags.has(bag.name)) {
          indexedBags.get(bag.name).add(bagName);
      } else {
          indexedBags.set(bag.name, new Set([ bagName ]));
      }

    }
  }

  return indexedBags;
}

const indexedBags = indexParentsByBag(input.split("\n"));

function countParents(bagName) {
  const parents = new Set();

  function iter(bagName) {
    const bags = indexedBags.get(bagName) || [];

    for (let bag of bags) {
      parents.add(bag);
      iter(bag);
    }

    return parents.size;
  }

  return iter(bagName);
}

countParents('shiny gold'); // 4
```

¡Perfecto! Para la data de entrada provista hemos llegado al resultado esperado.

#### Segunda parte

En la segunda parte del desafío tenemos que contar la cantidad concreta de bolsas que una bolsa en particular puede tener.

Por ejemplo, una bolsa `shiny gold` contiene **1** bolsa `dark olive` y **2** bolsas `vibrant plum`, o sea **3** bolsas en total. Pero estas bolsas contienen más bolsas, por ejemplo la bolsa `vibrant plum` contiene **5** bolsas `faded blue` y **6** bolsas `dotted black`, que serían **11** bolsas más, pero como nuestra `shiny gold` contiene 2 bolsas `vibrant plum`, entonces en total serían 22 bolsas en ese nodo. Hagamos un diagrama para entender esto más fácilmente:

```text
shiny gold x1 => dark olive x1   => faded blue   x3 => {}
                                 => dotted black x4 => {}
                                    total : 3 + 4
                 total : 1 + 1 * ( 3 + 4 )

              => vibrant plum x2 => faded blue   x5 => {}
                                 => dotted black x6 => {}
                                    total : 5 + 6
                 total : 2 + 2 * ( 5 + 6 )

total : 1 + 1 * ( 3 + 4 ) + 2 + 2 * ( 5 + 6 )
total : 32
```

Entonces una bolsa `shiny gold` puede contener hasta 32 bolsas dentro de ella.

El ejercicio acá es muy parecido al anterior, salvo que ahora debemos agrupar las bolsas por sus contenidos y recursivamente contar cuantas bolsas contiene cada bolsa.

Analicemos nuestra solución final:

```javascript
const input =
`light red bags contain 1 bright white bag, 2 muted yellow bags.
dark orange bags contain 3 bright white bags, 4 muted yellow bags.
bright white bags contain 1 shiny gold bag.
muted yellow bags contain 2 shiny gold bags, 9 faded blue bags.
shiny gold bags contain 1 dark olive bag, 2 vibrant plum bags.
dark olive bags contain 3 faded blue bags, 4 dotted black bags.
vibrant plum bags contain 5 faded blue bags, 6 dotted black bags.
faded blue bags contain no other bags.
dotted black bags contain no other bags.`;

// El mismo serializeBag de la primera parte
const serializeBag = entry =>
  entry
    .split('bags contain')
    .map((entry, index) => {
      if (index === 0) return entry.trim();

      return entry
        .trim()
        .split(', ')
        .reduce((bagList, bag) => {
          if (bag.includes("no other bags")) return bagList;

          const [ quantity, ...name ] = bag.split(' ');

          return bagList.concat({
            quantity: +quantity,
            name: name.slice(0, -1).join(' ')
          });
        }, []);
    });

// Crea un diccionario con las bolsas y sus contenidos
const indexBags = input =>
  input
    .reduce((bagIndex, entry) => {
      const [ bagName, contents ] = serializeBag(entry);
      return Object.assign(
          bagIndex,
          { [bagName]: contents }
      )
    }, {});

const indexedBags = indexBags(input.split("\n"));

// Cuenta el total de bolsas
function countTotalChildrenBags(bagName) {
    let totalBags = 0;

    function iter(bagName) {
        const bags = indexedBags[bagName];
        let innerBags = 0;

        for (let bag of bags) {
            innerBags = innerBags + bag.quantity + bag.quantity * (iter(bag.name));
        }

        return totalBags + innerBags;
    }

    return iter(bagName);
}

countTotalChildrenBags('shiny gold'); // 32
```


Y listo, con esto hemos resuelto el desafío del séptimo día de [#AdventOfCode](https://twitter.com/hashtag/AdventOfCode).

___

Si te ha gustado el contenido, no te olvides de darle una compartida en Twitter y seguirme por [ahí](https://twitter.com/daslaf).

Gracias totales y hasta la próxima.


AOC Día 7 - Handy Haversacks


En este desafío nuestra data de entrada representa las respuestas positivas de un formulario  grupo –las preguntas están numeradas alfabéticamente–. Los grupos están separados por una línea en blanco y pueden tener uno o más integrantes, donde las respuestas de cada integrante se encuentran en una línea nueva.

En la primera parte del desafío debemos encontrar la suma total de todas las respuestas positivas por grupo. Si dos o más integrantes de un grupo han respondido la misma pregunta de forma positiva, eso contaría como solo una respuesta positiva dentro del grupo.

Considerando la siguiente data:
```text
abc     | Grupo 1, 1 integrante   -> 3 respuestas ✅

a       |
b       |
c       | Grupo 2, 3 integrantes  -> 3 respuestas ✅

ab      |
ac      | Grupo 3, 2 integrantes  -> 3 respuestas ✅  

a       |
a       |
a       |
a       | Grupo 4, 4 integrantes  -> 1 respuesta ✅  

b       | Grupo 5, 1 integrante   -> 1 respuesta ✅  
```

El total de respuestas positivas es `3 + 3 + 3 + 1 + 1 = 11`. Como nos hemos dado cuenta, no nos interesan las respuestas duplicadas por grupo, por lo que podemos hacer uso de un `Set` para obtener solamente las respuestas únicas.

Nuestra solución se vería así:

```javascript
const input =
`abc

a
b
c

ab
ac

a
a
a
a

b`;


const countPositiveAnswers = input => 
    input
        .split("\n\n")
        .reduce((total, group) => {
            // Reemplazamos los saltos de línea de cada grupo y obtenemos
            // de vuelta un string de una sola línea con todas las respuestas del grupo
            const str = group.replace(/[\n\r]+/g, '');
            const chars = new Set(str);

            return chars.size + total;
        }, 0);

countPositiveAnswers(input); // 11
```

Como los strings en JavaScript implementan `Symbol.iterator`, al instanciar nuestro `Set` con un string, este tendrá todos los caracteres únicos del string, lo que es perfecto para nuestro caso. Y listo, para la data de entrada provista hemos llegado al resultado esperado.

#### Segunda parte

Sucede que el criterio para contar respuestas positivas por grupo ha cambiado. Debemos contar solo las preguntas que todos los miembros del grupo han contestado positivamente. Afortunadamente no es mucho el código que debemos cambiar para soportar este caso.

La solución final luciría así:

```javascript
const input =
`abc

a
b
c

ab
ac

a
a
a
a

b`;

const countBy = testFn => collection =>
    collection.reduce((count, item) => testFn(item) ? count + 1 : count, 0);

const countPositiveAnswers = input => 
    input
        .split("\n\n")
        .reduce((total, group) => {
            const rows = group.split(/[\n\r]+/g);
            const chars = new Set(rows.join(""));

            // Utilizamos nuestro `countBy` definido en el desafío del día 4
            const found = countBy(
                char => rows.every(row => row.includes(char))
            )(Array.from(chars));

            return found + total;
        }, 0);

countPositiveAnswers(input); // 6
```

Y listo, con esto hemos resuelto el desafío del sexto día de [#AdventOfCode](https://twitter.com/hashtag/AdventOfCode).

___

Si te ha gustado el contenido, no te olvides de darle una compartida en Twitter y seguirme por [ahí](https://twitter.com/daslaf).

Gracias totales y hasta la próxima.


AOC Día 6 - Custom Customs


La primera parte del desafío nos pide encontrar el número de identificación más grande de un asiento dada la tarjeta de abordaje provista como input.

En vez de utilizar un sistema de coordenadas, los números de asiento están codificados utilizando una partición binaria del espacio. El avión tiene 128 filas de asientos y 8 asientos (columnas) por fila.

Un número de asiento es un string de diez caracteres donde los primeros siete –`B` de *back* (atrás) y `F` de *front* (frente)– indican el número de fila y los tres restantes –`L` de *left* (izquierda) y `R` de *right* (derecha)– el número de columna. Por ejemplo, para la entrada `FBFBBFFRLR`, el primer caracter es `F`, eso indica que está en la mitad delantera del avión, entre las filas 0 y 63. El siguiente caracter es `B`, o sea en la mitad trasera de la mitad delatera, es decir entre las filas 32 y 63. Repitiendo el proceso llegamos a que el número de fila es 44. Aplicando el mismo principio para la columna, obtenemos la columna 5.

Como los números de fila y columna son solo una representación binaria, bastaría simplemente con reemplazar `B`s y `F`s por `0`s y `1`s (lo mismo aplica para las columans):

```javascript
const seat = "FBFBBFFRLR";

const row = seat.slice(0, 7);
const col = seat.slice(7);

const toBinary = (zero, one) =>
    entry => entry
        .replaceAll(zero, 0)
        .replaceAll(one, 1);

const findRow = row => parseInt(toBinary("F", "B")(row), 2);
const findCol = col => parseInt(toBinary("L", "R")(col), 2);

console.log("Fila: ", findRow(row));    // Fila: 44
console.log("Columna: ", findCol(col)); // Columna: 5
```
Con esto se hace muy simple calcular el id de cada asiento. Nuestra solución final se vería así:

```javascript
const input = 
`BFFFBBFRRR
FFFBBBFRRR
BBFFBBFRLL`;

const toBinary = (zero, one) =>
    entry => entry
        .replaceAll(zero, 0)
        .replaceAll(one, 1);

const findRow = row => parseInt(toBinary("F", "B")(row), 2);
const findCol = col => parseInt(toBinary("L", "R")(col), 2);

// Calculamos el número de id con la siguiente fórmula
const getId = (row, col) => row * 8 + col;

const getIdsList = input =>
    input
        .split("\n")
        .map(seat => {
            const row = seat.slice(0, 7);
            const col = seat.slice(7);

            return getId(findRow(row), findCol(col));
        });

const getHighestId = input => Math.max(...getIdsList(ids));

getHighestId(input); // 820
```

Perfecto! Para la data de entrada provista hemos llegado al resultado esperado.

#### Segunda parte

Debo confesar que me costó entender un poco la segunda parte del enunciado, pero finalmente es se trata de encontrar el número de asiento en el pase de abordaje (la data de entrada). La pista que nos dan es que en el listado de `id`s se encuentran el sucesor y el antecesor de nuestros ids. Como la formula para calcular los ids es lineal, significa que bastaría con ordenar nuestro listado de ids y ver cual es el que falta en la secuencia.

Para esto podemos implementar una función que recorra el listado ordenado descendentemente de ids:

```javascript
const findMissingId = sortedIds => {
    for (let i = 0; i < sortedIds.length; i ++) {
        const left = sortedIds[i];
        const right = sortedIds[i + 1];

        if (left - right === 2) {
            return left - 1;
        }
    }

    return null;
}
```

Nuestra solución final se vería así:

```javascript
const input = 
`<TU_DATA_AQUÍ>`; // Pon tu data aquí

const toBinary = (zero, one) =>
    entry => entry
        .replaceAll(zero, 0)
        .replaceAll(one, 1);

const findRow = row => parseInt(toBinary("F", "B")(row), 2);
const findCol = col => parseInt(toBinary("L", "R")(col), 2);

// Calculamos el número de id con la siguiente fórmula
const getId = (row, col) => row * 8 + col;

const findMissingId = sortedIds => {
    for (let i = 0; i < sortedIds.length; i ++) {
        const left = sortedIds[i];
        const right = sortedIds[i + 1];

        if (left - right === 2) {
            return left - 1;
        }
    }

    return null;
}

const getIdsList = input =>
    input
        .split("\n")
        .map(seat => {
            const row = seat.slice(0, 7);
            const col = seat.slice(7);

            return getId(findRow(row), findCol(col));
        });

const getSeatId = input => {
    const ids = getIdsList(input).sort((a, b) => a > b ? -1 : 1);
        
    return findMissingId(ids);
}

getSeatId(input); // <tu asiento aquí>
```

Y listo, con esto hemos resuelto el desafío del quinto día de [#AdventOfCode](https://twitter.com/hashtag/AdventOfCode).

___

Si te ha gustado el contenido, no te olvides de darle una compartida en Twitter y seguirme por [ahí](https://twitter.com/daslaf).

Gracias totales y hasta la próxima.


AOC Día 5 - Binary Boarding


Este desafío consta en validar que cierta información de unos pasaportes esté completa en los registros de un aeropuerto imaginario. Lamentablemente la data viene formateada de mala manera, por lo que antes de hacer cualquier cosa debemos normalizarla.

Un archivo con la información de los pasaportes podría verse de la siguiente forma:

```text
ecl:gry pid:860033327 eyr:2020 hcl:#fffffd
byr:1937 iyr:2017 cid:147 hgt:183cm

iyr:2013 ecl:amb cid:350 eyr:2023 pid:028048884
hcl:#cfa07d byr:1929

hcl:#ae17e1 iyr:2013
eyr:2024
ecl:brn pid:760753108 byr:1931
hgt:179cm

hcl:#cfa07d eyr:2025 pid:166559648
iyr:2011 ecl:brn hgt:59in
```

Cada pasaporte está separado por una fila en blanco, y los campos del pasaporte pueden estar ordenados de cualquier forma.

Hablando de campos, he aquí el listado de todos los campos que un pasaporte debe tener:
- `byr`: *Birth Year*
- `iyr`: *Issue Year*
- `eyr`: *Expiration Year*
- `hgt`: *Height*
- `hcl`: *Hair Color*
- `ecl`: *Eye Color*
- `pid`: *Passport ID*
- `cid`: *Country ID*

Para que un pasaporte sea válido, todos los campos deben estar presentes (salvo `cid` por una razón necesaria para seguir con la trama de la historia). Nuestro objetivo es contar cuantos pasaportes cumplen con los criterios de validación.

Para resolver este desafío haremos uso de una par de técnicas de programación funcional, como funciones de orden mayor, currying y composición de funciones.

<Disclaimer>Pro tip: Si quieres aprender sobre estos conceptos, date una vuelta por <a href="introduccion-a-ramda-js-parte-0" target="_blank">acá.</a></Disclaimer>

Comenzaremos por definir una función que nos permita iterar el listado de pasaportes y contar los que cumplen con los criterios de validación. Como esto es algo que ya hemos hecho bocha de veces, introduciremos una función utilitaria a la que llamaremos `countBy`:

```javascript
const countBy = testFn => collection =>
    collection.reduce((count, item) => testFn(item) ? count + 1 : count, 0);
```

`countBy` es una función curriada que recibe una función de prueba y retorna una función que espera una colección de elementos. Esta función interna retorna el total de elementos que pasan la función de prueba. La función será aplicada en cada elemento de la colección, de retornar `true` aumentaremos el valor del contador. De retornar `false` simplemente mantenemos el contador.

```javascript
// Dado que `countBy` es una función curriada podemos decir que esto:
const countValidPassports = rawPassports => countBy(validationFn)(passports);

// Es equivalente a esto:
const countValidPassports = countBy(validationFn);

function validationFn(rawPassport) {
    // Determina de alguna manera si un pasaporte es válido o no
}
```

Sólo nos queda por implementar nuestra función `validationFn`. Para saber si un pasaporte es válido o no, primero debemos serializar la data del pasaporte –que ahora está toda en un string– a una estructura de datos que nos permita trabajar con ella de forma más fácil.

Para ello definiremos una función `rawPassportToObject`, que nos ayudará a transformar la información de un pasaporte a una representación que nos sirva mejor para evaluar su validez:

```javascript
// Retorna un objeto de tipo { [kay]: value } donde `key` corresponde
// al nombre de los campos y value al valor del campo
const rawPassportToObject = entry => 
    entry
        .split(/\n|\s/g) // obtenemos un listado de los componentes del string
        .reduce((acc, entry) => {
            const [ key, value ] = entry.split(':');

            return Object.assign(acc, { [key]: value });
        }, {});

const rawPassport =
`ecl:gry pid:860033327 eyr:2020 hcl:#fffffd
byr:1937 iyr:2017 cid:147 hgt:183cm`;

rawPassportToObject(rawPassport); // { byr: "1937", cid: "147", ecl: "gry", eyr: "2020", hcl: "#fffffd", hgt: "183cm", iyr: "2017", pid: "860033327" }
```

Dicho esto, ya podemos contar nuestros *passwords* válidos. Nuestra solución completa queda así:

```javascript
const input =
`ecl:gry pid:860033327 eyr:2020 hcl:#fffffd
byr:1937 iyr:2017 cid:147 hgt:183cm

iyr:2013 ecl:amb cid:350 eyr:2023 pid:028048884
hcl:#cfa07d byr:1929

hcl:#ae17e1 iyr:2013
eyr:2024
ecl:brn pid:760753108 byr:1931
hgt:179cm

hcl:#cfa07d eyr:2025 pid:166559648
iyr:2011 ecl:brn hgt:59in`;

// Definimos un Map donde señalamos que campos son requeridos y cuales no
const fields = new Map([
    ['byr', true],
    ['iyr', true],
    ['eyr', true],
    ['hgt', true],
    ['hcl', true],
    ['ecl', true],
    ['pid', true],
    ['cid', false]
]);

const countBy = testFn => collection =>
    collection.reduce((count, item) => testFn(item) ? count + 1 : count, 0);

const rawPassportToObject = entry => 
    entry
        .split(/\n|\s/g)
        .reduce((acc, entry) => {
            const [ key, value ] = entry.split(':');

            return Object.assign(acc, { [key]: value });
        }, {});

const isValidPassport = passport => {
    for (const [field, required] of fields) {
        // De ser requerido el campo, verificamos que exista en nuestro pasaporte
        if (required && !passport.hasOwnProperty(field) ) {
            return false;
        }
    }

    return true;
}

const countValidPassports = countBy(rawPassport => {
    const passport = rawPassportToObject(rawPassport);

    return isValidPassport(passport);
});

countValidPassports(input.split("\n\n")); // |> 2 ✅
```

Perfecto! Para la data de entrada provista hemos llegado al resultado esperado.

#### Segunda parte

Hasta ahora solo hemos estado validando que los campos existan dentro del pasaporte. La segunda parte del desafío nos pide validar la data de entrada de cada campo según las siguientes reglas:

- `byr` (Birth Year) - cuatro dígitos; mínimo 1920 y 2002 como máximo.
- `iyr` (Issue Year) - cuatro dígitos; mínimo 2010 y 2020 como máximo.
- `eyr` (Expiration Year) - cuatro dígitos; mínimo 2020 y 2030 como máximo.
- `hgt` (Height) - un número seguido de `cm` o `in`:
  - De ser `cm`, el número debe ser mínimo 150 y máximo 193.
  - De ser `in`, el número debe ser mínimo 59 y máximo 76.
- `hcl` (Hair Color) - un `#` seguido de exactamente 6 caracteres entre 0-9 o a-f.
- `ecl` (Eye Color) - exactamente uno de: `amb`, `blu`, `brn`, `gry`, `grn`, `hzl` o `oth`.
- `pid` (Passport ID) - dígito de nueve números, incluyendo ceros a la izquierda.
- `cid` (Country ID) - ignorado, se encuentre o no.

Dicho esto, queremos tener una forma estandarizada de ejecutar una función de validación para cada uno de los campos de nuestro pasaporte. Igualemente definiremos funciones de validación que cumplan con las reglas establecidas para cada campo. Nuestra solución completa quedaría así:

```javascript
const input =
`ecl:gry pid:860033327 eyr:2020 hcl:#fffffd
byr:1937 iyr:2017 cid:147 hgt:183cm

iyr:2013 ecl:amb cid:350 eyr:2023 pid:028048884
hcl:#cfa07d byr:1929

hcl:#ae17e1 iyr:2013
eyr:2024
ecl:brn pid:760753108 byr:1931
hgt:179cm

hcl:#cfa07d eyr:2025 pid:166559648
iyr:2011 ecl:brn hgt:59in`;

// Validadores

const isWithinRange = (min, max) => value => (+value >= min && +value <= max);

const heightValidator = {
    'cm': isWithinRange(150, 193),
    'in': isWithinRange(59, 76)
};

const isValidHeight = value => {
    if (!value) return false;
    if (!(/\d+(?=(cm|in))/).test(value)) return false;

    const [ height, unit ] = value.match(/\d+(?=(cm|in))/);

    return unit && height ? heightValidator[unit](height) : false;
};

const isHex = value => /#(\d|[a-f]){6}/gi.test(value || '');

const isValidEyes = value => [ 'amb', 'blu', 'brn', 'gry', 'grn', 'hzl', 'oth' ].includes(value || '');

const isValidPid = value => /^\d{9}$/.test(value || '');

const validators = new Map([
    ['byr', isWithinRange(1920, 2002)],
    ['iyr', isWithinRange(2010, 2020)],
    ['eyr', isWithinRange(2020, 2030)],
    ['hgt', isValidHeight],
    ['hcl', isHex],
    ['ecl', isValidEyes],
    ['pid', isValidPid],
    ['cid', () => true]
]);

function validateEntry(entry) {
    for (const [field, validator] of validators) {
        const value = entry[field];

        if (!validator(value)) {
            return false;
        }
    }

    return true;
}

const countBy = testFn => collection =>
    collection.reduce((count, item) => testFn(item) ? count + 1 : count, 0);

const rawPassportToObject = entry => 
    entry
        .split(/\n|\s/g)
        .reduce((acc, entry) => {
            const [ key, value ] = entry.split(':');

            return Object.assign(acc, { [key]: value });
        }, {});

const countValidPassports = countBy(rawPassport => {
    const passport = rawPassportToObject(rawPassport);

    return validateEntry(passport);
});

countValidPassports(input.split("\n\n")); // |> 2 ✅
```

Y listo, con esto hemos resuelto el desafío del cuarto día de [#AdventOfCode](https://twitter.com/hashtag/AdventOfCode).

___

Si te ha gustado el contenido, no te olvides de darle una compartida en Twitter y seguirme por [ahí](https://twitter.com/daslaf).

Gracias totales y hasta la próxima.


AOC Día 4 - Passport Processing


El enunciado de este problema es bastane largo por lo que intentaré explicarlo de forma concisa. El desafío consta en recorrer una matriz de `n` filas por `m` columnas (el mapa de un bosque, compuesto de senderos y árboles), partiendo desde la esquina superior izquierda. Dada la naturaleza generativa de los bosques, el patrón se repite horizontalmente hacia el infinito.

Consideremos la siguiente data de entrada:

```text
..##.......
#...#...#..
.#....#..#.
..#.#...#.#
.#...##..#.
..#.##.....
.#.#.#....#
.#........#
#.##...#...
#...##....#
.#..#...#.#
```

Los puntos (`.`) marcan los senderos y los signos gato (`#`) señalan donde hay árboles.

Recorreremos el patrón de forma constante, moviéndonos desde el punto de partida `3` espacios a la derecha y `1` hacia abajo. Dicho esto, podemos marcar todos los puntos que forman nuestra trayectoria en un diagrama, señalando con una `O` donde hay sendero (`.`) y con una `X` donde hay un árbol (`#`).

```text
|- rep 1 -||- rep 2 -||- rep 3 -||-  etc  -|
O.##.........##.........##....... -------->
#..O#...#..#...#...#..#...#...#..
.#....X..#..#....#..#..#....#..#.
..#.#...#O#..#.#...#.#..#.#...#.#
.#...##..#..X...##..#..#...##..#.
..#.##.......#.X#.......#.##..... -------->
.#.#.#....#.#.#.#.O..#.#.#.#....#
.#........#.#........X.#........#
#.##...#...#.##...#...#.X#...#...
#...##....##...##....##...#X....#
.#..#...#.#.#..#...#.#.#..#...X.# -------->
```

Debemos contar la cantidad de árboles que nos encontramos en nuestro recorrido hacia el final del mapa. Para este mapa, la cantidad de árboles es 7.

En esta ocasión utilizaremos recursión para recorrer nuestro mapa.

#### Una palabrita sobre recursividad

Una función recursiva es una función que se llama así misma. Cualquier proceso iterativo se puede describir por medio de recursividad. Por ejemplo podemos implementar una versión de `Array.prototype.map` utilizando solamente recursividad:

```javascript
function reallyInefficcientMap(projectionFn, collection) {
  const [ first, ...rest ] = collection;

  return [
    projectionFn(first),
    ...(
      rest.length === 0
        ? []
        : reallyInefficcientMap(projectionFn, rest)
    )
  ];
}

reallyInefficcientMap(n => n + 1, [1, 2, 3, 4]); // [2, 3, 4, 5]
```

Si bien esta función cumple su acometido, es extremandamente ineficiente. Podemos comprobarlo haciendo un pequeño benchmark entre `Array.prototype.map` y nuestro `map`, y ver la diferencia en el tiempo de ejecución de ambas funciones.

```javascript
// Generamos un set de datos con diez mil entradas
const data = Array(10000)
  .fill('')
  .map((_, i) => i);

console.time('Native map');
data.map((n) => n + 1);
console.timeEnd('Native map');
// ⏰  Native map: 0.344970703125 ms

console.time('Really inefficient map');
reallyInefficcientMap(n => n + 1, data);
console.timeEnd('Really inefficient map');
// ❌ |> Uncaught RangeError: Maximum call stack size exceeded -> Oopsie 🙊
```

Nuestra función es tan ineficiente que de hecho el navegador colapsa porque la pila de llamadas se llenó y nos hemos quedado sin memoria.

El problema de nuestra implementación de `reallyInefficcientMap` es que cada vez que asignamos una variable dentro del cuerpo de la función, estamos distribuyendo memoria que se mantendrá ocupada hasta que la función recursiva haya terminado de ejecutarse y el motor de JavaScript pueda hacer *garbage collection* (o en otras palabras liberar la memoria que estaba siendo ocupada). 

Por ejemplo:

```javascript
reallyInefficcientMap(n => n + 1, data);
/**
 * Contexto de ejecución
 * 
 * reallyInefficcientMap
 *    args[0]: n => n + 1
 *    args[1]: [0, 1, 2, ... 9999]
 * 
 * La función `reallyInefficcientMap` es invocada. Internamente se crean las variables
 * `first` y `rest` dentro del contexto de ejecución, que almacenarán el
 * primer elemento de la colección y el resto de la colección respectivamente.
 */

const [ first, ...rest ] = collection;

/**
 * Luego retornamos un arreglo nuevo aplicando la función de proyección con
 * `first` como primer elemento e invocamos nuevamente a `reallyInefficcientMap`
 * con el resto de la colección (si quedan elementos en ella).
 */ 
return [
  projectionFn(first),
  ...(
    rest.length === 0
      ? []
      : reallyInefficcientMap(projectionFn, rest)
  )
];
```

Toda la memoria que hemos alocado antes de llamar a nuestra función nuevamente, estará ocupada. Como este proceso iterativo se repite hasta que termine la recursión, es entendible que nos quedemos sin memoria disponible antes de que termine la recursión.

En ciertos lenguajes de programación el compilador puede optimizar una función recursiva si es que esta es una función recursiva de cola. Es decir, si lo último que hace la función es llamarse a sí misma.

<Disclaimer>⚠️ Desafortunadamente los browsers y motores de JavaScript no implementan optimizaciones de recursividad de cola, por lo que debemos guardar mucho cuidado en la <em>performance</em> de nuestro programa al decidir resolver un problema utilizando recursividad.</Disclaimer>

Dicho eso, sigamos con la resolución de nuestro problema. Utilizando lo que ya sabemos de recursión nuestra solución se vería así:

```javascript
const input =
`..##.......
#...#...#..
.#....#..#.
..#.#...#.#
.#...##..#.
..#.##.....
.#.#.#....#
.#........#
#.##...#...
#...##....#
.#..#...#.#`;

const Point = {
  Empty: '.',
  Tree: '#',
  isTree: point => point === Point.Tree
}

const Slope = {
  Right: 3,
  Down: 1,
}

function run(input) {
  const rows = input.split('\n');
  const colWidth = rows[0].length;

  // Definimos una función que nos ayudará a recorrer fila por fila
  // nuestro mapa
  function goToNextRow(rows, colPosition, foundTrees) {
    // Si ya no quedan filas por recorrer, retornamos los árboles
    // encontrados
    if (!rows[0]) return foundTrees;

    const content = rows[0][colPosition];

    return goToNextRow(
      // Como debemos movernos hacia la siguiente fila, básicamente
      // estamos acortando el mapa por la cantidad determinada por Slope.Down
      rows.slice(Slope.Down),

      // Para calcular la posición de la columna en la que quedaremos,
      // podemos usar el operador módulo. Si `colPosition + Slope.Right`
      // es mayor o igual al ancho de la columna, significa que ya nos
      // hemos desbordado del mapa por la derecha. El módulo nos dice 
      // básicamente por cuantas casillas nos hemos desbordado.
      (colPosition + Slope.Right) % colWidth,

      // Si el sitio al que llegamos tenía un árbol, incrementamos la cantidad
      Point.isTree(content) ? foundTrees + 1 : foundTrees
    );
  }

  // Partimos en la posición en la esquina superior izquierda con 0 árboles encontrados
  return goToNextRow(rows, 0, 0);
}

run(input); // 7
```

Perfecto! Para la data de entrada provista hemos llegado al resultado esperado.

### Segunda parte

En la segunda parte del desafío debemos aplicar distintos *slopes* en los que nos podemos mover a través del map, y luego obtener el producto entre todos los árboles encontrados para cada *slope*.

Lo único que debemos cambiar en nuestra función `run` es que ahora le pasamos el slope como parámetro. El resto de nuestra función queda exactamente igual:

```javascript
function run(input, slope) {
  const rows = input.split('\n');
  const colWidth = rows[0].length;

  function goToNextRow(rows, colPosition, foundTrees) {
    if (!rows[0]) return foundTrees;

    const content = rows[0][colPosition];

    return goToNextRow(
      rows.slice(slope.Down),
      (colPosition + slope.Right) % colWidth,
      Point.isTree(content) ? foundTrees + 1 : foundTrees
    );
  }

  return goToNextRow(rows, 0, 0);
}
```

Para obtener el producto de los árboles, podríamos hacerlo igualmente (ya lo entendiste) con recursividad!

```javascript
function getProduct([ trees, ...rest ]) {
  if (rest.length === 0) return trees;

  return trees * getProduct(rest);
}

getProduct([
  run(input, { Right: 1, Down: 1}),
  run(input, { Right: 3, Down: 1}),
  run(input, { Right: 5, Down: 1}),
  run(input, { Right: 7, Down: 1}),
  run(input, { Right: 1, Down: 2}),
]); // 336
```

Y listo, con esto hemos resuelto el desafío del tercer día de [#AdventOfCode](https://twitter.com/hashtag/AdventOfCode).

---

Si te ha gustado el contenido, no te olvides de darle una compartida en Twitter y seguirme por [ahí](https://twitter.com/daslaf).

Gracias totales y hasta la próxima.


AOC Día 3 - Toboggan Trajectory


El segundo desafío de AOC consiste en contar cuantos *passwords* válidos existen en un grupo de entradas. Consideremos la siguiente data:

```text
1-3 a: abcde
1-3 b: cdefg
2-9 c: ccccccccc
```

La data viene de la siguiente forma:
- Los números en primera columna señalan la cantidad de veces que debe salir un caracter en el *password*
- En la segunda columna sale el caracter en cuestión
- Y finalmente en la tercera sale nuestro *password*

Siguiendo estas reglas, el primer password sí es válido, pues la letra `a` sale 1 vez; el segundo es inválido, pues la letra `b` no sale al menos 1 vez; y el tercero es válido porque la letra `c` aparece 9 veces.

En este caso la cantidad de passwords válidos para este set de datos es 2.

Para poder procesar nuestra data primero debemos transformarla en una representación que nos sea útil. Para esto utilizamos la función `String.prototype.split` para dividir nuestro texto de entrada por cada salto de línea. Con esto conseguiremos un arreglo donde cada entrada corresponde a una fila.

```javascript
const input =
`Foo
Bar
Baz`;

input.split('\n'); // ['Foo', 'Bar', 'Baz']
```

Adicionalmente vamos a tomar cada fila y descomponerla en las variables que necesitamos para validar una entrada sea válida. Como `input.split('\n')` nos retorna un arreglo, podemos utilizar `Array.prototype.map` para obtener un arreglo de vuelta con cada fila formateada:

```javascript
const input =
`1-3 a: abcde
1-3 b: cdefg
2-9 c: ccccccccc`;

function getRowComponents(row) {
    // Dividimos cada entrada por un espacio en blanco y luego
    // utilizando `destructuring`, accedemos a los elementos en cada posición
    // del arreglo que obtenemos al llamar a `row.split(' ')`.
    const [ range, letter, pass ] = row.split(" ");
                                        
    // Luego separamos la cantidad mínima y máxima de caracteres (y de paso los
    // transformamos en números).
    const [ min, max ] = range.split("-").map(n => +n);

    // Y retornamos nuestra data, para el caso de `letter`, nuestra data luce
    // así `a:`. Como no nos interesa el `:`, solo accederemos al primer caracter. 
    return { min, max, letter: letter[0], pass };
}

input.split('\n').map(getRowComponents); // [{ min: 1, max: 3, letter: 'a', pass: 'abcde' }, ..etc ]
```

Finalmente debemos implementar nuestra función que cuente cuantos passwords son válidos. Podemos separar el proceso de conteo del proceso de validación, por lo que primero definiremos una función que solamente valide una entrada:

```javascript
function isValidPassword(password) {
    // Utilizando una expresión regular podemos contar cuantas veces un caracter
    // se encuentra en un string. `String.propotype.match` nos retorna un arreglo
    // con todos los elementos que cumplan con la expresión regular. Así podemos saber
    // cuantas veces se repite un caracter (con el largo del arreglo).
    // De no hacer match, retorna `null`.
    const ocurrences = password.pass.match(new RegExp(password.letter, 'g'));

    // Si no hay ocurrencias, decimos que el password no es válido
    if (!ocurrences) return false;

    // Si la cantidad de apariciones está fuera del rango, decimos
    // que el password no es válido
    if (ocurrences.length < password.min || ocurrences.length > password.max) return false;

    // Si nada de eso sucede, entonces es válido
    return true;
}
```

Para contar cuántos passwords son válidos podemos hacerlo de dos formas y para explicarlas me gustaría usar una metáfora.

> Imaginemos que tenemos un cajón con manzanas <span style={{ color: "var(--green)" }}>verdes</span> y <span style={{ color: "var(--red)" }}>rojas</span>.<br/>
> Si queremos saber cuantas manzanas <span style={{ color: "var(--green)" }}>verdes</span> tenemos, podríamos separar las manzanas discriminándolas por su color, tomando cada manzana del cajón y preguntándonos <em>"¿De qué color es esta manzana?"</em>.<br/>
> Si la manzana es <span style={{ color: "var(--green)" }}>verde</span> la ponemos en una pila y si es <span style={{ color: "var(--red)" }}>roja</span>, en otra. Luego cuando ya estén todas las manzanas separadas, procedemos a contarlas.
> Pero bajo cierto punto de vista esto parece muy trabajoso. ¿Por qué no aprovechamos de contar nuestras manzanas mientras las separo?

Dicho eso, si utilizamos el primer *approach* para nuestros passwords, sería equivalente a hacerlo de la siguiente forma:

```javascript
const countValidPasswords = input =>
    input
        .split('\n')
        .map(getRowComponents)
        .filter(isValidPassword)
        .length;
}
```

En cada paso estamos tomando una colección de elementos, procesando cada uno de ellos y retornando una colección nueva. Si nuestra colleción tuviera mil entradas, tendríamos que primero transformar esas mil entradas y luego filtrarlas. Es decir nuestro algoritmo iteraría al menos dos mil veces.

Si decidiéramos usar el segundo `approach`, aplicaríamos cada una de estas operaciones mientras vamos procesando cada entrada de nuestra data. Para este tipo de cosas, podemos recurrir a `.reduce()`:

```javascript
const countValidPasswords = input =>
    input
        .split('\n')
        .reduce((total, row) => {
            // Magia ✨
        }, 0)
```

Lo que haremos dentro de la función que le pasamos a `reduce` es formatear cada entrada, determinar si el *password* es válido y de serlo, retornamos el nuevo valor total, que no es más que `total + 1`. Si el password es inválido, simplemente retornamos `total`.

Nuestra solución final quedaría así:

```javascript
const input =
`1-3 a: abcde
1-3 b: cdefg
2-9 c: ccccccccc`;

function getRowComponents(row) {
    const [ range, letter, pass ] = row.split(" ");
    const [ min, max ] = range.split("-").map(n => +n);

    return { min, max, letter: letter[0], pass };
}

function isValidPassword(password) {
    const ocurrences = password.pass.match(new RegExp(password.letter, 'g'));

    if (!ocurrences) return false;
    if (ocurrences.length < password.min || ocurrences.length > password.max) return false;

    return true;
}

const countValidPasswords = input =>
    input
        .split('\n')
        .reduce((total, row) => {
            const password = getRowComponents(row);

            return isValidPassword(password)
                ? total + 1
                : total;
        }, 0);

countValidPasswords(input); // 2
```

Y ya va, hemos resuelto la primera parte de nuestro problema.

#### Segunda parte

En la segunda parte del desafío nos encontramos con que el criterio de validación para los *passwords* cambia. Afortunadamente como hemos escrito nuestro código respetando el principio de responsabilidad única, cambiar el criterio de validación sólo implica reimplementar nuestra función `isValidPassword`.

El nuevo criterio de validación indica que los dígitos que obtenemos en la primera columna de cada entrada indica las posiciones dentro del password en donde el caracter podría estar. Para que un password sea válidp, solamente una posición debe contener el caracter. Si es que el caracter se repite en ambas posiciones, el password es inválido.

Uilizando la data de ejemplo:
- `1-3 a: abcde` es válido: la posición 1 contiene `a` y la posición `3` no.
- `1-3 b: cdefg` es inválido: ni la posición `1` ni `3` contienen la letra `b`.
- `2-9 c: ccccccccc` es inválido: ambas posiciones `2` y `9` contienen la letra `c`.

Reimplementando nuestra función de validación:

```javascript
function isValidPassword(password) {
    const firstMatch = password.pass[password.min - 1];
    const secondMatch = password.pass[password.max - 1];

    // Si ambos caracteres en las posiciones son iguales, decimos que
    // el password es inválido
    if (firstMatch === secondMatch) return false;

    // Si ninguno de los carecteres son iguales al caracter provisto
    // en la data de entrada, decimos que el password es inválido
    if (password.letter !== firstMatch && password.letter !== secondMatch) return false;

    // Si nada de eso sucede, entonces es válido
    return true;
}
```

Y listo, si ejecutamos nuestra función de conteo, obtenemos que el resultado final es 1.

Nuestra solución final quedaría así:

```javascript
const input =
`1-3 a: abcde
1-3 b: cdefg
2-9 c: ccccccccc`;

function getRowComponents(row) {
    const [ range, letter, pass ] = row.split(" ");
    const [ min, max ] = range.split("-").map(n => +n);

    return { min, max, letter: letter[0], pass };
}

function isValidPassword(password) {
    const firstMatch = password.pass[password.min - 1];
    const secondMatch = password.pass[password.max - 1];

    if (firstMatch === secondMatch) return false;
    if (password.letter !== firstMatch && password.letter !== secondMatch) return false;

    return true;
}

const countValidPasswords = input =>
    input
        .split('\n')
        .reduce((total, row) => {
            const password = getRowComponents(row);

            return isValidPassword(password)
                ? total + 1
                : total;
        }, 0);

countValidPasswords(input); // 1
```

Y listo, con esto hemos resuelto el segundo día de desafíos de [#AdventOfCode](https://twitter.com/hashtag/AdventOfCode).

___

Si te ha gustado el contenido, no te olvides de darle una compartida en Twitter y seguirme por [ahí](https://twitter.com/daslaf).

Gracias totales y hasta la próxima.


AOC Día 2 - Password Philosophy


El primer desafío de AOC consiste en calcular el producto de dos números en un listado cuya suma sea `2020`. Por ejemplo, consideremos el siguiente listado de números:

```javascript
const nums = [ 1721, 979, 366, 299, 675, 1456 ];
```

En este caso `1721` y `979` suman `2020`. El resultado esperado es el producto de ambos números, `1721 * 299 = 514579`, por lo tanto `514579` es nuestro resultado.

La forma más simple de resolver el ejercicio sería implementando una función que itere el listado, partiendo por el primer número (índice 0) y buscar la diferencia de `2020` con este en el resto de los números (a partir del índice 1).

De encontrar dicho número, nuestra función retorna el producto de ambos números.

De no encontrarlo, pasamos al siguiente número del listado (índice 1) y repetimos el proceso, esta vez a partir del número contiguo (índice 2). Así seguimos buscando la diferencia del número en el índice `n` a partir del índice `n + 1` hasta que demos con el número indicado.

Una implementación imperativa puede lucir así:

```javascript
function getProduct(list) {
    for (let i = 0; i < list.length; i++) {
        const target = 2020 - list[i];

        for (let j = i + 1; j < list.length ; j++) {
            if (target === list[j]) return list[i] * list[j];
        }
    }
}
```

Si bien esta implementación es correcta tiene un problema de *performance*. Para hacer visible este problema, vamos a tener un contador con la cantidad iteraciones que realiza nuestra función para encontrar el resultado.

```javascript
function getProduct(list) {
    let iter = 0;

    for (let i = 0; i < list.length; i++) {
        const target = 2020 - list[i];

        for (let j = i + 1; j < list.length ; j++) {
            iter++;

            if (target === list[j]) {
                console.log(`Total iterations : ${iter}`)
                return list[i] * list[j];
            }
        }
    }
}
```

Si ejecutamos nuestro ejemplo con el set de datos del ejemplo, podemos ver que nuestro código toma tres iteraciones:

```javascript
const nums = [ 1721, 979, 366, 299, 675, 1456 ];

getProduct(nums);
// Total iterations : 3
```

Pero esto cambia drásticamente si ahora nuestros números se encontraran al final de la lista:

```javascript
const nums = [ 979, 366, 675, 1456, 1721, 299 ];

getProduct(nums);
// Total iterations : 15
```

Esto se conoce como Complejidad de Computo. Si alguna vez has oído sobre *Big O Notation* pues bien, de esto se trata. *Big O* no es más que un sistema para medir la tasa de crecimiento de un algoritmo.

Según [este excelente artículo](https://jarednielsen.com/big-o-quadratic-time-complexity/), nuestra implementación tiene complejidad cuadrática, es decir, que la cantidad de cómputos que realice nuestro algoritmo, va a crecer al cuadrado según crezca la cantidad de elementos la lista.

> Si ejecutaramos nuestro algoritmo con una lista de 200 entradas y sucediera que los números que buscamos están ambos al final de la lista, nuestro algoritmo iteraría 19.900 veces 🤯.

#### Mejorando performance

Para reducir la complejidad de computo de nuestro algoritmo, podemos replantear como resolver nuestro problema fiándonos en el hecho de que al iterar la colección sabemos efectivamente cuál es el complemento que estamos buscando. La diferencia es que ahora en vez de buscarlo en el resto de la colección, sólo lo buscaremos dentro de los números que ya hayamos visitado.

La gracia es que si no encontramos el complemento `m` de un número `n` en el registro de números que ya hemos visitado, cuando sea turno de `m` en nuestra interación, ya tendremos a `n` en nuestro registro y por lo tanto podemos retornar el producto de `n * m`.

Igualmente para hacer de esta búsqueda más rápida, indexaremos nuestros números en una estructura de datos que nos permita acceder a ellos en tiempo constante, como por ejemplo en un objeto. No importa a cuál de sus propiedades de un objeto queramos acceder, la operación siempre va a tener una complejidad constante.

Nuestra implementación se vería así:

```javascript
function getProduct(list) {
    const nums = {};

    for (let num of list) {
        const expected = 2020 - num;

        if (nums[expected]) return num * expected;

        nums[num] = num;
    }
}
```

Y voilá, ahora `getProduct` es eficiente y tiene complejidad lineal. Si aplicamos nuestra función con la [data de entrada](https://adventofcode.com/2020/day/1/input) del desafío, obtenemos `1018336` como respuesta.

#### Segunda parte

La segunda parte del desafío añade un poco más de complejidad, ya que ahora debemos encontrar tres números que cumplan con la regla, por ejemplo: 979, 366 y 675. Esto significa que el complemento para `n` ya no es un número `m` que podemos encontrar en la lista, sino que la suma de `l` y `m`, o sea dos números del listado.

Para conseguir nuestro acometido podemos implementar una función auxiliar (muy similar a `getProduct`) que nos retorne una tupla de números cuya suma sea igual al complemento de `n`:

```javascript
function getAdditionFactors(target, list, nums) {
    for (let num of list) {
        const expected = target - num;

        if (nums[expected]) return [ num, expected ];

        nums[num] = num;
    }

    return null;
}
```

Es posible que no encontremos un par de números cuya suma satisfaga el valor que esperamos, en ese caso retornaremos `null`.

La función `getAdditionFactors` igualmente va a aceptar como último argumento un diccionario donde irá guardando los números a los que ya hemos accedido, así podemos reducir ciclos de iteración si es que nuestro número esperado ya fue almacenado en iteraciones previas.

Con esto dicho, implementaremos nuestra nueva función:

```javascript
function getThreeWayProduct(list) {
    const nums = {};

    for (let num of list) {
        const expectedSum = 2020 - num;
        const factors = getAdditionFactors(expectedSum, list, nums);

        if (factors) return num * factors[0] * factors[1];
    }
}
```

Y listo, con esto hemos resuelto el primer día de desafíos de [#AdventOfCode](https://twitter.com/hashtag/AdventOfCode). Si aplicamos nuestra función con la [data de entrada](https://adventofcode.com/2020/day/1/input) del desafío, obtenemos `288756720` como respuesta.

___

Si te ha gustado el contenido, no te olvides de darle una compartida en Twitter y seguirme por [ahí](https://twitter.com/daslaf).

Gracias totales y hasta la próxima.


AOC Día 1 - Report Repair


Hace unos días estuve en el meetup de [BeerJS Valdivia](https://valdivia.beerjs.cl/) hablando sobre cómo modelar efectos secundarios en React utilizando RxJS. Hacia el final de la charla, que puedes ver por [acá](https://youtu.be/F2SOzMPCGC8?t=2248), surgió una pregunta sobre qué formas podrían existir para manejar el estado de una aplicación con RxJS.

Pues a partir de esa pregunta me he quedado pensando y qué mejor forma que responderla escribiendo un artículo.

> En esta serie de artículos vamos a explorar 3 formas en las que podemos hacer manejo de estado utilizando RxJS.

<br />

- [Creando un Store a la redux con RxJS]({{ page.url }}) (este mismo artículo☝️)
- Servicios *stateful* con streams reactivos (próximamente)
- Implementando el patrón BLoC con RxJS (próximamente)

### Creando un Store a la redux.

Pues una de las formas más comunes de manejar estados con RxJS es implementando un *Store* que almacenará el estado de nuestra aplicación. Podemos enviar comandos a nuestro *Store* y modificar su estado interno utilizando un *reducer*, que no es más que una función pura que va a describir cómo el estado de la aplicación se transformará según el comando o acción que haya sido emitido.

Para esto podemos utilizar un `BehaviorSubject` de `rxjs`, que es una especie de `EventEmitter` en esteroides:

- Un `BehaviorSubject` es *multicast*, es decir, puede tener múltiples suscriptores.
- Cada vez que un observador se suscribe al `BehaviorSubject`, es notificado de forma síncrona sobre el último valor emitido por el sujeto. Gracias a esto nos aseguramos que todos los observadores del sujeto estén actualizados con el estado actual.
- A diferencia de un `Subject` común y corriente, un `BehaviorSubject` deber ser instanciado con un valor inicial (si lo pensamos, tiene sentido dado el comportamiento que describimos en el punto anterior).

Una implementación básica de nuestro *Store* podría lucir así:

```javascript
import { BehaviorSubject } from 'rxjs';

function createStore(initialValue, reducer) {
    const store = new BehaviorSubject(initialValue);
    let previousState;

    return {
        subscribe: (observer) => {
          store.subscribe({
            next: (value) => {
              previousState = value;
              observer(value);
            }
          })
        },
        dispatch: (action) => {
            const newState = reducer(previousState, action);

            store.next(newState);
        },
    }
}

function counterReducer(previousValue, action) {
  switch (action.type) {
    case 'INCREMENT':
      return {
        count: previousValue.count + 1
      }
    case 'DECREMENT':
      return {
        count: previousValue.count - 1
      }
    default:
      return previousValue;
  }
}

const counterStore = createStore({ count: 0 }, counterReducer);

counterStore.subscribe(v => console.log(`Count A :: ${v.count}`)); // Count A :: 0

counterStore.dispatch({ type: 'INCREMENT' }); // Count A :: 1
counterStore.dispatch({ type: 'INCREMENT' }); // Count A :: 2

counterStore.subscribe(v => console.log(`Count B :: ${v.count}`)); // Count :: 2

counterStore.dispatch({ type: 'INCREMENT' }); // Count A :: 3
                                              // Count B :: 3
counterStore.dispatch({ type: 'DECREMENT' }); // Count A :: 2
                                              // Count B :: 2
```

Veamos paso a paso la implementación de `createStore`.

Para crear nuestro *Store* necesitamos un valor inicial y una función (un *reducer*) que se encargará de describir las transiciones de estado en él.

Inicializamos nuestro `BehaviorSubject` utilizando `initialValue` como valor inicial:

```javascript
function createStore(initialValue, reducer) {
    const store = new BehaviorSubject(initialValue);
    // ...
}
```

A continuación definimos un método `subscribe`, que recibe como parámetro un observador. Internamente nos suscribimos al `BehaviorSubject` y cada vez que este emita un nuevo valor, propagaremos ese valor al observador que recibimos como parámetro. Esto nos permite almacenar una referencia al último valor emitido, que va a ser necesaria cuando llamemos al método `dispatch` para calcular el nuevo estado del *Store*:

```javascript
function createStore(initialValue, reducer) {
    const store = new BehaviorSubject(initialValue);
    let previousState;

    return {
        subscribe: (observer) => {
          store.subscribe({
            next: (value) => {
              previousState = value;
              observer(value);
            }
          })
        },
        dispatch: (action) => {
            // ...
        },
    }
}
```

Finalmente implementamos `dispatch` como una función que toma como argumento una acción y ejecuta el `reducer` utilizando `previousState` (que guardamos cada vez que un valor nuevo se emite en el `BehaviorSubject`) y la acción para calcular el nuevo estado de nuestro sujeto. Despachamos el estado nuevo utilizando el método `next` de nuestro sujeto.

```javascript
function createStore(initialValue, reducer) {
    const store = new BehaviorSubject(initialValue);
    let previousState;

    return {
        subscribe: (observer) => {
          store.subscribe({
            next: (value) => {
              previousState = value;
              observer(value);
            }
          })
        },
        dispatch: (action) => {
            const newState = reducer(previousState, action);

            store.next(newState);
        },
    }
}
```

Y *voilá*. Como puedes ver, una implementación mínima de un *Store* a la redux es posible utilizando una estructura como `BehaviorSubject`, que nos permite almacenar estado y propagar los cambios por medio de una estrategia de tipo *push*. Algo muy importante y que nos permite utilizar este *approach* es que, como mencionamos, el `BehaviorSubject` es *multicast*.

Ya veremos en los próximos artículos por qué esto es tan importante.

<PostDetailFooter />


Este artículo trata sobre cómo implementar un store al estilo redux para manejar estado utilizando un patrón orientado a transiciones gatilladas por mensajes

Técnicas de manejo de estado con RxJS, parte 1

Creando un Store a la redux con RxJS


Hace muchos años atrás, en los tiempos en que MooTools recién había sido publicado y yo tenía mi primera aproximación al mundo de la programación con J2SE 1.4 circa 2007 (por cierto, en aquél entonces NUNCA habría pensado dedicarme al desarrollo de software, pero esa es otra historia), [Christian Heilmann](https://twitter.com/codepo8) publicó [un artículo en su blog](https://christianheilmann.com/2007/08/22/again-with-the-module-pattern-reveal-something-to-the-world/) hablando sobre un patrón de diseño que denominó como *The Revealing Module Pattern*:

```javascript
var someService = (function () {
  var privateValue = 42;
  
  function privateMethod() { /* ... */ }
  
  function publicMethod() { /* ... */ }

  function anotherPublicMethod() { /* ... */ }

  return {
    publicMethod: publicMethod,
    anotherPublicMethod: anotherPublicMethod
  };
})();
```

La innovación de este patrón (en aquél entonces) es que al encapsular nuestro código en una IIFE, generamos un *scope* que nos permite declarar variables privadas y métodos privados, y sólo exponemos los miembros públicos explícitamente al retornarlos en un objeto literal.

> Recuerdo haber aprendido sobre *The Revealing Module Pattern* en la guía de estilos de AngularJs escrita por John Papa. Uff, qué recuerdos.

Sin embargo con la avenida de ES2015, la estandarización de las clases y la especificación de módulos en JavaScript, este patrón comenzó a caer en desuso, ya que los módulos ESM y las clases son mecanismos naturales de encapsulación.

Si reescribimos nuestro ejemplo utilizando módulos ESM nos basta con decir:

```javascript
// someService.js
const privateValue = 42;

function privateMethod() { /* ... */ }
  
function publicMethod() { /* ... */ }

function anotherPublicMethod() { /* ... */ }

export default { publicMethod, anotherPublicMethod };
```

Una de las cosas que particularmente no me gusta de esta solución, es que en cuanto más crece nuestro archivo, se hace más difícil identificar a simple vista qué contiene la API pública.

Igualmente hay ciertos miembros de nuestro módulo que no queremos acoplar a nuestro servicio, si no que exportarlos de forma independiente, por lo que ahora incluso tenemos 2 niveles de *exports*. Este problema se acentúa aún más cuando por ejemplo, usamos TypeScript, ya que probablemente definamos algunos tipos dentro de nuestro archivo:

```typescript
// someService.ts
const privateValue = 42;

const anotherPrivateValue = 23;

enum SomeEnumerable = {
  Foo,
  Bar
}

type SomeUnionType = 'foo' | 'bar' | 'baz';

// ... more stuff

function privateMethod() { /* ... */ }
  
function publicMethod() { /* ... */ }

// ... even more stuff

function anotherPublicMethod() { /* ... */ }

export default { publicMethod, anotherPublicMethod, publicMethodGallore };
export { SomeEnumerable, SomeUnionType, MoreStuff };
```

Pues bien, una mejor forma de organizar este mini caos es utilizar el (redoble de tambores 🥁🥁🥁) *Revealing Module Pattern*:

```typescript
// someService.ts
enum SomeEnumerable = {
  Foo,
  Bar
}

type SomeUnionType = 'foo' | 'bar' | 'baz';

// ... more stuff

const someService = (() => {
  return {
    publicMethod,
    anotherPublicMethod,
    publicMethodGallore,
  };

  const privateValue = 42;
  const anotherPrivateValue = 23;

  function privateMethod() { /* ... */ }
  
  function publicMethod() { /* ... */ }

  // ... even more stuff

  function anotherPublicMethod() { /* ... */ }
})();

export default someService;
export { SomeEnumerable, SomeUnionType, MoreStuff };
```

¡Y listo! Ahora todas las cosas pertinentes al servicio quedan encapsuladas dentro de la función (que en nuestro IDE podríamos colapsar, si es que no nos interesa ver el contenido de esta) y lo *extra* queda fuera.

Un pequeño truco que podemos utilizar para hacer más fácil de identificar la API pública de nuestro servicio, es valernos del mecanismo de hoisting de las funciones en JavaScript y retornar el objeto literal antes de declarar las funciones. Una limitante de esto es que las funciones deben ser declaradas utilizando la sintaxis `function name(arg) { /* etc */ }`. Igualmente si queremos exponer una constante o algo distinto a una función, debemos declararla antes del `return`, pero siendo honesto en general cuando hacemos servicios, la mayoría de las veces nuestros servicios no tienen estado y sólo queremos exponer métodos.

---

Y eso ha sido todo por hoy. Si te ha gustado el contenido, no te olvides de darle una compartida en Twitter y seguirme por [ahí](https://twitter.com/daslaf).

Gracias totales y hasta la próxima.


Cómo podemos utilizar este patrón de diseño junto a JavaScript moderno

Cómo encapsular servicios con un patrón simple

Revealing Module Pattern en 2020


<Disclaimer>Este artículo no es un tutorial de React ni tampoco de RxJS. Si no sabes absolutamente nada sobre RxJS, te recomiendo comenzar por <a href="https://tech.cornershop.io/programaci%C3%B3n-reactiva-con-rxjs-bebc9432485f" target="_blank" rel="noopener noreferrer">este artículo</a>.</Disclaimer>

RxJS es una librería para realizar Programación Funcional Reactiva (PFR desde ahora) en JavaScript. Si buscas en internet qué es **PFR**, probablemente encuentres muchas definiciones muy _cool_ y cada una más complicada que la anterior.

Por lejos mi definición de **PFR** favorita es la siguiente:

> _La esencia de la programación funcional reactiva es especificar el comportamiento dinámico de un valor al momento de su declaración_
>
> – Heinrich Apfelmus

<Vapor>Mindblowing</Vapor>

**¿Qué significa esto?**

Cuando hacemos **PFR** intentamos definir cómo el valor de una variable va a ir cambiando a través del tiempo al momento de declarar dicha variable. Puede resultar un poco extraño imaginar cómo luciría código de esta naturaleza, porque JavaScript no nos provée primitivas para hacer definiciones de este tipo.

En React existe una forma de definir el valor de una variable que _podría_ satisfacer esta definición, pero con algunas limitantes. Consideremos el siguiente ejemplo:

```javascript
const greeting = React.useMemo(() => `${greet}, ${name}!`, [greet, name]);
```

`useMemo` nos permite definir un valor que será computado cada vez que sus dependencias cambien. En nuestro caso particular, el valor de `greeting` será recalculado dependiendo de los valores de `greet` y `name`. Cabe mencionar que `greeting` es sólo el resultado de la expresión `` `${greet}, ${name}!` ``, sucede que con `useMemo` podemos controlar cuándo es recalculado el valor de nuestra expresión, lo que es conveniente para nuestra definición de reactividad.

¡Maravilloso! Y todo podría quedar hasta ahí y viviríamos felices. Pero pero pero, `useMemo` sólo nos permite definir `greeting` cuando `greet` y `name` cambian, mas no nos proporciona ninguna información sobre dónde y cómo estos valores son actualizados. 

La pregunta del millón entonces es ¿Cómo y dónde es que estas dependencias cambian?

### La verdad de la milanesa

Expandiendo nuestro ejemplo, podríamos tener el siguiente componente:

```javascript
import * as React from 'react';

const GreetSomeone = ({ greet = 'Hello' }) => {
    const [name, setName] = React.useState('World');
    const greeting = React.useMemo(() => `${greet}, ${name}!`, [greet, name]);

    React.useEffect(() => {
        fetchSomeName().then(name => {
            setName(name);
        }, () => {
            setName('Mololongo');
        });
    }, []);

    return <p>{greeting}</p>;
};
```

Nuestro componente `GreetSomeone` recibe `greet` por medio de `props` y `name` como resultado de una promesa que nos retorna `fetchSomeName()`.

Si bien seguimos definiendo `greeting` de la misma manera que en el ejemplo inicial, no podemos determinar sólo leyendo su definición que el valor de una de sus dependencias proviene de una promesa y que es un valor asíncrono.

En JavaScript no existen primitivas para determinar la naturaleza asíncrona del valor de esta expresión (tampoco en React).

### Observables al rescate

Dejemos React a un lado por el momento y veamos cómo podríamos llegar a nuestra definición ideal utilizando RxJS. Partiremos definiendo dos Observables que emitirán los valores de `greet` y `name`, y los compondremos para obtener un Observable que represente el valor de `greeting`:

```javascript
import { combineLatest, of } from 'rxjs';
import { map } from 'rxjs/operators';

const greet$ = of('Hello');
const name$ = of('World');

const greeting$ = combineLatest(greet$, name$).pipe(
    map(([greet, name]) => `${greet}, ${name}!`)
);

greeting$.subscribe(greeting => {
    console.log(greeting);    
});

// ✏️: "Hello, World!" -- En cuanto nos suscribimos a greeting$
```

Recordemos que en nuestro ejemplo de React el valor de `name` proviene de una promesa. Con RxJS definir la naturaleza asíncrona de `name` es sencillo, sólo tenemos que cambiar la definición de `name$` de la siguiente manera:

```javascript
import { combineLatest, from, of } from 'rxjs';
import { catchError, map, startWith } from 'rxjs/operators';

const greet$ = of('Hello');
const name$ = from(fetchSomeName()).pipe(
    startWith('World'),
    catchError(() => of('Mololongo')),
);

const greeting$ = combineLatest(greet$, name$).pipe(
    map(([greet, name]) => `${greet}, ${name}!`)
);

greeting$.subscribe(greeting => {
    console.log(greeting);    
});

// ✏️: "Hello, World!"      -- En cuanto nos suscribimos a greeting$
// ✅: "Hello, Thundercat!" -- En cuanto `fetchSomeName()` se resuelva exitosamente
// ❌: "Hello, Mololongo!"  -- Si `fetchSomeName()` es rechazada
```

Y con esto ya podemos describir la naturaleza asíncrona de `name$` y por extensión, la de `greeting$`.

### De vuelta a React

Considerando todo lo dicho anteriormente ¿Cómo podemos implementar nuestra solución de RxJS en React?

Para responder esta pregunta, primero nos conviene entender el hecho de que `useMemo` es una suerte de `useState` + `useEffect`. Por ejemplo:

```javascript
const greeting = React.useMemo(() => `${greet}, ${name}!`, [greet, name]);
```

Puede ser descrito de la siguiente forma:

```javascript
const [greeting, setGreeting] = useState(() => `${greet}, ${name}!`);

useEffect(() => {
    setGreeting(() => `${greet}, ${name}!`);
}, [greet, name]);
```

Si bien en la práctica estos dos _snippets_ llegan a resultados muy similares, tiene un par de diferencias sustanciales en cómo lo hacen. El callback que le pasamos a `useEffect` se corre **después** del render, mientras que el de `useMemo` se calcula **antes** de hacer render. En otras palabras, durante el primer render el valor de `greeting` en la versión con `useMemo` ya habrá sido computado; mientras que en la versión con `useEffect`, su valor será el valor inicial cuando fue declarado con `useState`.

El hecho de que podamos describir una actualización de estado dentro de `useEffect`, indica que actualizar una variable o computar un pedazo de estado es en la práctica un efecto secundario.

Dicho esto, la estrategia para utilizar RxJS con React es básicamente **deferir el manejo de estos efectos secundarios** desde React a RxJS.

Partiremos con este proceso copiando todo nuestro código de RxJS dentro de nuestro componente `GreetSomeone`. Para que el componente se renderice correctamente cada vez que el Observable `greeting$` emita un valor, debemos persistir el valor emitido utilizando algún mecanismo conocido por React, como `useState`:

```javascript
import * as React from 'react';
import { combineLatest, from, of } from 'rxjs';
import { catchError, map, startWith } from 'rxjs/operators';

const GreetSomeone = ({ greet = 'Hello' }) => {
    const [greeting, setGreeting] = React.useState('');

    React.useEffect(() => {
        const greet$ = of(greet);
        const name$ = from(fetchSomeName()).pipe(
            startWith('World'),
            catchError(() => of('Mololongo')),
        );

        const greeting$ = combineLatest(greet$, name$).pipe(
            map(([greet, name]) => `${greet}, ${name}!`)
        );

        const subscription = greeting$.subscribe(value => {
            setGreeting(value);
        });

        return () => {
            subscription.unsubscribe();
        }
    }, []);

    return <p>{greeting}</p>;
};
```

En cuanto el componente se haya montado, el _callback_ que le hemos pasado a `useEffect` se ejecutará y con ello toda la lógica para calcular el valor de `greeting`.

Un problema de nuestra solución actual es que si el valor de la propiedad `greet` cambia, el valor de `greeting` no será recalculado. Esto se debe a que nuestro Observable `greet$` sólo se define cuando se ejecuta el efecto y esto sucede sólo una vez. Cualquier cambio en el valor de `greet` no tendrá ingerencia en la definición de `greet$` (y por lo tanto en el observable `greeting$`).

Una de las cosas que podríamos hacer es agregar `greet` como dependencia a `useEffect`, asegurándonos que el efecto se ejecute cada vez que el valor de `greet` cambie. Si bien esto soluciona nuestro problema, puede tener consecuencias inesperadas.

En primera instancia, el efecto se va a ejecutar cada vez que cambie el valor de `greet`. Cuando el _callback_ se ejecute no solo redefiniremos `greet$` con el último valor de `greet`, sino que también `name$` y esto llamará nuevamente a la función `getSomeName`. 

En nuestro ejemplo inicial sólo nos interesa llamar a `getSomeName` una sola vez, por lo que desechemos esta alternativa.

En mi artículo <a href="https://medium.com/noders/sobre-observables-performance-y-magia-negra-en-react-con-context-y-hooks-dae3e407f7a0" target="_blank" rel="noopener noreferrer">Sobre Observables, Performance y Magia Negra en React con Context y Hooks</a> nos enfrentamos a una situación similar, en la que intentamos exponer un pedazo de estado desde un proveedor de contexto, hacia varios componentes que consumen dicho contexto sin que el proveedor se renderice con cada cambio del valor expuesto.

La solución a la que llegamos en dicho artículo se basa en cierta particularidad sobre el arreglo de dependencias de `useEffect`. El _callback_ de `useEffect` se gatilla sólo cuando alguna de las dependencias que le pasamos cambia. En JavaScript, los valores primitivos se comparan por su valor y los valores que no son primitivos, lo hacen por referencia.

Esto significa que si estamos observando un objeto cuya referencia no cambia, no importa cuanto cambien las propiedades internas de dicho objeto. El _callback_ simplemente no se ejecutará. Sólo lo hará cuando el variable que estamos observando contenga un objeto referencialmente distinto.

Lo que haremos entonces será crear un observable `greet$` (utilizando una `ref` y un `BehaviorSubject`) que emitirá valores cada vez que `greet` cambie:

```javascript
import * as React from 'react';
import { BehaviorSubject, combineLatest, from, of } from 'rxjs';
import { catchError, map, startWith } from 'rxjs/operators';

const GreetSomeone = ({ greet = 'Hello' }) => {
    const greet$ = React.useRef(new BehaviorSubject(greet));

    // Acá observamos `greet` con `useEffect` y promovemos dicho valor a `greet$`
    React.useEffect(() => {
        greet$.current.next(greet);
    }, [greet]);

    // El resto del código queda relativamente igual
    const [greeting, setGreeting] = React.useState('');

    React.useEffect(() => {
        const name$ = from(fetchSomeName()).pipe(
            startWith('World'),
            catchError(() => of('Mololongo')),
        );

        const greeting$ = combineLatest(greet$.current, name$).pipe(
            map(([greet, name]) => `${greet}, ${name}!`)
        );

        const subscription = greeting$.subscribe(value => {
            setGreeting(value);
        });

        return () => {
            subscription.unsubscribe();
        }
    }, [greet$]);

    return <p>{greeting}</p>;
};
```

`BehaviorSubject` es una suerte de emisor de eventos al que nos podemos suscribir (tal como a un observable común y corriente), pero con el que podemos producir valores de forma imperativa (con el método `next`). Guardamos nuestro subject utilizando `useRef`, que nos sirve para persistir una referencia entre _renders_.

Si bien ahora tenemos más código, el _callback_ de nuestro `useEffect` principal se ejecuta una sola vez. Hurray!

Podemos mejorar un poco esto ocultando los detalles de implementación con un _custom hook_.

```javascript
const useObservedValue = value => {
    const subject = React.useRef(new BehaviorSubject(value));

    React.useEffect(() => {
        subject.current.next(value);
    }, [value]);

    return React.useMemo(() => subject.current.asObservable(), [subject]);
};
```

Y luego:

```javascript
const GreetSomeone = ({ greet = 'Hello' }) => {
    const greet$ = useObservedValue(greet);
    const [greeting, setGreeting] = React.useState('');

    React.useEffect(() => { /* etcétera */ }, [greet$]);

    return <p>{greeting}</p>;
};
```

> En `useObservedValue` retornamos el valor memorizado de `subject.current.asObservable()` para evitar que podamos despachar valores manualmente llamando al método `next`.

Siguiendo con la refactorización de nuestro ejemplo, podemos extraer la definición de `name$` del _callback_ de `useEffect` (de hecho, podemos sacarlo completamente de nuestro componente). Igualmente definiremos `greeting$` fuera del efecto:

```javascript
import * as React from 'react';
import { from, of } from 'rxjs';
import { catchError, map, startWith } from 'rxjs/operators';

const name$ = from(fetchSomeName()).pipe(
    startWith('World'),
    catchError(() => of('Mololongo')),
);

const GreetSomeone = ({ greet = 'Hello' }) => {
    const greet$ = useObservedValue(greet);
    const greeting$ = React.useMemo(
        () => combineLatest(greet$, name$).pipe(
            map(([greet, name]) => `${greet}, ${name}!`)
        )), []
    );

    const [greeting, setGreeting] = React.useState('');

    React.useEffect(() => {
        const subscription = greeting$.subscribe(value => {
            setGreeting(value);
        });

        return () => {
            subscription.unsubscribe();
        }
    }, [greeting$]);

    return <p>{greeting}</p>;
};
```

Finalmente nuestro `useEffect` sólo se encarga de suscribirse a `greeting$` y persistir cada valor que el observable emite por medio de `setGreeting`.

Incluso esto podríamos encapsularlo por medio de un _custom hook_:

```javascript
const useObservable = (observable) => {
    const [value, setValue] = React.useState();

    React.useEffect(() => {
        const subscription = observable.subscribe((v) => {
            setValue(v);
        });

        return () => {
            subscription.unsubscribe();
        };
    }, [observable]);

    return value;
};
```

Finalmente obtenemos:

```javascript
import * as React from 'react';
import { from, of } from 'rxjs';
import { catchError, map, startWith } from 'rxjs/operators';

const name$ = from(fetchSomeName()).pipe(
    startWith('World'),
    catchError(() => of('Mololongo')),
);

const GreetSomeone = ({ greet = 'Hello' }) => {
    const greet$ = useObservedValue(greet);
    const greeting$ = React.useMemo(
        () =>
            combineLatest([greet$, name$]).pipe(
                map(([greet, name]) => `${greet}, ${name}!`)
            ),
        [greet$]
    );

    const greeting = useObservable(greeting$);

    return <p>{greeting}</p>;
};
```

¡Y eso es! Hemos especificado el comportamiento dinámico de `greeting$` en el lugar de su definición. Puedes ver un demo <a href="https://codesandbox.io/s/using-rxjs-observables-inside-react-pjq6n" target="_blank" rel="noopener noreferrer">aquí</a>.

### Ordenando el gallinero 🐔

Ok, lo entiendo. Probablemente crees que la solución que he implementado no es de lo más limpia, y estoy de acuerdo contigo. Pero, es un buen punto de partida para entender qué es necesario para poder usar observables de RxJS en React.

En vez de utilizar nuestros propios hooks para ocultar todo el _boilerplate_ necesario para consumir observables, démosle un vistazo al mismo ejemplo utilizando <a href="https://github.com/LeetCode-OpenSource/rxjs-hooks" target="_blank" rel="noopener noreferrer">rxjs-hooks</a>:

```javascript
import * as React from 'react';
import { from, of } from 'rxjs';
import {
    catchError,
    combineLatest,
    map,
    pluck,
    startWith,
} from 'rxjs/operators';
import { useObservable } from 'rxjs-hooks';

const name$ = from(fetchSomeName()).pipe(
    startWith('World'),
    catchError(() => of('Mololongo'))
);

const GreetSomeone = ({ greet = 'Hello' }) => {
    const greeting = useObservable(
        input$ =>
            input$.pipe(
                pluck(0),
                combineLatest(name$),
                map(([greet, name]) => `${greet}, ${name}!`)
            ),
        '',
        [greet]
    );

    return <p>{greeting}</p>;
};
```

El hook `useObservable` expuesto por `rxjs-hooks` acepta 3 parámetros: el primero es una función que debe retornar un observable y recibe el observable `input$` como parámetro; el segundo es el valor inicial que tendrá `greeting`; y el tercero es un arreglo de dependencias que representa el valor que emitirá `input$`.

Cada vez que una de las dependencias observadas cambie, se emitirá el arreglo con el último valor de dichas dependencias en el observable `input$`. Esto nos permite observar la propiedad `greet` y combinarla con `name$` para componer el valor de `greeting`.

El resto es relativamente simple, utilizamos `pluck` para extraer el primer elemento del arreglo emitido por `input$` y esta vez usamos una versión del módulo de operadores de `combineLatest` para combinar el valor de greet con el de `name$`.

Como podemos ver cantidad de código se reduce bastante.

Para terminar, `rxjs-hooks` expone solo un hook más y es `useEventCallback`. Este hook recibe una función de producción que toma un observable de eventos como parámetro que representa los eventos emitidos a partir de cualquier _event handler_ que asignemos a un nodo de JSX. El hook nos retorna un callback (que le pasamos a `onClick`, por ejemplo) y el valor emitido por el observable que retorna la función de producción, tal como sucede con `useObservable`.

---

Y _voilá_, eso ha sido todo por hoy. Al utilizar `rxjs` podemos expresar el comportamiento asíncrono de nuestro estado de una forma más declarativa, por medio de composición de funciones y técnicas de programación funcional.

Igualmente nos permite modelar lógica asíncrona muy compleja que sería una pesadilla de implementar utilizando promesas.

Si bien existe un poco de fricción para utilizar React en conjunto con RxJS, podemos mejorar la forma en que estas librerías interactúan utilizando hooks de React.

Si te ha gustado el contenido, no te olvides de darle una compartida en Twitter y seguirme por [ahí](https://twitter.com/daslaf) tal vez.

Gracias totales y hasta la próxima.






Este artículo trata sobre cómo utilizar en conjunto React y RxJS.

Cómo utilizarlos en conjunto y no morir en el intento.

React y RxJS


Hace mucho tiempo que he estado intentando darle un poco más de amor a mi sitio web personal, y por qué no, empezar a publicar mis artículos en una plataforma que sienta propia. He estado escribiendo exclusivamente en **[Medium](https://medium.com/@osmancea)** por casi 2 años ya, e independiente de las controversias que han surgido en torno al modelo de monetización de la plataforma, personalmente creo que ha sido una experiencia muy positiva.

No solo me ha servido como infraestructura para preocuparme exclusivamente de escribir y no de dónde hacerlo, sino que también me ha expuesto a una audiencia a la que hubiese sido difícil llegar por mis propios medios.

Igualmente el colaborar como escritor en las publicaciones **[Angular Chile](https://medium.com/angular-chile)** y **[Noders](https://medium.com/noders)** me han hecho conocer a mucha gente muy buena onda. ¡Y hey! parte de hacer esto es compartir y pasarlo bien.

¡Pero, pero, pero! Las ganas de tener mi espacio personal vencieron la pereza (¡enhorabuena!) y finalmente aquí está, en gloria y majestad, el primero de muchos artículos en `daslaf.dev`.

### ¿Qué pasará con todo el contenido que tengo Medium?
#### La respuesta te sorprenderá

**No pasará absolutamente nada.**

Todos los artículos que he posteado hasta el día de hoy en Medium, seguirán ahí. Sin embargo voy a re-publicar los artículos en mi nuevo y brillante sitio siguiendo las siguientes reglas:

- Todos los artículos personales que he subido (esto es, bajo ninguna publicación) serán re-publicados en este sitio. Al comienzo de cada artículo en Medium voy a poner un link a la versión alojada en `daslaf.dev`. De realizar actualizaciones en dichos artículos, las voy a hacer exclusivamente en la versión nueva (o sea, acá).
- En cuanto al resto de artículos, es decir los que he publicado en **Angular Chile**, **Noders** y **[Cornershop](https://tech.cornershop.io/)**, voy a consultar con el dueño de cada publicación si es posible re-postear dichos artículos en mi sitio personal. De ser así, trataré dichos artículos de la misma forma que el grupo anterior. En el caso que no pueda re-postear, de todos modos voy a añadir una entrada nueva con enlace al artículo original en Medium.
- La migración de los artículos será un proceso gradual en el que voy a trabajar paulatinamente durante las próximas semanas.

Finalmente, todos los artículos nuevos que escriba serán publicados acá. De re-postear dichos artículos en Medium, voy a configurar la url canónica apuntando al artículo original.

### Ventajas de ir independiente

Una de las razones por las que empecé a escribir en Medium, como ya mencioné, es porque me proveyó de la infraestructura necesaria para enfocarme solo en escribir hasta lograr hacer un hábito de ello. Escribir es una actividad muy enriquecedora, pero que me costó mucho concretar. Antes de publicar mi primer artículo, probablemente hice unos diez borradores que nunca vieron la luz en un lapso de varios meses. Darle clic al botón `Publicar` (y sentirme seguro al respecto) fue un proceso bastante largo.

Ya de eso ha pasado harto tiempo y he escrito varios artículos. Afortunadamente ya no me siento tanto como un impostor en ese aspecto de mi vida profesional.

Hay otros desafíos eso sí, que me gustaría atacar y superar. Hoy por hoy, creo que uno de los mayores beneficios de tener un blog propio, es que me pone frente a uno de esos desafíos: mantener un _pet project_.

Me resulta imposible dedicar atención constantemente a algo que no me interesa. Por lo mismo tengo mucha dificultad para desarrollar _side projects_. Muy pocas veces pienso en cosas que puedan resultar útiles y que el proceso de realizarlas me brinde satisfacción. Mi tiempo de ocio es muy valioso como para dedicárselo a algo que no me produce alegría.

Desarrollar mi propio blog cumple con las reglas mínimas para manterme comprometido con el proyecto. Es algo que me trae beneficios y que continuamente voy a apuntar a mejorar. Ya sea tanto desde el diseño del blog en sí, añadir nuevos _features_, mejorar la experiencia de desarrollo y un largo etcétera.

---

En fin, creo que eso ha sido todo por hoy. Con esto damos el puntapié inicial a una nueva etapa en mi carrera de _blogger_.

Saludos y hasta pronto. 👋


Eventualmente todo mi contenido terminará aquí

Adiós Medium, que la fuerza te acompañe

Moviendo ¿casi? todo a daslaf.dev


En este artículo vamos a revisar algunos conceptos básicos y terminología necesaria para entender la filosofía detrás de Ramda.

<LinkToCanonical canonicalUrl="https://medium.com/noders/introducci%C3%B3n-a-ramda-js-parte-0-a36b1074729b" />

### Funciones puras y efectos colaterales

Las funciones puras cumplen con 3 reglas:

- Para un mismo _input_ siempre retornan el mismo _output_
- Poseen transparencia referencial (una función pura puede ser reemplazada por su resultado)
- No producen efectos colaterales

El objetivo principal al hacer programación funcional es encapsular lógica componiendo funciones puras y reducir el área en un programa donde se producen los efectos colaterales.

La ventaja de hacer esto es que al extraer los efectos secundarios de las transacciones lógicas de un programa, es mucho más fácil probar dichas transacciones y hacerlas predecibles, pues las funciones sólo dependen de sus _inputs_. Igualmente el área de superficie de un programa donde se producen _side effects_ está contenida, por lo que también es más fácil razonar sobre dichos efectos y testearlos.

Un _side effect_ o efecto colateral/secundario se refiere a una modificación de cualquier tipo de estado en un programa: desde cambiar el valor de una variable a hacer una petición http y cualquier cosa entre medio.

Todas las funciones expuestas por Ramda son funciones puras, por lo que carecen de efectos secundarios. Igualmente, todas las funciones están automáticamente curriadas. ¿Qué significa esto en estricto rigor?

### Currying

Currying es un mecanismo que nos permite aplicar (invocar) una función `f` con una cantidad parcial de argumentos y obtener de vuelta una función `g` que espera el resto de los argumentos que no le pasamos a `f`. Por ejemplo:

```js
// addSeveralNumbers es una función curriada que suma
// los 6 parámetros que recibe
const addSeveralNumbers = (a, b, c, d, e, f) => { /* ... */ }

const addAllButFirst = addSeveralNumbers(1);
const addRemainingTwo = addSeveralNumbers(1, 2, 3, 4);

addAllButFirst(2, 3, 4, 5, 6) === addRemainingTwo(5, 6) // true
```

Al definir `addAllButFirst` hemos aplicado `addSeveralNumbers` con sólo 1 argumento, por lo que `addAllButFirst` esa una función que espera los 5 parámetros restantes. En el caso de `addRemainingTwo`, hemos llamado a `addSeveralNumbers` con 4 argumentos, por lo que recibimos de vuelta una función con aridad 2.

>Aridad es un término que se utiliza para describir la cantidad de argumentos que una función espera. Una función que espera un sólo argumento tiene aridad 1. En nuestro `casoaddSeveralNumbers` tiene aridad 6, pues espera seis argumentos.

Una implementación simplificada de `addSeveralNumbers` sería:

```js
const addSeveralNumbers = a => {
  return b => {
    return c => {
      return d => {
        return e => {
          return f => {
            return a + b + c + d + e + f;
          }
        }
      }
    }
  }
};
```

O utilizando el `return` implícito de las funciones flecha:

```js
const addSeveralNumbers = a => b => c => d => e => f =>  (a + b + c + d + e + f);
```

Desafortunadamente nuestra implementación nos limita a llamar cada función con un sólo argumento, por lo que nuestra definición de `addRemainingTwo` quedaría así:

```js
const addRemainingTwo = addSeveralNumbers(1)(2)(3)(4);
```

Recordemos que `addSeveralNumbers` recibe sólo un parámetro y retorna una función. Esa función igualmente recibe sólo un parámetro y retorna otra función, y así sucesivamente cada función recibe un parámetro y retorna otra función hasta llegar a la última función que recibe el parámetro `f` y retorna la suma de `a`, `b`, `c`, `d`, `e` y `f`.

```js
addSeveralNumbers(1)(2)(3)(4)(5)(6); // 21
//| 1 => ...etc  --|
//|-- 2 => ...etc  ---|
//|---- 3 => ...etc  ----|
//|------ 4 => ...etc  -----|
//|-------- 5 => ...etc  ------|
//|---------- 6 => 1 + 2 + 3 + 4 + 5 + 6;
```

Afortunadamente Ramda incluye una función `curry` para convertir funciones comunes y corrientes en funciones curriadas y así poder realizar aplicación parcial de mejor forma:

```js
import { curry } from 'ramda';

const addSeveralNumbers = curry((a, b, c, d, e, f) => {
  return a + b + c + d + e + f;
});
```

Y luego:

```js
addSeveralNumbers(1, 2, 3, 4, 5, 6) // 21
addSeveralNumbers(1, 2, 3, 4)(5, 6) // 21
addSeveralNumbers(1)(2, 3, 4, 5, 6) // 21
addSeveralNumbers(1)(2)(3)(4)(5)(6) // 21
```

**¡Mucho mejor!**

#### ¿Cuándo es útil el currying?

Entendamos lo utilidad del _currying_ a través de un ejemplo. Para efectos demostrativos, digamos que tenemos que implementar nuestra propia versión de `Array.prototype.map`. Podríamos hacerlo de la siguiente manera:

```js
function map(projectionFn, arr) {
  const result = [];

  for (const item of arr) {
    result.push(projectionFn(item));
  }

  return result;
}
```

En este caso aplicamos la función de proyección `projectionFn` a cada elemento de nuestro arreglo inicial (sin mutarlo), retornando un nuevo arreglo:

```js
map(x => x * 2, [1, 2, 3, 4]); // [2, 4, 6, 8]
```

Si quisiéramos aplicar la misma función para múltiples arreglos, podríamos hacer algo por el estilo:

```js
const timesTwo = x => x * 2;

map(timesTwo, [1, 2, 3, 4]); // [2, 4, 6, 8]
map(timesTwo, [4, 2]);       // [8, 4]
map(timesTwo, [1, 1, 1, 3]); // [2, 2, 2, 6]
map(timesTwo, [5, 7, -3]);   // [10, 14, -6]
```

Podemos notar que para cada llamada a `map` le pasamos `timesTwo` como primer parámetro. Nuestro código podría quedar más legible si hiciéramos algo como:

```js
const timesTwo = x => x * 2;

const mapTimesTwo = arr => {
  return map(timesTwo, arr);
};

mapTimesTwo([1, 2, 3, 4]); // [2, 4, 6, 8]
mapTimesTwo([4, 2]);       // [8, 4]
mapTimesTwo([1, 1, 1, 3]); // [2, 2, 2, 6]
mapTimesTwo([5, 7, -3]);   // [10, 14, -6]
```

Desafortunadamente si también quisiéramos implementar una función que multiplica cada elemento de nuestro arreglo por 3, tenemos que duplicar la misma lógica, salvo que sólo cambiando la función que le pasamos a `map` internamente:

```js
const timesTwo = x => x * 2;
const timesThree = x => x * 3;

const mapTimesTwo = arr => map(timesTwo, arr);
const mapTimesThree = arr => map(timesThree, arr);
```

Podemos resolver este problema haciendo de `map` una función curriada:

```js
import { curry } from 'ramda';

const map = curry((projectionFn, arr) => {
  const result = [];

  for (const item of arr) {
    result.push(projectionFn(item));
  }

  return result;
});
```

Y luego re-implementamos `mapTimesTwo`:

```js
const timesTwo = x => x * 2;
const fn = map(timesTwo);

const mapTimesTwo = arr => fn(arr);
```

Fijémonos que const `mapTimesTwo = arr => fn(arr)` es idéntico a simplemente const `mapTimesTwo = fn`.

Si no te queda claro, quizás es más simple verlo así:

```js
const log = message => console.log(message);

log('foo'); // "foo"
console.log('foo'); // "foo"
```

En este caso, log es una función que recibe un parámetro message y llama a la función `console.log` pasándole el mismo parámetro. ¿Qué diferencia tiene llamar a `log` o directamente a `console.log`? Para este caso puntual, ninguna. `log` es sólo un alias de `console.log`, por lo que podríamos definirla del siguiente modo:

```js
const log = console.log; 
```

Aplicando esto en nuestro ejemplo inicial:

```js
const timesTwo = x => x * 2;
const timesThree = x => x * 3;

const mapTimesTwo = map(timesTwo);
const mapTimesThree = map(timesThree);

mapTimesTwo([1, 2, 3, 4]); // [2, 4, 6, 8]
mapTimesTwo([4, 2]);       // [8, 4]
mapTimesThree([1, 2, 3]);  // [3, 6, 9]
mapTimesThree([5, 7]);     // [15, 21]
```

¡Mucho mejor! Y todo gracias al currying.

#### Point-free style

La forma en la que acabamos de escribir nuestras funciones se conoce como estilo sin argumentos o _point-free style_. Gracias al _currying_ y a que nuestras funciones reciben como último argumento la data sobre la que operan, podemos hacer aplicación parcial de funciones sin declarar el argumento final. Todas las funciones en Ramda siguen este principio y nos da pie a escribir código declarativo de forma directa y legible. Retomemos nuestro ejemplo:

```js
import { map } from 'ramda';

const mapTimesTwo = arr => map(x => 2 * x, arr);
```

Reescribiremos esta función paso a paso utilizando _point-free style_:

```js
import { map, multiply } from 'ramda';

const mapTimesTwo = arr => map(x => multiply(2, x), arr);
```

Como `multiply` es una función curriada, `x => multiply(2, x)` es lo mismo que decir `x => multiply(2)(x)` y por lo tanto, idéntico a `multiply(2)`:

```js
import { map, multiply } from 'ramda';

const mapTimesTwo = arr => map(multiply(2), arr);
```

Y como `map` también está curriada, `arr => map(fn, arr)` es equivalente a `arr => map(fn)(arr)`, y por lo tanto idéntico a `map(fn)`. Finalmente obtenemos:

```js
import { map, multiply } from 'ramda';

const mapTimesTwo = map(multiply(2));
mapTimesTwo([1, 2, 3, 4]); // [2, 4, 6, 8]
```

Esto queda claramente más directo y fácil de leer que cualquier de nuestros ejemplos anteriores.
Como Ramda igualmente posee definiciones de tipos para TypeScript, podemos obtener muy buena inferencia de tipos en IDEs como VSCode de forma gratuita (sin necesidad de utilizar TypeScript en nuestro proyecto).

<figure>
  <img
    alt="Anotación de tipos inferidos en mapTimesTwo"
    src="/img/map-times-two-type-inference.png"
  />
  <figcaption>Anotación de tipos inferidos en mapTimesTwo</figcaption>
</figure>

En este caso VSCode nos informa que `mapTimesTwo` es una función que toma como parámetro un arreglo de números y retorna otro arreglo de números. El tipo de elementos del arreglo (`number`) es inferido a partir de la función `multiply(2)`, que retorna una función que espera recibir un número y retornar otro número.

<figure>
  <img
    alt="Anotación de tipos en multiply"
    src="/img/multiply-type-inference.png"
  />
  <figcaption>Anotación de tipos en multiply</figcaption>
</figure>

### Inmutabilidad

Finalmente, hablemos de inmutabilidad.

Al hacer programación funcional es muy importante que trabajemos nuestra data de forma inmutable. Una estructura de datos es inmutable cuando, para representar un cambio de estado, no alteramos la estructura en sí, si no que derivamos una nueva estructura de datos a partir de la original.

Mantener la inmutabilidad en nuestros programas aumenta la previsibilidad de cómo va cambiando el estado, ya que cada cambio de estado es explícito.

Al tratar los cambios de estado de forma explícita, podríamos incluso rastrearlos y generar un sistema de navegación entre los distintos estados de un programa, también conocido como [time traveling debugging](https://en.wikipedia.org/wiki/Time_travel_debugging#Time_traveling_debuggers).

Está de más decir que todas las funciones expuestas por Ramda, tratan sus argumentos de forma inmutable.

---

Eso ha sido todo por hoy. Si te ha gustado el contenido, no te olvides de darle una compartida en Twitter. En el próximo artículo vamos a hablar de composición de funciones.

Gracias totales y hasta la próxima.


Funciones puras, currying, aplicación parcial e inmutabilidad

Conceptos generales sobre programación funcional

Introducción a Ramda.js - Parte 0


La “nueva” API de Context de React (disponible desde la versión 16.3) nos permite encapsular un pedazo de estado en un contexto que es inyectable en cualquier lugar de nuestro árbol de componentes. Por ejemplo:

```javascript
import React from 'react';

const AlbumOfTheWeek = React.createContext({
  title: 'Pop Food',
  artist: 'Jack Stauber',
  genre: 'Edible Pop', // lol
});

export default AlbumOfTheWeek;
```

Luego podemos consumir los valores provistos por `AlbumOfTheWeek` en cualquier lugar de nuestra aplicación a través de un consumidor utilizando [render props](https://medium.com/@osmancea/entendiendo-render-props-en-react-dfe22f84f593):

```jsx
import React from 'react';
import ReactDOM from 'react-dom';

import AlbumOfTheWeek from './context/album-of-the-week';

function App() {
  return (
    <UserProfile />
  );
}

function UserProfile() {
  return (
    <section>
      <h1>Hi I'm Osman and this is my album of the week:</h1>
      <AlbumOfTheWeek.Consumer>
        {album => (
          <dl>
            <dt>Title:</dt>
            <dd>{album.title}</dd>
            <dt>Artist:</dt>
            <dd>{album.artist}</dd>
            <dt>Genre:</dt>
            <dd>{album.genre}</dd>
          </dl>
        )}
      </AlbumOfTheWeek.Consumer>
    </section>
  );
}

ReactDOM.render(
  <App />,
  document.getElementByID('root')
);
```

Probablemente en una aplicación real no sabremos el valor del álbum de la semana al momento de declarar el contexto `AlbumOfTheWeek` y debemos consultarlo a través de una API o algo por el estilo. En este caso lo que podemos hacer es proveer un valor para el contexto utilizando `AlbumOfTheWeek.Provider` tras haber obtenido la respuesta de nuestro servicio:

```jsx
// ...

import { getAlbumOfTheWeek } from './services/album-of-the-week';

class App extends React.Component {
  state = {
    album: null
  };

  componentDidMount() {
    getAlbumOfTheWeek().then(res => {
      this.setState({ album: res.data });
    });
  }

  render() {
    return (
      <AlbumOfTheWeek.Provider value={this.state.album}>
        <UserProfile />
      </AlbumOfTheWeek.Provider>
    );
  }
}

// ...
```

Igualmente tenemos que actualizar `UserProfile` ya que el valor inicial de album es `null` y al tratar de acceder a alguna propiedad de nuestro álbum antes de haber seteado su valor, se romperá nuestra aplicación:

```jsx
function UserProfile() {
  return (
    <section>
      <h1>Hi I'm Osman and this is my album of the week:</h1>
      <AlbumOfTheWeek.Consumer>
        {/* Renderizamos la información sólo si album es truthy */}
        {album => album && (
          <dl>
            <dt>Title:</dt>
            <dd>{album.title}</dd>
            <dt>Artist:</dt>
            <dd>{album.artist}</dd>
            <dt>Genre:</dt>
            <dd>{album.genre}</dd>
          </dl>
        )}
      </AlbumOfTheWeek.Consumer>
    </section>
  );
}
```

Como hemos proveído un valor para `AlbumOfTheWeek.Provider`, el valor por defecto que asignamos al momento de crear el contexto es ignorado.

Puedes ver un demo de la aplicación [acá](https://codesandbox.io/s/state-management-context-1-dstvc).

> Antes de continuar me gustaría comentar que algunos de estos casos pueden ser resueltos simplemente pasando los datos por props. En este caso lo hacemos con context meramente para efectos demostrativos del artículo.

### Zapatero a tus zapatos — pastelero a tus pasteles

Hasta el momento nuestro componente App se encarga de implementar la lógica para obtener la información del álbum de la semana y de renderizar `UserProfile`. Podríamos ir un paso más adelante y separar completamente estas dos responsabilidades:

```jsx
class AlbumOfTheWeekProvider extends React.Component {
  state = {
    album: null
  };

  componentDidMount() {
    getAlbumOfTheWeek().then(res => {
      this.setState({ album: res.data });
    });
  }

  render() {
    const { children } = this.props;
    return (
      <AlbumOfTheWeek.Provider value={this.state.album}>
        {children}
      </AlbumOfTheWeek.Provider>
    );
  }
}
```

Básicamente hemos transformado nuestro componente `App` en `AlbumOfTheWeekProvider` y en vez de renderizar `UserProfile`, le hemos pasado `children` al método render.

Con esto hemos conseguido una mejor separación de responsabilidades entre los elementos de nuestra aplicación. Ahora la única responsabilidad de nuestro *provider* es manipular y actualizar la data que le hemos encargado almacenar. Por otra parte `App` sólo se preocupa de renderizar `UserProfile` y conectarlo con `AlbumOfTheWeekProvider`.

Utilizamos nuestro proveedor de la siguiente forma:

```jsx
function App() {
  return (
    <AlbumOfTheWeekProvider>
      <UserProfile />
    </AlbumOfTheWeekProvider>
  );
}

ReactDOM.render(
  <App />,
  document.getElementByID('root')
);
```

Puedes ver el ejemplo actualizado [acá](https://codesandbox.io/s/state-management-context-2-dstvc).

### Introduciendo Hooks

Una de las desventajas de utilizar render props es que es muy difícil utilizar la data de nuestro contexto fuera del método render (o fuera de la función que le pasamos de hijo al consumidor). Digamos que ahora queremos implementar *client-side routing* en nuestra aplicación y al entrar a la página del álbum de la semana, queremos actualizar el título del documento con el nombre del artista y del álbum. Actualizamos nuestro componente `App` para implementar el enrutamiento utilizando `react-router`:

```jsx
import React from 'react';
import {
  BrowserRouter as Router, Switch, Route, NavLink
} from 'react-router-dom';

// ...

function App() {
  return (
    <AlbumOfTheWeekProvider>
      <Router>
        <nav>
          <NavLink exact activeClassName="active" to="/">
            Home
          </NavLink>
          <NavLink activeClassName="active" to="/album-of-the-week">
            Album
          </NavLink>
        </nav>
        <Switch>
          <Route exact path="/" component={Home} />
          <Route
            path="/album-of-the-week"
            component={UserProfile}
          />
        </Switch>
      </Router>
    </AlbumOfTheWeekProvider>
  );
}
```

Y luego en nuestro componente `UserProfile` usamos `contextType` para exponer el valor del contexto en los ciclos de vida de nuestro componente en la propiedad `this.context`:

```jsx
class UserProfile extends React.Component {
  static contextType = AlbumOfTheWeek;

  componentDidMount() {
    // ¿Actualizamos document.title aquí?
    if (this.context) {
      document.title = this.context.title;
    }
  }

  componentDidUpdate() {
    // ¿O lo actualizamos aquí?
    if (document.title !== this.context.title) {
      document.title = this.context.title;
    }
  }

  render() {
    return (
      <section>
        <h1>Hi I'm Osman and this is my album of the week:</h1>
        {this.context && (
          <dl>
            <dt>Title:</dt>
            <dd>{this.context.title}</dd>
            <dt>Artist:</dt>
            <dd>{this.context.artist}</dd>
            <dt>Genre:</dt>
            <dd>{this.context.genre}</dd>
          </dl>
        )}
      </section>
    );
  }
}
```

El problema actual es que al navegar directamente a la url `/album-of-the-week` el valor del contexto será `null` ya que probablemente aún no hemos recibido la respuesta de nuestro servicio que obtiene el álbum de la semana. Cuando el valor del contexto se actualice, se gatillará el ciclo de vida `componentDidUpdate` y podremos actualizar `document.title`.

Si navegamos primero a la ruta base `/` y luego hacemos clic en el link a `/album-of-the-week`, lo más probable es que el contexto ya tenga un valor asignado, por lo que debemos actualizar `document.title` en el ciclo `componentDidMount` (ya que `componentDidUpdate` no se va a ejecutar).

Igualmente el uso de `contextType` no es tan práctico porque está limitado a sólo un contexto por componente. De querer inyectar otro contexto para ser utilizado dentro de los ciclos de vida de `UserProfile` o dentro de algún método de la clase, no podríamos hacerlo.

Puedes ver el ejemplo actualizado [acá](https://codesandbox.io/s/state-management-context-3-9i72e).

Podemos abordar estos problemas de mejor forma utilizando `useContext`:

```jsx
function UserProfile() {
  const album = React.useContext(AlbumOfTheWeek);

  React.useEffect(() => {
    if (album) {
      document.title = album.title;
    }
  }, [album]);

  return (
    <section>
      <h1>Hi I'm Osman and this is my album of the week:</h1>
      {album && (
        <dl>
          <dt>Title:</dt>
          <dd>{album.title}</dd>
          <dt>Artist:</dt>
          <dd>{album.artist}</dd>
          <dt>Genre:</dt>
          <dd>{album.genre}</dd>
        </dl>
      )}
    </section>
  );
}
```

Como podemos ver, el valor provisto por `AlbumOfTheWeek` ahora está disponible dentro del cuerpo de la función y lo podemos usar tanto en el JSX, como en algún otro hook o dentro de un método que definamos en nuestro componente.

### Un caso de confianza

Es posible que hayas notado que para efectos de nuestra aplicación no tiene mucho sentido hacer el llamado a `getAlbumOfTheWeek` dentro de `AlbumOfTheWeekProvider` cuando entramos en la ruta `/` y cargamos el componente `Home`, pues dentro de este no tenemos necesidad de acceder al contexto. O tal vez sí creemos que es necesario cargarlo con antelación para tener la información ya disponible cuando naveguemos a `/album-of-the-week`.

Dicho eso ¿Qué aproximación es mejor? ¿Cómo decido qué hacer?

Mi única respuesta a estas interrogantes es la siguiente:

<Vapor>Concesiones mutuas</Vapor>

Y si mi respuesta suena a sinsentido es porque básicamente no hay una respuesta correcta ni una incorrecta. Finalmente es una decisión de diseño de software que tienes que tomar dependiendo de la naturaleza y de las necesidades de tu proyecto.

Frente a esto existen un par de alternativas o patrones que podemos aplicar según sea necesario y te los explico a continuación.

### Cambiar de lugar donde se provee el contexto

O en otras palabras, mover `AlbumOfTheWeekProvider` dentro de la ruta `/album-of-the-week`:

```jsx
function App() {
  return (
    <Router>
      <nav>
        <NavLink exact activeClassName="active" to="/">
          Home
        </NavLink>
        <NavLink activeClassName="active" to="/album-of-the-week">
          Album
        </NavLink>
      </nav>
      <Switch>
        <Route exact path="/" component={Home} />
        <Route
          path="/album-of-the-week"
          render={routeProps => (
            <AlbumOfTheWeekProvider>
              <UserProfile {...routeProps} />
            </AlbumOfTheWeekProvider>
          )}
        />
      </Switch>
    </Router>
  );
}
```

> Pudimos haber movido `AlbumOfTheWeekProvider` dentro de `UserProfile`, pero para nuestro ejemplo no tiene tanto sentido

Con esto nos aseguramos de que el efecto que trae nuestra data del álbum de la semana sólo se ejecutará cuando estemos en la ruta `/album-of-the-week`. La “desventaja” de esto es que si navegamos fuera de `/album-of-the-week` nuestro *provider* se desmontará, por lo que al volver a navegar a la ruta se volverá a ejecutar el llamado a `getAlbumOfTheWeek`. Cabe mencionar que esto no es algo malo per se, pero sí lo tenemos que tener en consideración.

Acá está la [demo](https://codesandbox.io/s/state-management-context-5-wgks9) actualizada.

### Contexto como una API

Otra alternativa es delegar la responsabilidad de hacer el llamado a `getAlbumOfTheWeek`, exponiendo en `AlbumOfTheWeekProvider` una API para que cualquier consumidor del contexto pueda iniciarlo:

```jsx
class AlbumOfTheWeekProvider extends React.Component {
  state = {
    album: null
  };

  constructor(props) {
    super(props);
    this.getAlbumOfTheWeek = this.getAlbumOfTheWeek.bind(this);
  }

  getAlbumOfTheWeek() {
    if (this.state.album) {
      return;
    }

    return albumService.getAlbumOfTheWeek().then((res) => {
      this.setState({ album: res.data });
    });
  }

  render() {
    const { children } = this.props;

    return (
      <Provider
        value={{
          album: this.state.album,
          getAlbumOfTheWeek: this.getAlbumOfTheWeek
        }}
      >
        {children}
      </Provider>
    );
  }
}
```

Luego en `UserProfile` mantenemos todo igual, salvo que invocamos la función expuesta por `AlbumOfTheWeek`:

```jsx
function UserProfile() {
  const { album, getAlbumOfTheWeek } = React.useContext(AlbumOfTheWeek);
  
  useEffect(() => {
    if (album) {
      document.title = album.title;
    }
  }, [album]);

  // Añadimos este efecto
  useEffect(() => {
    getAlbumOfTheWeek();
  }, [getAlbumOfTheWeek]);

  return (
    <section>
      <h1>Hi I'm Osman and this is my album of the week:</h1>
      {album && (
        <dl>
          <dt>Title:</dt>
          <dd>{album.title}</dd>
          <dt>Artist:</dt>
          <dd>{album.artist}</dd>
          <dt>Genre:</dt>
          <dd>{album.genre}</dd>
        </dl>
      )}
    </section>
  );
}
```

Con esto nos aseguramos de traer nuestra data sólo al renderizar el componente `UserProfile`. Como `AlbumOfTheWeekProvider` sigue viviendo en nuestro componente `App`, la data persistirá en el proveedor aunque cambiemos de ruta. Como “desventaja” tenemos que si existen múltiples componentes donde podríamos necesitar la data, debemos implementar la llamada a `getAlbumOfTheWeek` en cada una de ellos.

La última [demo](https://codesandbox.io/s/state-management-context-6-l4qj7).

### Conclusión

Finalmente no existe una regla de oro para implementar tus contextos y probablemente te hayan surgido algunas dudas sobre como organizar tu estado — de hecho, desde *release* de hooks, han salido muchas librerías de manejo de estado con contexto y, la comunidad ha encontrado diversos patrones alrededor de este tema.

Ya que logramos centralizar el manejo de nuestra data en un contexto, podríamos pensar en éste como un store de `redux`, `mobx` o cualquier otra solución de manejo de estados ¿Significa que debo centralizar toda mi data en el mismo contexto? ¿Debo user múltiples contextos, uno para cada tipo de data que voy a manejar? ¿Debo olvidarme de mantener estado local y apuntar por mantener mis componentes de presentación completamente estúpidos?

En mi opinión creo que el approach de dividir y conquistar ha tenido muy buenos resultados en mi día a día. Puedes crear un *provider* por cada tipo de entidad (usuarios, tiendas, productos, cuentas, etc…) que estés manejando y a su vez tener otro *provider* más general y centralizado para manejar información transversal a toda la aplicación.

Finalmente no todo el estado de tu aplicación debe estar centralizado. Sí tiene ventajas hacerlo, porque te ayuda a definir barreras y responsabilidades acotadas para cada actor de tu programa, pero en muchos casos de negocio puedes mantener estado a nivel de componente porque tiene sentido hacerlo así. A final de cuentas y como lo habrás notado, nuestro `AlbumOfTheWeekProvider` no es más que un componente común y silvestre.

---

Y _voilá_, eso ha sido todo por hoy. Si te ha gustado el contenido, no te olvides de darle una compartida en Twitter y seguirme por [ahí](https://twitter.com/daslaf).

Gracias totales y hasta la próxima.


La “nueva” API de Context de React (disponible desde la versión 16.3) nos permite encapsular un pedazo de estado en un contexto que es inyectable en cualquier lugar de nuestro árbol de componentes.

Blog

De JavaScripts y humanes

Modelado de dominio para aplicaciones frontend utilizando TypeScript

Control de flujo, expresiones de corto circuito y programación funcional en JavaScript

Arquitectura CLEAN para el frontend

Implementando CLEAN en aplicaciones web con React

Lidiando con reducers e inmutabilidad de forma declarativa

Servicios, servicios, servicios

AOC Día 9 - Encoding Error

Resolviendo el desafío Advent of Code (AOC) en JavaScript

AOC Día 8 - Handheld Halting

Resolviendo el desafío Advent of Code (AOC) en JavaScript

AOC Día 7 - Handy Haversacks

Resolviendo el desafío Advent of Code (AOC) en JavaScript

AOC Día 6 - Custom Customs

Resolviendo el desafío Advent of Code (AOC) en JavaScript

AOC Día 5 - Binary Boarding

Resolviendo el desafío Advent of Code (AOC) en JavaScript

AOC Día 4 - Passport Processing

Resolviendo el desafío Advent of Code (AOC) en JavaScript

AOC Día 3 - Toboggan Trajectory

Resolviendo el desafío Advent of Code (AOC) en JavaScript

AOC Día 2 - Password Philosophy

Resolviendo el desafío Advent of Code (AOC) en JavaScript

AOC Día 1 - Report Repair

Resolviendo el desafío Advent of Code (AOC) en JavaScript

Creando un Store a la redux con RxJS

Técnicas de manejo de estado con RxJS, parte 1

Revealing Module Pattern en 2020

Cómo encapsular servicios con un patrón simple

React y RxJS

Cómo utilizarlos en conjunto y no morir en el intento.

Moviendo ¿casi? todo a daslaf.dev

Adiós Medium, que la fuerza te acompañe

Introducción a Ramda.js - Parte 0

Conceptos generales sobre programación funcional

Manejo de estado con Context y Hooks en React