Layouts

Usando el selector a: Navegación MPA

Será el enlace de toda la vida y para navegar a una ruta u otra, simplemente debemos de de asignarle el valor de esa ruta en el atríbuto href

<a href={'/about'}>Enlace cargando todo el contenido (estilos globales y todo el documento de nuevo)</a>

Este elemento nos llevará a la ruta about de nuestra aplicación y lo hará cargando TODO EL CONTENIDO DE NUEVO, es decir, cargando el contenido de los estilos globales, cabeceras, etc.

Teniendo como referencia la plantilla que hemos trabajado al principio de este capítulo, cargaría aparte de lo que tenemos en la ruta, cargaría de nuevo todos los componentes individualmente, haciendo que su rendimiento no sea el más adecuado.

En este caso, no nos interesa estar recargando una y otra vez componentes que van a estar siempre a la vista en nuestro proyecto como puede ser una cabecera (<Header />) o un pie de página (<Footer />). También nos interesa que el apartado del menú sea fijo y que se cargue una primera vez.

¿Cómo solucionamos esto para tener una experiencia Single Page Application (SPA)? Usando el componente <Link /> y/o el hook useNavigate().

Navegación tipo SPA

Para realizar la navegación con experiencia tipo SPA, Qwik (como en Anugular por ejemplo) nos ofrece un componente <Link /> y un hook useNavigate().

Podemos usarlo haciendo este import:

import { Link, useNavigate } from '@builder.io/qwik-city';

Estos elementos se pueden utilizar para iniciar una actualización de SPA o navegar entre páginas SIN RECARGAR todo el documento.

El componente <Link /> es la forma recomendada de navegar cuando interactuamos desde un elemento HTML, ya que utiliza la etiqueta HTML <a>, que es la forma más accesible de moverse entre páginas.

Si necesitamos navegar programáticamente, podemos utilizar el hook useNavigate() que mantendrá el mismo comportamiento que <Link /> pero ejecutándose después de un click a un elemento <button>, por poner un ejemplo.

El código de ejemplo para trabajar con estos dos elementos sería el siguiente:

import { component$ } from '@builder.io/qwik';
// 1.- Importamos el componente y el hook para navegación tipo SPA
import { Link, useNavigate } from '@builder.io/qwik-city';
 
export default component$(() => {
  // 2.- Iniciamos el hook
  const nav = useNavigate();

  // 3.- Link y/o nav => Nos llevan a '/about'. 
  // El primero desde un elemento HTML y segundo desde una acción de click a un botón
  return (
    <div>
      <Link href="/about">About (Más recomendable)</Link>
      <button onClick$={() => nav('/about')}>About</button>
    </div>
  );
});

Tanto <Link /> como useNavigate() nos llevarán a la ruta /about de manera interna, solo recargando el contenido de esa ruta y no todo el documento. Esto lo veremos con más detalle cuando trabajemos con los estilos en el siguiente capítulo, viendo su comportamiento ante el uso de <a> ó <Link />.

