Tylus melas — kai pamiršti vieną perpiešimą

Dabar — skausmas. Pridedam naują funkciją: „Remove" mygtuką kolekcijoje. Kodo stulpelyje removeFromCollection atrodo teisingai:

function removeFromCollection(date) {
  favorites = favorites.filter(f => f.date !== date);
  renderCollection();   // eilutė dingsta — atrodo padaryta!
  renderHome();         // skaitiklis sumažėja
  // ...bet PAMIRŠOM renderGallery().
}

Rašydamas galvoji apie tai, ką matai — kolekciją, kurioje spaudi „Remove", ir skaitiklį. Perpieši juos — atrodo baigta. Bet ta pati nuotrauka yra ir galerijoje, ir ten jos ♡ liko užpildytas. Programa dabar sako „išsaugota", nors nebeišsaugota.

Atkurk pats:

1. Įdėk nuotrauką į kolekciją (♡ galerijoje užsipildo).
2. Nueik į kolekciją, paspausk „Remove".
3. Grįžk į galeriją → ta pati nuotrauka VIS DAR su pilnu ♡.

Jokios klaidos konsolėje. Jokio įspėjimo. Testai praeina (juk kolekcija atsinaujino). Klaida iškeliauja į produkciją, ir ją randa vartotojas. Tai — tylus melas: DOM rodo viena, duomenys sako kita.

Ir esmė ne ta, kad „buvai neatidus". Esmė struktūrinė: kiekvienas veiksmas privalo žinoti pilną vaizdų, priklausančių nuo jo liečiamų duomenų, aibę — ir nieko nėra, kas tai užtikrintų. Kuo daugiau veiksmų ir vaizdų, tuo daugiau tokių porų „veiksmas × vaizdas", ir vieną nutylėti — tik laiko klausimas.

Vaistas — 9 pamokoje. Vietoj to, kad kiekvienas veiksmas kviestų kiekvieną vaizdą, būsena vieną kartą paskelbia „aš pasikeičiau", ir kiekvienas vaizdas atsinaujina pats. Tai — subscribe/notify (pub/sub). Veiksmas nustos rūpintis vaizdais; jam terūpės duomenys.

Spąstai — pamirštas perpiešimas

Rankinis būsenos valdymas nelūžta iškart — jis lūžta tyliai ir vėliau. „Nepamiršk perpiešti visų priklausomų vaizdų" nėra kodo taisyklė; tai — disciplina. O disciplina masto neatlaiko. Būtent todėl atsirado būsenos valdymo bibliotekos ir karkasai — ne dėl mados, o dėl šito konkretaus skausmo.

main.js MODIFIKUOTI 24 eilutės pakeistos

Redaguok šį failą kataloge js/

// The app's ENTIRE memory — as loose module-level variables. Ten of them now.
// There is no single place that owns state; it's scattered, and every action
// has to remember which views depend on what it just changed.

import { fetchPictures } from './api.js';
import { renderGallery } from './views/gallery.js';
import { debounce } from './utils.js';

const searchInput = document.getElementById('search');   // <input type="search" id="search">

// ---- the app's state, as loose variables (this is piling up...) ----
let pictures = [];
let isLoading = false;
let error = null;
let searchQuery = '';
let favorites = [];            // in-memory for now — persistence arrives in lesson 9
let daysToShow = 14;
let collectionQuery = '';
let sortKey = 'date';
let currentPage = 1;
let pageSize = 10;

// Derived: the pictures that pass the current search
function visiblePictures() {
  if (!searchQuery) return pictures;
  const q = searchQuery.toLowerCase();
  return pictures.filter(p => p.title.toLowerCase().includes(q));
}

function render() {
  renderGallery({ isLoading, error, pictures: visiblePictures() });
}

// Placeholder views — the real collection page arrives in lesson 10 and the
// home counter lives in the nav. The PRINCIPLE (three views depending on one
// piece of data) is what this lesson is about, not their looks.
const favCount = document.getElementById('fav-count');   // <span id="fav-count"> in the nav

function renderCollection() {
  console.log('collection:', favorites.map(f => f.title));
}

function renderHome() {
  favCount.textContent = String(favorites.length);
}

// THREE views read `favorites`:
//   • the gallery   → whether each card's ♡ is filled
//   • the collection → whether a row exists for this picture
//   • the home page  → the "saved" counter
// So when `favorites` changes, ALL THREE must be re-rendered — by hand.
function toggleFavorite(pic) {
  const i = favorites.findIndex(f => f.date === pic.date);
  if (i >= 0) favorites.splice(i, 1);
  else favorites.push({ ...pic, rating: 0, notes: '', tags: [] });

  renderGallery({ isLoading, error, pictures: visiblePictures() });   // the ♡ fill
  renderCollection();                                                 // the row
  renderHome();                                                       // the counter
  // Miss ANY one of these three and that view silently shows stale data.
  // Nothing errors. Nothing warns you. The screen just quietly lies.
}

// A new feature: a "Remove" button in the collection view. Easy to write —
// update favorites, re-render the collection you're looking at, update the
// counter. Ship it.
function removeFromCollection(date) {
  favorites = favorites.filter(f => f.date !== date);

  renderCollection();   // the collection updates — the row disappears. Looks done!
  renderHome();         // the "saved" counter ticks down too.

  // ...but we FORGOT renderGallery().
  //
  // The same picture is still in the gallery, and its ♡ is STILL filled — the
  // app now shows it as saved when it isn't. You won't see this bug unless you
  // (a) remove from the collection, then (b) scroll back to the gallery. It
  // passes every quick test. It ships. A user finds it.
}

// This is the disease: every action must know the FULL set of views that depend
// on the data it touches — and there is nothing to enforce it. The DOM and the
// data drift apart, and only your memory holds them together. Memory fails.
//
// The cure is in lesson 9: instead of each action calling each view, the state
// announces "I changed" ONCE, and every view updates itself. subscribe/notify.

// debounce: only filter once the user STOPS typing for 250ms — not on every key
searchInput.addEventListener('input', debounce((e) => {
  searchQuery = e.target.value.trim();
  render();
}, 250));

async function load() {
  isLoading = true; error = null; render();
  try {
    pictures = await fetchPictures(14);
  } catch (e) {
    error = e.message;
  } finally {
    isLoading = false; render();
  }
}

load();