Conectar una API de geocodificación con la lógica de tu aplicación puede parecer sencillo, pero los pequeños errores de implementación suelen romper todo el flujo. Aquí se muestra cómo detectar y corregir esos problemas paso a paso, desde una función que nunca se invoca hasta una propiedad mal nombrada que impide el cálculo de distancias y tiempos.
¿Por qué la función getDistances no se ejecutaba?
El primer síntoma fue claro: al agregar waypoints en el navegador, los resultados aparecían de forma inmediata en la consola, sin mostrar ni distancia ni tiempo [01:00]. Eso indicaba que el cálculo real nunca se estaba ejecutando.
La pista estaba en el editor de código. La función getDistances aparecía en gris, lo que significa que estaba definida pero no se utilizaba en ningún lugar [01:14]. La corrección fue directa: dentro del método addWaypoint, se agregó la llamada this.getDistances() para que cada vez que se añade un punto intermedio se dispare el cálculo correspondiente [01:27].
¿Qué errores de nomenclatura aparecieron al probar?
Al hacer refresh y agregar un par de waypoints, surgió un invalid value error relacionado con la propiedad waypoints [01:46]. El problema era una diferencia de mayúsculas: la librería de Geocoding de Google espera la propiedad en minúsculas (waypoints), pero en el código estaba escrita con la P mayúscula [02:00]. Este tipo de error es común al trabajar con APIs externas, ya que los nombres de los parámetros los define el proveedor y no pueden modificarse.
Una segunda variable también aparecía en gris. Se había creado theseWaypoints para almacenar los puntos intermedios —excluyendo el inicio y el fin— pero a la hora de usarla se escribió this.waypoints en lugar de theseWaypoints [02:25]. Corregir esa referencia fue fundamental para que el arreglo correcto llegara a la API.
¿Cómo se verificó que las distancias fueran correctas?
Tras las correcciones, se creó una rodada de prueba con la ruta Ciudad Victoria → Tampico → Ciudad de México [02:50]. Esta vez la consola tardó un poco más en responder, señal de que la llamada a la API se estaba ejecutando de verdad.
Los resultados confirmaron el funcionamiento:
- Ciudad Victoria a Tampico: 237 km, 3 horas 9 minutos [03:07].
- Tampico a Ciudad de México: 456 km, 5 horas 54 minutos [03:17].
Cada tramo incluyó además las coordenadas de start location y end location con latitud y longitud, datos esenciales para representar la ruta en un mapa.
¿Qué pasó con la validación del título en el backend?
Al intentar guardar la rodada con el título "CDMX", el servidor respondió con un error invalid new record [03:42]. La causa fue una validación de minLength en el modelo Ride del backend, que exigía al menos cinco caracteres y "CDMX" solo tiene cuatro [03:55].
Se presentaron dos enfoques posibles:
- Reducir el mínimo de caracteres permitidos.
- Ajustar el título para cumplir la regla existente.
En esta ocasión se optó por bajar el minLength a tres, considerando que destinos como CDMX son frecuentes [04:22]. Después de reiniciar el servidor, la rodada se guardó exitosamente con distancias, tiempos y waypoints completos [04:42].
¿Qué buenas prácticas se pueden extraer de esta depuración?
El proceso de debugging mostrado deja lecciones concretas:
- Revisar indicadores del editor: una función o variable en gris es una señal inmediata de que algo no se está usando.
- Respetar la nomenclatura de APIs externas: la diferencia entre mayúsculas y minúsculas puede provocar errores silenciosos.
- Validar datos en ambos extremos: las reglas del modelo en el backend deben ser coherentes con lo que el frontend permite enviar.
- Probar con datos reales: usar rutas conocidas ayuda a verificar que las distancias y tiempos tengan sentido.
El siguiente paso será integrar información del clima desde otra API externa y mejorar la presentación de cada rodada. Si has enfrentado errores similares al conectar servicios externos, comparte tu experiencia en los comentarios.
