Cómo manejar correctamente los cambios de URL slug en Next.js

Hola a todos. Soy Andrey, evangelista de desarrolladores en Content by Kentico. Y hoy, quiero contarles cómo manejar correctamente los cambios en URL Slack en Next.js.

Ahora, primero que nada, ¿por qué deberíamos preocuparnos por los URL slags? Cada elemento de contenido que se almacena en el headless CMS y que realmente estás almacenando o mostrando como una página en tu implementación de sitio contiene un URL slag. Ahora, el problema es cuando el editor entra en ese elemento de contenido, cambia el URL slag, y tu implementación de sitio simplemente toma el cambio, reconstruye la página, y la antigua página, el antiguo URL slag simplemente deja de existir. El problema es que si esa página solía tener un buen ranking de página en los motores de búsqueda, o usaste esa página en tus campañas de marketing, todos esos visitantes que están usando esa URL ahora obtendrán errores 404. Y en estos días realmente no podemos permitirnos visitantes confundidos, ¿verdad?

Entonces, lo que necesitamos hacer es, primero, necesitamos saber para cada página, cada elemento de contenido, necesitamos conocer el historial de URL slag. Ves aquí, el ejemplo es que la página actual tiene un URL slug, hello-typescript-congress, pero en el pasado solía tener un URL slug, typescript-congress y hello-conference, necesitamos conocer el historial para poder emitir las redirecciones correctamente. Lo siguiente es para Next.js, ahora vamos a estar usando Next.js y contenido en este ejemplo, pero si estás usando un framework diferente, puedes aplicar los mismos principios allí. Aquí solo estamos hablando de Next.js, por lo que tenemos dos métodos. Tenemos getstaticpaths y getstaticprops. En getstaticpaths, necesitamos proporcionar todos los URL slugs donde hay una página para nosotros para generar. En ese caso, necesitamos proporcionar los tres URL slugs. Así que, esos son los históricos y los actuales también. Y el último paso, el tercer paso es agregar una redirección adecuada en getstaticprops. Allí necesitamos averiguar en base al slug, si este es un slug actual, como el hello-typescript-congress, que es la página objetivo, o si el slug que estamos usando es uno histórico, y deberíamos redirigir al visitante a una página actual. En este caso, serían el typescript-congress, hello-conferences, que emitirán redirecciones. Entonces, ¿cómo podemos hacer esto en Next.js? Echemos un vistazo. Comencemos en el contenido primero. En el lado del contenido de las cosas, preparé un tipo de contenido llamado conferencia. Y cuando miras el elemento de contenido, ya está usando ese tipo de contenido. Ves en el contenido que tenemos un elemento personalizado especial urlslug-history que puedes usar en tu proyecto. Está disponible de código abierto, por lo que simplemente podemos implementarlo en Netlify o Vercel y usarlo tal como lo estoy usando aquí. Realmente rastrea todos los cambios que haces a un urlslug. Así que ves aquí, ahora el urlslug es typescript-congress-2022. Si lo cambio a typescript-congress, automáticamente registra el cambio. Y cuando publico la página, va a almacenar el cambio dentro del elemento de contenido. Así que ves que esto está en el historial. Ahora, podemos hacer esto tantas veces como queramos. Simplemente vamos a obtener una lista de cadenas de la API, pero este es el primer paso.

Necesitas conocer todos los urlslugs, los históricos y los actuales. Ahora echemos un vistazo a la implementación. En Next.js, tengo una página simple, slug-tsx. Ahora, todo esto se basa en un boilerplate de contenido de Next.js, por lo que no hay mucha funcionalidad. Pero aquí ves que hay dos métodos, getStaticPaths, getStaticProps. Y como mencioné en la presentación al principio, necesitas proporcionar todas las rutas a getStaticPaths o como resultado, a Next.js.

En getStaticProps, necesitas emitir la redirección si es una página que debe ser redirigida. Así que aquí solo necesitamos hacer un cambio simple y agregar al parámetro de elementos el historial también. Así que antes, solo estábamos usando el URL slug, pero ahora queremos usar el historial de URL slug también para obtener realmente todas las rutas. Y ahora necesitamos obtener todas las rutas en una lista simple.