Esto es lo básico que necesitamos saber, si queréis profundizar en este aspecto sobre el apartado SPA y el uso de <Link /> junto con useNavigate(), os invito que accedáis a la documentación oficial (Siguiendo esta referencia: https://shorten-up.vercel.app/T-WhiunHkj) y exploréis las diferentes opciones con este apartado.

Una vez vistas las formas de navegar en Qwik, con el nuevo elemento <Link /> junto con useNavigate() más al detalle, vamos a empezar a realizar el último paso de la refactorización aplicando el uso de <Link /> para los elementos del menú.

Implementando navegación en componente <Menu/> {#menu-component-navigation}

Ahora mismo, estamos enfocados en el apartado donde añadiremos el contenido correspondiente al componente <Menu />

Hacemos lo mismo con la parte del menú, trasladándolo al componente <Menu>:

Lo añadimos en src/components/core/menu.tsx de esta manera:

import { Link } from "@builder.io/qwik-city";

export const Menu = () => {
  return (
    <div class="column menu-items">
      <h2>Menu</h2>
      <ul>
        <li>
          <Link href={"/"}>Home</Link>
        </li>
        <li>
          <Link href="/about">About</Link>
        </li>
      </ul>
    </div>
  );
};

Y añadimos el componente <Menu /> aislado en el layout, como hemos hecho con <Header />:

Después de realizar todos estos cambios y mejoras en el código, vamos a trabajar con cosas más especificas acorde a los layouts (plantillas).

En este punto es donde queremos buscar una personalización de plantillas enfocándonos en diferentes apartados que podamos encontrar dentro de nuestros proyectos, como podría ser tener una plantilla pública y una privada.

only-header, solo cabecera + contenido

• /blog (only-header)

• /contact (only-header)

Página completa con complete {#complete-layout}

• / (complete)

• /about (complete)

Llegados a este punto, ya sabemos como trabajar con los Grouped Layouts (Plantillas Agrupadas) para poder tener de manera agrupada las rutas que corresponde a un tipo de layout, para poder hacer diferentes variantes de layouts para nuestros objetivos.

Plantilla (layout.tsx)

Haciendo referencia a la plantilla layout.tsx mediante el index.tsx

• /
• /about

Plantilla (layout-only-header.tsx)

Hacemos referencia a la plantilla layout-only-header.tsx mediante el index@only-header.tsx tanto en src/routes/blog como src/routes/contact:

• /blog
• /contact

En este caso harán referencia a la plantilla personalizada nombrada que acabamos de crear mediante @only-header. Si no añadimos nada después del index.tsx de la ruta SIEMPRE seleccionará la plantilla correspondiente a src/routes/layout.tsx, que es la plantilla por defecto.

Imaginaros que si hubiese una plantilla llamada layout-anartz.tsx, para su uso deberíamos de hacer dentro del index de una ruta, la referencia con index@anartz.tsx.

Como hemos hecho antes, añadimos el siguiente contenido en layout-only-header.tsx, prácticamente sería hacer lo mismo pero en este caso con plantillas nombradas en vez de agrupadas:

import { component$, Slot } from "@builder.io/qwik";
import { Header } from "~/components/core/header";

export default component$(() => {
  return (
    <>
      <Header />
      <section class="row">
        <Slot />
      </section>
    </>
  );
});

Y en los ficheros index@only-header.tsx tanto de contact como de blog, debe de añadirse el mismo código que se ha añadido en el apartado anterior.

El resultado que debe de mostrar en las 4 rutas es el mismo que en las rutas agrupadas (Grouped Layouts)., por lo que debéis de hacer las mismas comprobaciones que el apartado anterior.

Anidando un layout hijo dentro de una ruta NO principal

Para acercarnos al uso habitual que se da en los proyectos reales, es deseable anidar diseños entre sí, ya que el contenido de una página se podrá anidar en numerosos diseños envolviéndolos en diferentes niveles para hacer una personalización más ajustada al contenido que deseamos mostrar.

Esto estará determinado por la estructura del directorio en el que en una ruta NO principal (por ejemplo /about), le añadimos para cargar su layout anidado al principal correspondiente, como se puede ver a continuación, con el objetivo de poder hacer más personalizado este apartado respecto a la página inicial:

src/
  ...
  └── routes/
      |── index.tsx         # / 
      ├── layout.tsx        # Layout Padre - Inicial (Por defecto)
      └── about/
          ├── layout.tsx    # Layout hijo. Se anida después del padre
          └── index.tsx     # /about 
                            # Se introduce en Slot del layout.tsx de "about"

En esta estructura que acabamos de ver, tenemos dos diseños que se van a aplicar dentro del componente de página la /about.

Se realizará en este orden:

1. src/routes/layout.tsx

2. src/routes/about/layout.tsx

3. Finalmente se carga el contenido index.tsx de src/routes/about/index.tsx en el Slot del layout.tsx (src/routes/about/layout.tsx) que se cargará todo agrupado en el Slot de src/routes/layout.tsx. Es decir, irá "navegando" de abajo arriba agrupando los layout hasta renderizarlos en base a lo que hemos pedido desde la URL.

En este caso, los diseños se van a anidar entre sí, con la página dentro de cada uno de ellos, siguiendo el orden primero desde el index.tsx correspondiente al recurso pedido.

Después irá introduciéndose en los Slot de los layout.tsx de abajo hacia arriba, hasta llegar al layout.tsx principal, que será el que ya agrupe todo y lo muestre en el navegador.

Esto sería una idea de lo que se vería:

Aplicándolo al código, con nuestros colores, vamos a crear el fichero layout.tsx dentro de src/routes/about con el siguiente contenido:

import { component$, Slot } from '@builder.io/qwik';

export default component$(() => {
  return (
    <div style="border: 4px dotted green; padding: 25px">
      <p>
        <code>src/routes/about/layout.tsx</code>
      </p>
      <Slot />
    </div>
  );
});

Cuyo resultado será el siguiente:

Recordando el orden de carga:

1. Carga index.tsx principal (src/routes/about/index.tsx) en el primer Slot.
2. Este Slot se encontrará a nivel de directorio about (src/routes/about/layout.tsx) y cogiendo todo eso agrupado finalmente en el Slot que se ha añadido en el layout principal (src/routes/layout.tsx)

Anidando dos layout hijos dentro de una ruta NO principal

En este ejemplo lo haremos con dos hijos y lo bueno de esto es que si conseguimos entender bien esto, lo vamos a poder aplicar hasta con n hijos, con los niveles que necesitemos.

Imaginaros que dentro de about, queremos añadir otro nivel para abajo para mostrar unos detalles.

Lo que habría que hacer es adaptar la ruta a otro nivel más para abajo dentro del directorio about quedando de la siguiente forma estructurado:

src/
  ...
  └── routes/
      |── index.tsx               # / 
      ├── layout.tsx              # Layout padre
      └── about/
            ├── layout.tsx        # Layout hijo de routes/layout.tsx se anida a el
            ├── index.tsx         # /about
            └── about-one/        # NUEVO DIRECTORIO
                  ├── layout.tsx  # Layout hijo de about/layout.tsx y de layout.tsx
                  └── index.tsx   # /about/about-one

En esta situación, tenemos 3 rutas disponibles:

• /, donde solo cargaría la plantilla /src/routes/layout.tsx y dentro del Slot de este src/routes/index.tsx (primer ejemplo visto en los nested layouts)

• /about carga lo siguiente: src/routes/layout.tsx => Slot => src/routes/about/layout.tsx => src/routes/about/index.tsx (visto en Anidando un layout hijo en una ruta NO principal)

• /about/about-one: Este caso que lo veremos a continuación, pasa por más layouts, haciendo el siguiente camino: src/routes/layout.tsx => Slot => src/routes/about/layout.tsx => src/routes/about/about-one/layout.tsx => src/routes/about/about-one/index.tsx

Aplicándolo al código debemos de realizar lo siguiente:

• Crear el directorio about-one dentro src/routes/about.

• Crear los ficheros index.tsx y layout.tsx dentro de src/routes/about/about-one

• Añadir el contenido en los ficheros creados.

Y sabiendo esto, definimos el contenido de estos dos nuevos ficheros de la siguientes manera:

• src/routes/about/about-one/layout.tsx

import { component$, Slot } from '@builder.io/qwik';

export default component$(() => {
  return (
    <div style="border: 4px dotted orange; padding: 25px">
      <p>
        <code>src/routes/about/about-one/layout.tsx</code>
      </p>
      <Slot />
    </div>
  );
});

• src/routes/about/about-one/index.tsx

import { component$ } from '@builder.io/qwik';

export default component$(() => {
  return (
    <div style='border: 4px dotted blue; padding: 25px'>
      <p>
        <code>src/routes/about/index.tsx</code>
      </p>
      <h1>Ruta "/about/about-one"</h1>
      Esta es la página 'about/about-one'
    </div>
  );
});

Reiniciamos en la consola el proyecto (en el caso de que sea necesario), para que pueda coger los cambios de la nueva ruta que hemos añadido y vamos a probar ruta a ruta el resultado de cada una de ellas:

• /

• /about

Como se puede observar, al entrar en juego src/routes/about/layout.tsx (2), se ha añadido una nueva plantilla con los bordes amarillos y posteriormente se carga el contenido de src/routes/about/index.tsx (1)

• /about/about-one

Y con esto terminaríamos todo lo relacionado a los Nested layouts (Layout anidados), como he mencionado, podríamos seguir añadiendo más niveles para abajo.

Página 404 predeterminada

En lugar de mostrar una página en blanco, por defecto Qwik City nos va a proporcionar una página genérica 404 para cualquier ruta que no esté disponible por no existir.

Para visualizar esta página no necesitamos hacer ningún ajuste ni configuración adicional en el proyecto.

La página 404 predeterminada se renderiza como una alternativa cuando no se encuentra una página personalizada 404.

La página predeterminada de Qwik City es muy útil, para notificarnos que la ruta seleccionada no es la correcta, ya que no existe.

Aun siendo útil lo ideal es que nosotros proporcionemos una página 404 personalizada para ofrecer una mejor experiencia al usuario, como proporcionar el encabezado y la navegación comunes para que el usuario pueda encontrar la página que busca.

Vamos a forzar que nos muestre una página de error predeterminada 404 al introducir una ruta no existente, que en este caso sería el siguiente caso, introduciendo la ruta /contact (podéis poner cualquier otra ruta no registrada), ruta que no existe, por tener únicamente la inicial (/):

• 1: Nos notifican que la ruta introducida /contact no existe y de ahí el mensaje 404 | /contact/ not found.
• 2: Nos muestra la lista de rutas disponible, en este caso solo tenemos la de raíz, pero imaginaros que tenemos más rutas, nos mostraría todas las disponibles como sugerencia.
• 3: Al darse un código de error 404, en Red, dentro de las herramientas de desarrollador nos muestra el estado del recurso que queríamos cargar, en color rojo, que si hacemos click, nos debe de mostrar algo como esto:

Como se puede observar en la imagen anterior (la primera de este apartado), nos muestra la lista de rutas que SI existen a la vez que nos dice que la que hemos seleccionado, no existe.

Página 404 personalizada

En lugar de mostrar la típica y aburrida respuesta genérica 404, tenemos la posibilidad de mostrar una página 404 personalizada utilizando la misma estructura de diseño que nuestra plantilla principal layout.tsx.

Para crear una página 404 personalizada general, debemos de agregar un archivo 404.tsx en el directorio raíz src/routes.

src/
  ...
  └── routes/
        ├── 404.tsx            # Página 404 personalizada 
        ├── layout.tsx         # Diseño predeterminado
        └── index.tsx          # /

En este punto, la página 404.tsx usará el diseño layout.tsx, ya que es un archivo hermano del diseño en el mismo directorio.

Este fichero actuará como una ruta, como podría ser /, /about o cualquier otra ruta existente. El contenido del fichero 404.tsx solo se mostrará cuando no exista la ruta que estamos introduciendo.

Además, al utilizar el enrutamiento basado en directorios de Qwik City, es posible crear páginas 404 personalizadas en diferentes rutas.

Por ejemplo, si también se agregamos src/routes/account/404.tsx en la estructura, entonces la página 404 personalizada de la cuenta solo se aplicará a las rutas /account/*, mientras que todas las demás páginas 404 utilizarán la página 404.tsx del directorio raíz.

Definida de esta manera, así se reflejaría:

src/
  ...
  └── routes/
        ├── account/
        │   └── 404.tsx        # Página 404 personalizada de account
        │   └── index.tsx      # /account
        ├── 404.tsx            # Página 404 personalizada para todas las rutas
        ├── layout.tsx         # Diseño predeterminado
        └── index.tsx          # /

Sabiendo esto, lo aplicamos a la práctica y realizamos estos cambios

Hay que tener en cuenta que las páginas 404 personalizadas se van a generar estáticamente en tiempo de compilación, lo que va a dar como resultado un archivo estático 404.html, en lugar de renderizar páginas individuales generadas en el servidor.

Esta estrategia va a reducir la carga en nuestro servidor HTTP al evitar el renderizado de páginas 404 en el servidor, y así preservará los recursos.

Vamos a empezar a trabajar con el apartado práctico, basándonos en la estructura sugerida y luego ya veremos como se ve en desarrollo y como se vería en producción.

A continuación os muestro paso a paso como vamos a implementar la configuración de las páginas de error.

Recordad que debemos de subirlo a producción para poder ver su funcionamiento real.

Mientras trabajamos en desarrollo, podremos ver de manera previa como se renderiza estas páginas de error, aunque nos seguirá mostrando la página de error predeterminada, solo que ya aparecerán las páginas 404 que añadamos, sea en la ruta principal o en rutas secundarias como account con su extensión html que podremos visualizarlos a mano.

Los pasos que daremos en el ejemplo basándonos en la estructura que os he mencionado:

• src/routes/404.tsx:

import { component$ } from '@builder.io/qwik';
import { Link } from '@builder.io/qwik-city';

export default component$(() => {
  return <div>Página de error <code>principal</code>. Solo existen las siguientes rutas:
    <ul>
        <li>Principal: <Link href='/'>Ir a inicio</Link></li>
        <li>Account: <Link href='/account'>Ir a account</Link></li>
    </ul>
  </div>
});

• src/routes/index.tsx

Aplicaremos el contenido que se renderizará correctamente para la página principal asociada a la ruta /.

import { component$ } from "@builder.io/qwik";
import { Link, type DocumentHead } from "@builder.io/qwik-city";

export default component$(() => {
  return (
    <>
      <h1>Bienvenido a mi página 👋</h1>
      <p>Página principal</p>
      <h2>Otras páginas de interés</h2>
      <ul>
        <li>
          Account:{" "}
          <Link href="/account" class="my-link">
            Ir al account
          </Link>
        </li>
        <li>
          Account con detalles (error 404):{" "}
          <Link href="/account/details" class="my-link">
            Ir al account con error
          </Link>
        </li>
      </ul>
    </>
  );
});

export const head: DocumentHead = {
  ...
};

Y esta es la apariencia que tendrá:

Vamos a añadirle el siguiente código CSS en el fichero src/global.css para darle un poco de estilo:

body {
  padding: 2rem;
  line-height: inherit;
  border: 2px dotted red;
  margin: 1rem;
  border-radius: 1rem;
}

h1 {
  text-align: center;
  border-bottom: 1px solid green;
}

h2 {
  color: orange;
  margin: 1rem;
}

li {
  list-style: circle;
}

Y ahora se visualizará de la siguiente forma:

• src/routes/account/index.tsx

Aplicaremos el contenido que se renderizará correctamente para la página asociada a la ruta /account.

import { component$ } from "@builder.io/qwik";
import { Link, type DocumentHead } from "@builder.io/qwik-city";

export default component$(() => {
  return (
    <>
      <h1>
        Bienvenido a la página <code>account</code>
      </h1>
      <p>
        Estamos en la página de <code>account</code>
      </p>
      <h2>Otras páginas de interés</h2>
      <ul>
        <li>
          Principal:
          <Link href="/" class="my-link">
            Ir al inicio
          </Link>
          <li>
            Blog (error 404):{" "}
            <Link href="/blog" class="my-link">
              Ir al blog con error (No existe)
            </Link>
          </li>
        </li>
      </ul>
    </>
  );
});

export const head: DocumentHead = {
  ...
};

• src/routes/account/404.tsx:

Tal como hemos hecho anteriormente con el fichero 404.tsx en src/routes asignamos el código correspondiente para que se renderice este contenido siempre y cuando no existan las rutas que ejecutemos dentro del ámbito de account.

import { component$ } from "@builder.io/qwik";
import { Link } from "@builder.io/qwik-city";

export default component$(() => {
  return (
    <div>
      Página de error <code>account</code>. Solo existe la ruta{" "}
      <code>/account</code>
      <ul>
        <li>
          Principal: <Link href="/">Ir a inicio</Link>
        </li>
        <li>
          Account: <Link href="/account">Ir a account</Link>
        </li>
      </ul>
    </div>
  );
});

En estos dos casos se han añadido dos enlaces a rutas QUE NO EXISTEN dentro de los ficheros index.tsx y son las siguientes:

• /blog: En este caso debería de renderizar lo que está en src/routes/404.tsx.
• /account/details: Al intentar acceder aquí, se renderizaría src/routes/account/404.tsx.

En desarrollo no se mostrarán directamente, pero vamos a verlo ahora ejecutando con el proyecto en marcha en desarrollo (yarn start o npm start).

Al iniciar el proyecto, podemos visualizar la página principal de la ruta /:

Tendremos esta información a la vista:

• 1: URL principal / que accede al contenido de la página principal
• 2: Enlace a la página de la ruta /account que SI existe.
• 3: Enlace a la ruta /blog que no existe y nos saltaría un error teniendo que mostrar el contenido de src/routes/404.tsx (recordad, en desarrollo no muestra directamente) por estar dentro de lo que sería el ámbito de raíz y no intentando acceder desde account.

Pulsamos en la opción 2 para ir a /account y veremos lo siguiente:

Donde encontraremos la siguiente información:

• 1: Enlace a la página de la ruta /account que SI existe.
• 2: URL principal / que accede al contenido de la página principal
• 3: Enlace a la ruta /account/details que no existe y nos saltaría un error teniendo que mostrar el contenido de src/routes/account/404.tsx por estar queriendo acceder a un recurso NO existente dentro de account (recordad, en desarrollo no muestra directamente).

Probando las rutas NO existentes

Siguiendo en /account pulsamos en la opción 3 que nos debería de llevar a /account/details, pero como no existe, nos debería de mostrar el contenido de src/routes/account/404.tsx cosa que en desarrollo, nos mostrará de la siguiente forma:

Como se puede observar, se detecta que la ruta NO existe (1) mostrándonos todas las rutas disponibles a las que podemos acceder.

Aquí vemos que las páginas de error 404 se generan con la extensión HTML y si queremos ver sus contenidos, en este caso deberemos de hacer click sobre ellos.

Para el caso de account/details, la página que se mostrará es la correspondiente a /account/404.html (2) y la 404.html (3) sería para cualquier ruta que no este dentro del directorio account.

Y estaremos en la página inicial:

Probamos a acceder a la página /account/details mediante Account con detalles... que nos dará un error al no encontrarse ningún contenido asociado a esa ruta:

Y una vez que accedemos, ahora a diferencia de trabajar en desarrollo ya nos muestra el contenido de la ruta /account/details con lo implementado en src/routes/account/404.tsx:

Lo mismo podríamos hacer para rutas que no se encuentran dentro de /account y como queremos verlo, vamos a /blog que nos mostrará el contenido asociado a src/routes/404.tsx:

Llegados a este punto, ya hemos aprendido a realizar la configuración de nuestras páginas de error 404 personalizadas.

Pasamos al desarrollo de estas con información dinámica.

Página 404 dinámica

Al renderizar una página, lo predeterminado es siempre responder con un código de estado HTTP 200 (https://shorten-up.vercel.app/2ESgj-gxQx), que indica al navegador que todo está bien y la ruta existe.

En este caso, tenemos la posibilidad de manejar el renderizado de la página y establecer manualmente el código de estado de respuesta en algo diferente a 200, como 404 aunque no sería aplicar buenas prácticas.

Ejemplo

Por ejemplo, supongamos que tenemos una página de producto con una URL como http://localhost:5143/product/abc.

La página del producto se manejaría utilizando una ruta basada en directorios src/routes/product/[productId]/index.tsx, donde [productId] es un parámetro dinámico en la URL.

En este ejemplo, productId se podría utilizar como clave para cargar los datos del producto desde la base de datos.

Como en este momento no tenemos disponible acceso a ninguna base de datos (y no es lo importante para probar esta funcionalidad), vamos a mockear una lista de productos, simulando una base de datos.

Tendremos dos casos:

1. Se encuentran los datos del producto, perfecto, se renderizarán correctamente los datos. Se devuelve el código de estado 200.

2. NO se encuentran los datos del producto en la información que disponemos, aún podemos manejar el renderizado de esta página, pero en lugar de ello, responderemos con un código de estado HTTP 404 (status(404)).

Aplicando el ejemplo en la práctica

Vamos a verlo practicando y para ello necesitamos una fuente de datos / base de datos.

En este caso, trabajaremos con unos datos en local, añadiendo un fichero mock en src/data/products.ts con este contenido:

export const products = [
  {
    id: "1",
    name: "Smartphone",
    description: "Teléfono inteligente de última generación con cámara de alta resolución, pantalla táctil y capacidad de conexión a internet.",
    price: 500
  },
  {
    id: "2",
    name: "Laptop",
    description: "Computadora portátil ligera y potente con pantalla de alta definición y capacidad para ejecutar programas y juegos exigentes.",
    price: 1000
  },
  {
    id: "3",
    name: "Headphones",
    description: "Auriculares inalámbricos con cancelación de ruido, sonido envolvente y comodidad ergonómica.",
    price: 200
  },
  {
    id: "4",
    name: "Smart TV",
    description: "Televisor inteligente con resolución Ultra HD, conectividad a Internet y acceso a aplicaciones y servicios de streaming.",
    price: 800
  },
  {
    id: "5",
    name: "Digital Camera",
    description: "Cámara fotográfica digital con alta resolución, zoom óptico y capacidad de grabación de video en alta definición.",
    price: 400
  },
  {
    id: "6",
    name: "Tablet",
    description: "Dispositivo portátil con pantalla táctil de alta resolución, conexión inalámbrica y capacidad para descargar aplicaciones.",
    price: 300
  },
  {
    id: "7",
    name: "Printer",
    description: "Dispositivo de impresión que permite imprimir documentos y fotografías en diferentes formatos y con calidad profesional.",
    price: 150
  }
];

Ahora creamos dentro de src/routes un directorio product y dentro de este último un nuevo directorio llamado [productId] que servirá para añadir dinámicamente el valor id del producto para seleccionar cualquier producto de nuestra tienda o comercio electrónico.

Quedaría de la siguiente forma:

src/
  ...
  └── routes/
      ├── product/
      |     └── [productId]/
      |           └── index.tsx # /product/1234
      ...
      ├── layout.tsx            # Diseño predeterminado
      └── index.tsx             # /

Y a continuación añadimos un nuevo elemento, llamado routeLoader$ que sirve para cargar los datos en el servidor y al inicio de la ejecución de la ruta, con el objetivo que estén disponibles para su uso dentro de los Componentes de Qwik.

Se activan cuando ocurre la navegación de SPA / MPA, por lo que pueden ser invocados por los Componentes de Qwik durante el proceso de renderizado.

Y en este fichero creado en src/routes/product/[productId]/index.tsx, aplicamos el código, donde realizaremos la búsqueda de los datos mockeados en base al id del producto introducido:

import { component$ } from '@builder.io/qwik';
import { routeLoader$ } from '@builder.io/qwik-city';

// Datos mock en un fichero local para simular una base de datos
import { products } from '~/data/product';

export const useProductLoader = routeLoader$(async ({ params, status }) => {
  // Ejemplo de llamada a la base de datos (local) utilizando el parámetro productId que será el valor "id" de nuestros productso introducido desde la ruta
  
  // Como he mencionado, haremos una búsqueda en el mock
  
  // El resultado podría devolverse como null si no se encuentra el producto

  const data = products.find((item) => item.id === params.productId);

  // Verifica si hemos encontrado el producto
  if (!data) {
    // No se encontraron datos del producto
    // Establecer el código de estado en 404 (por defecto 200)
    status(404);
  }

  // Devolver los datos y su código estado 200
  return data;
});

export default component$(() => {
  // Obtener los datos del producto desde el hook creado que funciona como un useSignal
  const product = useProductLoader();
 ...
});

Y con esto, debemos de obtener el resultado y evaluar que resultado sea satisfactorio (status(200)) o no, en el caso de que no encuentre nada devolviendo un status(404), mostrándolo de la siguiente forma:

import { component$ } from '@builder.io/qwik';
import { routeLoader$ } from '@builder.io/qwik-city';
import { products } from '~/data/products';

export const useProductLoader = routeLoader$(async ({ params, status }) => {
  ...
});
export default component$(() => {
  // Obtener los datos del producto desde el hook creado
  const product = useProductLoader();
  
  // Evaluamos si existe ese producto
  if (!product.value) {
    // No se encontraron datos del producto
    // Por lo tanto, renderizamos nuestra propia página personalizada de producto 404
    // y está notificado al navegador que su estado es el 404 que se ha especificado en el routeLoader$
    return <p>Lo sentimos, parece que no tenemos este producto.</p>;
  }

  // Se encontraron los datos del producto (código estado 200), así que los renderizamos
  return (
    <div>
      <h1>{product.value?.name}</h1>
      <p>{product.value?.price}</p>
      <p>{product.value?.description}</p>
    </div>
  );
});

Verificamos las dos situaciones haciendo uso de la siguiente URL teniendo en cuenta el parámetro productId:

http://localhost:5173/product/<productId>/

Prueba satisfactoria

Comenzamos con las pruebas y pasamos el id cuyo valor será 1 que corresponde a un Smartphone.

La ruta será http://localhost:5173/product/1/ ejecutándose en el navegador y el resultado será lo siguiente.

Y como se puede observar, obtenemos la información del producto seleccionado, ya que existe y está disponible para mostrarse.

Si observamos dentro de Red, en las herramientas de desarrollador podemos observar que registra el código de estado 200, notificandonos que ha encontrado el recurso pedido.

Sin resultado, por no existir el producto

En cambio, si añadimos un id que no existe como 1234 siendo la ruta http://localhost:5173/product/1234/ el resultado debería de ser el siguiente:

Y aquí es donde nos muestra el mensaje de disculpa, diciéndonos que no existe ese producto y si observamos de nuevo en Red, podemos observar que registra el error 404, mencionando que no ha encontrado ese recurso.