Queda una forma de resolver problemas con funciones que todavía no has usado a propósito, y es la más desconcertante de todas: una función que se llama a sí misma. Ya te la has cruzado dos veces —la expresión de función con nombre de 03-02 existía en parte para esto, y el RangeError: Maximum call stack size exceeded de 03-05 apareció por una llamada que nunca paraba—. En esta lección le pondrás método. Y no es un ejercicio académico: Nómada Tareas tiene un problema que los bucles resuelven mal y la recursión resuelve de forma natural, porque Marta quiere que una tarea pueda descomponerse en subtareas, y esas subtareas en otras, sin límite de profundidad.

1. Qué es una función recursiva
2. Caso base y caso recursivo
3. La pila de llamadas de una recursión
4. Calentamiento 1: factorial
5. Calentamiento 2: Fibonacci y su coste oculto
6. El caso real: subtareas anidadas
7. Recorrer el árbol: sumar horas
8. Recorrer el árbol: aplanar, contar y buscar
9. Recursión frente a iteración
10. Recursión de cola y por qué JavaScript no la optimiza
11. Memoización aplicada a Fibonacci
12. Cuándo NO usar recursión
13. Errores Comunes y Consejos
14. Ejercicios
15. Conclusión

Una función recursiva es aquella que, dentro de su cuerpo, se llama a sí misma con un problema más pequeño, hasta llegar a un caso tan simple que puede resolverse directamente.

La idea que hay detrás es una forma de pensar, no un truco de sintaxis:

Para resolver un problema grande, supón que ya sabes resolver el mismo problema un poco más pequeño, y combina ese resultado con lo que te toca hacer aquí.

Esto se llama salto de fe recursivo, y es la parte que más cuesta. Cuando escribes cuentaAtras(n - 1) no tienes que imaginar todas las llamadas encadenadas: solo tienes que confiar en que esa llamada hace bien su trabajo.

Toda función recursiva correcta tiene exactamente dos partes:

Y dos condiciones que hay que verificar siempre:

1. El caso base se alcanza. No basta con que exista: el argumento debe acercarse a él en cada llamada.
2. El problema se reduce de verdad. Llamarse con el mismo argumento, o con uno mayor, es un bucle infinito con más pasos.

Aquí se retoma la pila de Hoisting y el Contexto de Ejecución. Cada llamada recursiva apila un contexto nuevo que no se libera hasta que la llamada interior termina.

Dos observaciones esenciales:

• La fase de "bajada" apila llamadas sin calcular nada definitivo: cada una queda esperando el resultado de la siguiente.
• La fase de "subida" es donde se producen los cálculos, de dentro hacia fuera.

Por eso una recursión de profundidad 50 000 revienta la pila, como comprobaste en el ejercicio final de 03-05: las 50 000 sumas están todas pendientes a la vez.

El factorial de n es el producto de todos los enteros de 1 a n. Su definición matemática ya es recursiva: n! = n × (n-1)!, con 0! = 1.

Traza de factorial(5):

Fíjate en el throw para el caso negativo: es el fallo temprano de Manejo de Errores. Sin él, factorial(-1) bajaría hasta -Infinity apilando contextos y acabaría en RangeError, un error que no explica nada.

La sucesión de Fibonacci empieza 0, 1, 1, 2, 3, 5, 8, 13…, donde cada término es la suma de los dos anteriores.

Elegante y correcta. Y desastrosa en rendimiento, porque cada llamada genera dos, y muchas repiten trabajo ya hecho:

fib(3) se calcula dos veces y fib(2) tres veces, y con n mayor la duplicación explota. El número de llamadas crece exponencialmente:

De 10 a 35, las llamadas pasan de 177 a casi 30 millones. En el apartado 11 lo arreglarás con memoización, y la mejora será espectacular. Guarda el dato de que fibonacci(35) tarda varios segundos: lo compararás.

Hasta ahora Nómada Tareas ha trabajado con una lista plana. Pero Marta ha pedido algo razonable: que una tarea grande pueda descomponerse en subtareas, y que esas subtareas puedan descomponerse a su vez. Así queda la tarea 1 del backlog desglosada:

Esa estructura es un árbol, y en JavaScript se representa con objetos que contienen arrays de objetos:

¿Por qué un bucle no basta aquí? Porque no sabes cuántos niveles hay. Con un for recorres el primer nivel; con dos anidados, el segundo; con tres, el tercero. Pero si mañana Iván añade una sub-sub-subtarea, el código deja de funcionar. La recursión, en cambio, no necesita saberlo: cada nivel se trata exactamente igual que el anterior.

Esta es la señal que delata un problema recursivo: la estructura del dato se contiene a sí misma. Una tarea contiene tareas, una carpeta contiene carpetas, un comentario contiene respuestas que son comentarios.

El primer cálculo que necesita Marta: cuántas horas suma una tarea contando todas sus subtareas, a cualquier profundidad.

Merece la pena analizar por qué funciona:

• El caso base está implícito. Si subtareas es [], el for no da ninguna vuelta y la función devuelve solo tarea.horasEstimadas. No hace falta un if explícito, aunque escribirlo tampoco estaría mal.
• Cada nodo hace lo mismo: aporta sus horas y pide a sus hijos que aporten las suyas.
• El resultado, 12 h, coincide con las horas que la tarea 1 tenía en el backlog plano del Módulo 2 (3 + 2 + 2 + 5 = 12). La descomposición no ha cambiado el total.

Y una variante que filtra: horas abiertas (no terminadas) del subárbol.

Comprobación manual: quedan abiertas «Visitar a dos proveedores» (2 h) y «Pintar y montar» (5 h). Total, 7 h. Las de «Medir y levantar el plano» (3 h) y «Pedir presupuestos» (2 h) están hechas.

Con el mismo esquema se resuelven todas las operaciones sobre el árbol. Cambia solo qué se hace en cada nodo.

Salida:

El parámetro nivel = 0 con valor por defecto (03-03) es un patrón habitual en recursión: quien llama desde fuera lo omite, y la propia función lo va incrementando hacia dentro.

El if (encontrada !== null) return encontrada; es importante: sin él, la función seguiría explorando ramas inútiles después de haber encontrado el resultado. Es el equivalente recursivo del break de break, continue y Bucles Anidados.

Todo lo que se puede hacer con recursión se puede hacer con bucles, y al revés. La pregunta es cuál conviene en cada caso.

Compara las dos versiones de la misma tarea, aplanar el árbol. La recursiva ya la has visto. La iterativa necesita gestionar su propia pila:

Funciona, no puede desbordar la pila del motor y es más rápida. Pero fíjate en lo que ha costado: una pila manual, un bucle inverso poco evidente y un objeto auxiliar para llevar el nivel. Esa es la elección real: claridad frente a control.

Regla práctica para el día a día:

• Estructura anidada de profundidad moderada (árboles de menús, comentarios, subtareas, JSON) → recursión.
• Lista plana, o profundidad potencialmente enorme (miles de niveles, ficheros grandes) → iteración.

Se dice que una recursión es de cola (tail recursion) cuando la llamada recursiva es lo último que hace la función: su resultado se devuelve tal cual, sin operaciones pendientes.

En teoría, una recursión de cola no necesita apilar contextos: como no queda nada por hacer al volver, el motor podría reutilizar el marco actual. Eso se llama tail call optimization (TCO) y convertiría la recursión en un bucle, con memoria constante.

El problema es que, en la práctica, JavaScript no la aplica:

Compruébalo:

Conclusión práctica: escribir recursión de cola en JavaScript no te protege del desbordamiento. Es una buena costumbre estilística y funciona en otros lenguajes, pero aquí, si la profundidad puede ser grande, la solución es un bucle.

Volvemos al Fibonacci exponencial del apartado 5. El problema era recalcular lo mismo una y otra vez, y ya tienes la herramienta para arreglarlo: la memoización con closure de Ámbito y Closures.

La comparación es demoledora:

Se pasa de crecimiento exponencial a crecimiento lineal. El coste es la memoria de la caché, que aquí es despreciable, y la restricción de siempre: memoizar solo funciones puras (03-03). fib(n) siempre da lo mismo para el mismo n, así que es seguro.

Dos avisos sobre el resultado de fibonacciRapido(90): ese número supera Number.MAX_SAFE_INTEGER y por tanto es aproximado. Para enteros grandes hay que usar BigInt, el tipo que conociste en Variables y Tipos de Datos. Y la profundidad sigue siendo lineal: fibonacciRapido(20000) desbordaría la pila aunque la caché funcione.

Hay tres situaciones donde la recursión es la respuesta equivocada:

Y una advertencia de seguridad que importa más de lo que parece: si los datos anidados vienen de fuera (una API, un fichero que sube el usuario), la profundidad la controla quien envía los datos. Un árbol malicioso de 100 000 niveles tumbaría tu función recursiva. En esos casos, o iteras, o pones un límite explícito:

1. Olvidar el caso base. Es el error número uno y siempre produce RangeError: Maximum call stack size exceeded.

2. Caso base inalcanzable. Usa <= en lugar de === cuando el argumento pueda saltárselo (decimales, restas de más de uno).

3. No reducir el problema.

4. Olvidar el return delante de la llamada recursiva.

Es un fallo silencioso: no da error, simplemente nunca encuentra nada.

5. Confundir un for dentro de una recursión con un bucle anidado. El for recorre los hijos de este nodo; la recursión baja de nivel. Son ejes distintos.

6. Memoizar una función impura. Ya lo sabes desde 03-04: la caché devolvería resultados obsoletos.

7. Confiar en la recursión de cola. No está optimizada en la mayoría de motores.

8. Consejo: dibuja el árbol de llamadas para tres o cuatro niveles. Casi todos los errores de recursión se ven a simple vista en el dibujo y son invisibles leyendo el código.

9. Consejo: pon un console.log con sangría al depurar.