Ahora, si solo obtenemos las rutas en getStaticProps, tendríamos que hacer una verificación adicional de la API con la API de contenido para ver si el slug es uno histórico o un actual. Así que lo que voy a hacer es que voy a crear una lista de todos los slugs y todos los slugs actuales a los que deben redirigir. Ahora, voy a hacer la implementación aquí, voy a avanzar rápidamente y luego voy a explicar el code en un segundo.

Bien, lo que implementé aquí es que estamos obteniendo todas las rutas del CMS de contenido, y en realidad estamos proporcionando todas esas rutas de vuelta como una estructura IPagePath, que puedes ver que contiene solo dos propiedades path y redirectsTo. Path es el URL slug, el actual, y redirectsTo es, en caso de que estemos trabajando con la ruta histórica, aquí vamos a mantener la ruta actual de cualquier página. Así que ves que para el elemento actual que viene del contenido, estamos proporcionando una ruta que es la ruta actual del elemento, la de la versión publicada de la página. Y luego estamos creando una estructura de las rutas históricas, slugs históricos, y redirigen todos a la ruta de la página actual.

Ahora el problema es, realmente no podemos tomar toda la estructura y proporcionarla a Next.js para que la obtengamos en getStaticProps. La razón es, Next.js solo nos permitirá transferir el slug, porque está en el nombre del archivo, es la variable en el camino a la página. Así que no vamos a poder transferir esto a getStaticProps y evitar los problemas de performance. Así que lo que vamos a hacer es, vamos a hacer un truco sugerido por Versal, donde simplemente vamos a tomar todas las rutas, las vamos a serializar en un archivo físico, y luego vamos a tomar ese archivo de vuelta en getStaticProps. Voy a hacer de nuevo la implementación y avanzar rápidamente.

Ahora ves aquí que estoy almacenando todas las rutas en la caché. Lo último que necesito hacer aquí es proporcionar todos los slugs, este es el segundo punto de la presentación. Necesitamos obtener todas las rutas, históricas y actuales, y devolverlas a Next.js aquí. Porque solo estamos diciendo a Next.js, en esta ruta, no hay un 404, hay una página aquí. Y ahora necesitamos hacer el tercer paso, y eso es emitir una redirección adecuada si descubrimos que deberíamos. Así que, en este caso, simplemente estamos tomando la ruta de la caché y si hay una página que debería ser redirigida, tendrá el campo redirects.to. Porque estos son todos los URL slugs históricos, y necesitamos redirigirlos a esta ruta. Así que, podemos hacer una condición simple aquí, si existe path.redirects.to.

En ese caso, queremos hacer la redirección. Así que vamos a devolver un objeto de redirección, y el objeto de redirección solo necesita contener un destino y un permanente. Así que, permanente, si quieres hacer una redirección 307 o 308, basado en eso, establece el campo permanente. Quiero que permanente sea verdadero. Y en el destino, solo recuerda si estás en la subcarpeta o si estás en la raíz, este va a ser el destino desde la raíz de tu sitio. Así que en mi caso es solo una barra y el camino al que redirige. Así que guardemos esto.

Todavía hay un problema aquí bajo get static paths. Correcto. Lo olvidé. Sí, hay path dot path, porque aquí estamos obteniendo solo el objeto, así que queremos el slack ahí. Ahora, esto está bien. Así que intentemos ejecutar el sitio. Y volvamos al navegador y actualicemos esta página. Ahora, el URL slack actual es TypeScript Congress. Así que en esa página en el URL slack deberíamos tener la página de TypeScript Congress. Así que ves que esto está funcionando. Y el slack anterior era TypeScript Congress 2022. Así que si añadimos aquí 2022 deberíamos ser redirigidos a TypeScript Congress. Así que funciona como se esperaba.

Ahora, la implementación no es ideal para ser honesto, pero funciona de esta manera y nos permite poner todo en orden. Y no, eso es lo más importante, no requiere que los editores hagan ningún paso extra. Simplemente funciona. Y eso es todo por mi parte. Si quieres obtener más información sobre esta solución o quieres compartir tu experiencia manejando URL slacks, entonces definitivamente ponte en contacto conmigo. Puedes encontrarme en Twitter. Y espero que disfrutes el resto de la masterclass.