Digamos que un usuario da el título de una nota como 'onboarding.md'.
Y la URL termina así localhost:4000/ecme/onboarding.md .
Ahora, tras una actualización con esa URL, quiero que mi enrutador del lado del cliente lo maneje: cargue un componente, llame a una API a través de la búsqueda y luego cargue el resultado en el componente.
Pero aparece una página en blanco con un error Cannot GET /ecme/onboarding.md .
No hay tal error si navego programáticamente a la nota.
No puedes, al menos no realmente.
Si el usuario está actualizando la página, el navegador le está pidiendo al servidor esa URL.
Su enrutador del lado del cliente ni siquiera se ha cargado.
Cuando utiliza el enrutamiento del lado del cliente con URL "reales" (a diferencia del enrutamiento hash donde todos los datos de ruta se mantienen en el identificador de fragmento), también debe tener soporte de servidor .
Un buen soporte de enrutador usaría la representación del lado del servidor para que la página se entregue completa desde el servidor en lugar de generarse en el lado del cliente. Esto es eficiente (no es necesario servir una página de arranque y luego hacer que el cliente haga todo el trabajo y realizar solicitudes HTTP adicionales de datos), amigable con los motores de búsqueda y significa que si JS falla por algún motivo , la página seguirá siendo accesible.
Hay marcos para admitir esto para los marcos SPA más comunes (por ejemplo, React tiene Next.js).
El enfoque rápido y sucio si desea evitar SSR es simplemente configurar el servidor para que sirva el documento HTML de arranque que ejecuta el código del lado del cliente para cada URL que se solicita (o al menos aquellos que no están asociados con un archivo). Esto no tiene los beneficios enumerados anteriormente y también termina dando a los clientes (incluidos los motores de búsqueda) un documento HTML incluso cuando deberían recibir un error 404 No encontrado.