Ver la bajada y la subida indentadas hace comprensible cualquier recursión. En Depuración de JavaScript verás cómo hacer lo mismo con puntos de interrupción y la pila en vivo.

Sobre tareaRediseno, escribe tres funciones recursivas:

• contarPorEstado(tarea, estado): cuántas tareas del subárbol están en ese estado.
• titulosDeResponsable(tarea, nombre): array con los títulos de las tareas asignadas a esa persona, a cualquier profundidad.
• estaCompleta(tarea): true si la tarea y todas sus subtareas están en estado 'hecha'.

Escribe rutaHasta(tarea, id) que devuelva un array con los títulos que van desde la raíz hasta la tarea con ese identificador, o null si no existe. Por ejemplo, para el id 121 debe devolver ['Rediseñar la sala polivalente', 'Elegir el mobiliario', 'Pedir presupuestos'].

La función profundidadMaxima del apartado 8.2 es recursiva. Reescríbela de forma iterativa usando una pila explícita, comprueba que da el mismo resultado (3) y explica en qué caso concreto preferirías cada versión.

Ejercicio 1

Comentario: las tres siguen el mismo esquema —hacer algo con este nodo, después con cada hijo— y solo cambia la operación. estaCompleta incorpora además la salida temprana: en cuanto encuentra una subtarea incompleta deja de mirar el resto, igual que miEvery en Funciones de Orden Superior.

Ejercicio 2

Comentario: la clave es la línea return [tarea.titulo, ...rutaHija];. El ... es el operador spread, que despliega los elementos de rutaHija dentro del array nuevo; lo estudiarás formalmente en Desestructuración de Objetos, Spread y Rest. Sin él, tendrías que construir el array con un bucle. Fíjate también en que la ruta se monta en la subida: cada nivel añade su título por delante de lo que le devuelve el nivel inferior.

Ejercicio 3

Cuándo preferir cada una:

Observa además una diferencia sutil: la recursiva calcula la profundidad en la subida (1 + máximo de los hijos), mientras que la iterativa la lleva en la bajada, guardando el nivel junto a cada nodo pendiente. Es el mismo cálculo visto del revés.

Con esta lección cierras el Módulo 3. Ya sabes que una función recursiva se llama a sí misma con un problema más pequeño, que necesita siempre un caso base alcanzable y un caso recursivo que reduzca de verdad el problema, y que cada llamada apila un contexto que solo se libera en la subida: por eso una recursión profunda produce el RangeError que conociste en 03-05. Has practicado con factorial y fibonacci, y has visto de primera mano cómo el Fibonacci ingenuo pasa de 177 llamadas con n = 10 a casi treinta millones con n = 35, y cómo la memoización con closure de 03-04 lo devuelve a treinta y cuatro cálculos.

Sobre todo, has visto por qué la recursión existe. Cuando Marta pidió descomponer una tarea en subtareas, y esas en otras, los bucles dejaron de servir: no se puede escribir un for anidado para una profundidad que no conoces. sumarHorasTotales, aplanarTareas, contarTareas, profundidadMaxima, buscarPorId y rutaHasta resuelven ese árbol con el mismo esquema de seis líneas, porque la estructura del código imita la estructura del dato. Y conoces sus límites: la tabla de recursión frente a iteración, la recursión de cola que JavaScript no optimiza, el límite de profundidad para datos que vienen de fuera y las tres situaciones en las que un bucle es sencillamente la respuesta correcta.

Mira lo que has ganado en estas siete lecciones. Empezaste con bloques de código copiados cuatro veces y terminas con pesoDePrioridad(), estaVencida(), describirTarea(), crearTarea(), resumirCarga(), crearGeneradorDeIds(), crearAlmacenDeTareas(), un motor de informes configurable y un recorrido recursivo de subtareas. Sabes definir y llamar funciones, escribirlas como valores y como flechas, diseñar sus parámetros y sus retornos, controlar dónde vive cada variable, encerrar estado en un closure, entender qué prepara el motor antes de ejecutar, pasar funciones a otras funciones y hacer que una función se llame a sí misma. Eso es, con diferencia, el salto más grande del curso hasta ahora.

Pero fíjate en el precio que has ido pagando sin quejarte. Todo este módulo ha trabajado con variables sueltas y arrays paralelos: titulos[i], responsables[i], prioridades[i], estados[i], horas[i], fechasLimite[i]. Has tenido que filtrar índices en vez de tareas, pasar ocho argumentos a describirTarea, arrastrar seis arrays a cada función y confiar en que ninguno se desalinee. Y en cuanto ha aparecido una estructura de verdad —el árbol de subtareas— no ha habido más remedio que usar objetos anidados, avisando de que eso venía después. Ese "después" es ahora. En el Módulo 4: Objetos y Arrays dejarás de simular el modelo de datos y lo escribirás de verdad: cada tarea será un objeto con sus nueve campos, el backlog será un array de objetos, y todas las funciones de este módulo se reescribirán con firmas limpias como describirTarea(tarea, hoy). Empieza con Introducción a los Objetos, y el primer alivio llegará en la primera página.