Add README explanation and translate tests descriptions

Author: fdodino

README.md

@@ -22,7 +22,7 @@ Acá comenzamos a ver cómo funciona el mecanismo de routing de Svelte, que est
 
 ```
 + src
-  - routes
+  + routes
     - +page.svelte <== acá está el menú principal
     + csr
       - +page.svelte <== está la página apuntada por la url `/csr`
@@ -80,3 +80,194 @@ Más adelante vamos a ver ejemplos donde quizás necesitemos disparar una búsqu
 
 ## Server-side rendering (SSR)
 
+En la carpeta SSR podrás ver que tenemos esta estructura de archivos:
+
+```
++ src
+  + routes
+    + ssr
+      - +page.svelte
+      - +page.server.ts
+      ...
+```
+
+### Página svelte
+
+La página Svelte contiene código que vamos a ejecutar en el cliente (el navegador), pero en este caso necesitamos que el procesamiento de la palabra (para obtener la cantidad de letras) lo haga el servidor. La interacción cliente-servidor en web siempre debe comenzar en el servidor, entonces lo más simple en este caso es agregar un botón de Submit que envía la petición al server:
+
+<img src="./images/input_ssr.png" alt="input client side" height="auto" width="30%">
+
+Y para enviar información al server haremos un pedido POST desde un formulario html:
+
+```html
+  <form method="POST" use:enhance>
+    <input name="palabra" placeholder="Escribí una palabra" data-testid="palabra" required />
+    <button type="submit" data-testid="submit">Contar letras</button>
+  </form>
+```
+
+Algunas cuestiones:
+
+- el input tiene un `name="palabra"`, en el Submit lo que hacemos es armar pares clave-valor en base a estos names
+- el form indica el tipo de método http que vamos a usar, en este caso POST
+- `use:enhance` propio de Svelte intercepta el formulario y hace internamente una llamada al server mediante `fetch`, una función nativa del entorno de los navegadores. Como consecuencia de ese cambio, no vamos a notar la llamada al servidor (lo que produce un típico parpadeo cuando se recarga toda la página)
+
+### Recibiendo la información
+
+Por convención, el archivo `+page.server.ts` se procesa en el servidor:
+
+- recibimos la información de nuestro formulario HTML, básicamente claves/valor donde el valor será siempre un string al viajar por http
+- devolvemos un JSON: la información tiene que ser serializable para poder viajar nuevamente del servidor al cliente por http
+
+```ts
+export const actions: Actions = {
+  default: async ({ request }) => {
+    const formData = await request.formData()
+    const palabra = formData.get('palabra')?.toString() || ''
+    const longitud = palabra.length
+    return { palabra, longitud }
+  }
+}
+```
+
+Lo que hace no es gran cosa pero sirve como ejemplo: obtiene la palabra del formulario y devuelve un JSON con la misma palabra y la longitud correspondiente.
+
+![ssr network](./images/ssr_network.gif)
+
+Esa respuesta es recibida por la página Svelte, en el cliente (navegador) para descomponer la información y mostrar un div con el resultado:
+
+```ts
+<script lang="ts">
+  ...
+  export let form: { palabra?: string; longitud?: number } | null
+</script>
+...
+{#if form?.palabra}
+  <div class="row">
+    <p data-testid="resultado">La palabra "{form.palabra}" tiene {form.longitud} letras.</p>
+  </div>
+{/if}
+```
+
+Cada vez que presionamos el botón estamos yendo al servidor a procesar la palabra:
+
+![ssr several times](./images/ssr_several_times.gif)
+
+## Esquema mixto
+
+Si renombramos nuestro archivo `+page.server.ts` a `+page.ts`, Svelte automáticamente va a trabajar en modo mixto
+
+- la primera vez irá al server a procesar la palabra
+- también descargará localmente el código (se transpilará de ts a js)
+- las sucesivas veces que presionemos el botón Submit se procesará en el cliente
+
+
+
+## Testing
+
+### CSR
+
+El testeo de front es similar a ejemplos anteriores, solo es interesante contar la manera en que probamos que el botón Volver nos lleva al punto raíz de la navegación:
+
+```ts
+  it('should navigate to the home page when link is clicked', async () => {
+    render(Counter)
+    const backLink = screen.getByTestId('back-link') as HTMLAnchorElement
+    await userEvent.click(backLink)
+    expect(window.location.pathname).toBe('/')
+  })
+```
+
+- buscamos nuestro anchor (a href) por testid
+- y chequeamos que al hacer click sobre el elemento eso cambia variable global `window`
+
+### SSR
+
+Como la estrategia SSR es un poco más compleja necesitamos agregar más tests para cubrir todos los casos. Por ejemplo queremos testear que cuando el server nos devuelve una palabra y su longitud, lo sabemos mostrar en el div:
+
+```ts
+  it('should show the word length when a word is passed as props', async () => {
+    render(Counter, {
+      props: {
+        form: {
+          palabra: 'hola',
+          longitud: 4
+        }
+      }
+    })
+    const palabra = await screen.getByTestId('palabra') as HTMLInputElement
+    expect(palabra.value).to.equal('')
+    expect(screen.getByTestId('resultado').textContent).to.equal('La palabra "hola" tiene 4 letras.')
+  })
+```
+
+Pero también tenemos que chequear la información que pasamos al server cuando escribimos una palabra. Esto hace perder bastante la inocencia de los tests (algo que muchas personas podrían marcar como polémica):
+
+```ts
+  it('sends the word by doing a submit', async () => {
+    const mockFetch = vi.fn().mockResolvedValue({
+      ok: true,
+      json: async () => ({
+        type: 'success',
+        data: { palabra: 'hola', longitud: 4 }
+      })
+    })
+
+    globalThis.fetch = mockFetch
+
+    render(Counter, { props: { form: null } })
+
+    const input = screen.getByTestId('palabra')
+    const submit = screen.getByTestId('submit')
+
+    await userEvent.type(input, 'hola')
+    await userEvent.click(submit)
+
+    // Verificar que se llamó fetch
+    expect(mockFetch).toHaveBeenCalled()
+
+    // Verificamos el FormData enviado
+    const fetchCall = mockFetch.mock.calls[0]
+    const requestInit = fetchCall[1] as RequestInit
+    expect(requestInit.body).toBeInstanceOf(URLSearchParams)
+    const params = new URLSearchParams(requestInit.body as string)
+    expect(params.get('palabra')).toBe('hola')
+  })
+```
+
+Por qué el test pierde su naturaleza naif de caja negra? Porque sabemos que internamente no se dispara un submit hacia el server sino un fetch, mockeamos en consecuencia esta función y esperamos que dentro del segundo parámetro en la primera llamada haya una clave 'palabra'.
+
+Por último, también debemos testear por separado el comportamiento del server:
+
+```ts
+  it('should process a word and return its length', async () => {
+    const mockRequest = {
+      formData: async () =>
+        new Map([['palabra', 'svelte']]) as unknown as FormData
+    }
+
+    // Simulamos el objeto RequestEvent mínimamente
+    const event = { request: mockRequest } as unknown as RequestEvent<RouteParams, '/ssr'>
+
+    const result = await actions.default(event)
+    expect(result).toEqual({
+      palabra: 'svelte',
+      longitud: 6
+    })
+  })
+```
+
+Fíjense que no estamos testeando la interacción cliente/servidor: podríamos cambiar en el archivo `+page.server.ts` el nombre del parámetro a `word`:
+
+```ts
+export const actions: Actions = {
+  default: async ({ request }) => {
+    const formData = await request.formData()
+    const palabra = formData.get('word')?.toString() || '' // introducimos un error
+    const longitud = palabra.length
+    return { palabra, longitud }
+  }
+}
+```
+
+cambiar nuestro test unitario y 1. los tests pasarían correctamente, 2. tendríamos una buena cobertura. Sin embargo la aplicación no funcionaría.

images/input_ssr.png

@@ -1,12 +1,9 @@
-import { describe, it, expect, vi, beforeEach } from 'vitest'
+import { describe, it, expect } from 'vitest'
 import { render, screen } from '@testing-library/svelte'
 import Counter from './+page.svelte'
 import userEvent from '@testing-library/user-event'
 
 describe('count letters', () => {
-  beforeEach(() => {
-    vi.clearAllMocks()
-  })
 
   it('should start with empty string and should show no result', () => {
     render(Counter)

images/ssr_network.gif

@@ -37,7 +37,7 @@ describe('count letters', () => {
     expect(window.location.pathname).toBe('/')
   })
 
-  it('envía la palabra correctamente al hacer submit', async () => {
+  it('sends the word by doing a submit', async () => {
     const mockFetch = vi.fn().mockResolvedValue({
       ok: true,
       json: async () => ({

images/ssr_several_times.gif

@@ -1,11 +1,11 @@
 // tests/page.server.test.ts
 import { describe, it, expect } from 'vitest'
-import { actions } from './+page.server'
+import { actions } from './+page'
 import type { RequestEvent } from '@sveltejs/kit'
 import type { RouteParams } from './$types'
 
 describe('actions.default', () => {
-  it('debería devolver palabra y longitud', async () => {
+  it('should process a word and return its length', async () => {
     const mockRequest = {
       formData: async () =>
         new Map([['palabra', 'svelte']]) as unknown as FormData