Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/LuisED18/proyecto-pagina-peliculas/llms.txt

Use this file to discover all available pages before exploring further.

Pelisgo’s TV series feature lives on series.html and is powered by the exact same main.js module that drives the movies page. There is no separate script — instead, main.js inspects the current page URL at runtime and dynamically switches the TMDB endpoint and the result field names between movie and tv mode. This means all logic for fetching, rendering, and searching series is handled inside the shared module with zero code duplication.

​
Page Auto-Detection

When main.js is loaded, it immediately evaluates two constants that determine the content type for the entire session: 
// DETECCIÓN: ¿Estamos en series.html o index.html?
// Esto busca la palabra "series" en la URL de tu navegador
const esPaginaSeries = window.location.pathname.includes('series');
const tipo = esPaginaSeries ? 'tv' : 'movie';
window.location.pathname returns the path segment of the current URL (e.g. /series.html or /index.html). The .includes('series') check sets esPaginaSeries to true when the visitor is on series.html and false on index.html. The tipo constant resolves to either 'tv' or 'movie' and is used in two places throughout main.js:
  1. Endpoint construction — tipo is interpolated directly into the TMDB URL path to target the correct API resource.
  2. Field name resolution — esPaginaSeries is used in ternary expressions to read item.name / item.first_air_date for series, or item.title / item.release_date for movies.
This single boolean is the only branching mechanism in the entire module. When series.html loads, obtenerContenido() is called with no arguments. With tipo set to 'tv', the function builds the following endpoint: 
https://api.themoviedb.org/3/tv/popular?api_key=YOUR_KEY&language=es-ES&page=1
The fetch returns a JSON object whose results array contains up to 20 TV series objects. These are passed directly to mostrarCards() for rendering. 
async function obtenerContenido(query = '') {
    try {
        let endpoint;
        if (query) {
            endpoint = `${BASE_URL}/search/${tipo}?api_key=${API_KEY}&language=es-ES&query=${query}`;
        } else {
            // tipo = 'tv' on series.html
            endpoint = `${BASE_URL}/${tipo}/popular?api_key=${API_KEY}&language=es-ES&page=1`;
        }

        const respuesta = await fetch(endpoint);
        const datos = await respuesta.json();
        
        if (datos.results) {
            mostrarCards(datos.results);
        }
    } catch (error) {
        console.error('Error al obtener los datos:', error);
    }
}

​
TV Series vs Movie Fields

The TMDB API uses different field names for movies and TV series. main.js handles this with two ternary expressions evaluated inside mostrarCards(): 
const titulo = esPaginaSeries ? item.name : item.title;
const fechaOriginal = esPaginaSeries ? item.first_air_date : item.release_date;
The table below compares the fields consumed from each content type:
Fields read from each object in a /movie/popular or /search/movie response:
FieldTypeDescription
item.titlestringThe movie’s title
item.release_datestringISO date string, e.g. "2024-07-19" — year extracted via .split('-')[0]
item.poster_pathstring | nullRelative poster image path
The resolved titulo and año variables are what ultimately get rendered in the card — meaning the card template itself never needs to know which content type it is displaying.

​
Shared Card Rendering

Because mostrarCards() only ever works with the pre-resolved titulo and año local variables, the HTML template it injects is completely identical for both movies and series: 
card.innerHTML = `
    <img src="${poster}" alt="${titulo}">
    <div class="info">
        <h3 class="tituloPeli">${titulo}</h3>
        <span class="fecha">${año}</span>
    </div>
`;
There is no if (esPaginaSeries) check inside mostrarCards(). The type-specific branching is fully resolved before the function is called, keeping the rendering logic clean and reusable. This also means any future change to the card layout (styling, added fields, click handlers) only needs to be made in one place.

Build docs developers (and LLMs) love

Get started for freeTalk to us