Los problemas de trabajar con History API y cómo los solucionamos
¿Alguna vez has trabajado con la History API para construir tus aplicaciones? ¿No? ¡Pues deberías intentarlo, es increíble!
¿No me crees? ¿Piensas que es una mierda? Pues probablemente sea porque te has encontrado con alguno de sus muchos problemas:
- En algunos casos, un evento popstate se activa al cargar la página sin una razón aparente. Esto ocurre cuando actualizas una página que anteriormente tenía un estado configurado. La mayoría de las veces no necesitas esto, ya que puedes verificar el window.history.state desde JS al cargar la página si necesitas hacer algo con él. Se siente más natural que un evento popstate solo se active cuando el usuario presiona los botones de retroceso o avance, ¿verdad?
- ¿Por qué incluir el parámetro title en los métodos pushState y replaceState si los navegadores ni siquiera lo están implementando? No es ciencia espacial cambiar el parámetro document.title. ¡Vamos, Mozilla y Google! Microsoft, sabemos que lo intentas con todas tus fuerzas – ¡solo eliminen IE de una vez!
- Google Analytics todavía no se lleva bien con la History API, pero en este caso es comprensible. No todos los eventos pushState o popState están destinados a activar una respuesta de Analytics.
Después de luchar con estos problemas durante un tiempo, he creado una pequeña biblioteca JS que proporciona casi la misma interfaz que el objeto historia nativo, pero llena los vacíos mencionados anteriormente.
Está incluido en nuestro framework de código abierto, Ignite WP. Echa un vistazo a la fuente aquí y documentación aquí.
