
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

Donde hablo mayoritariamente sobre JavaScript y frontend.

Twitter

Donde subo videos de JavaScript y frontend.

YouTube

Donde subo código, mayoritariamente (sí, lo adivinaste) JavaScript para el frontend.

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

¡Hola! 👋

Mi nombre es Osman Cea y soy un ingeniero de software y desarrollador frontend establecido en Santiago de Chile.