State by Hand — and the Pain

Code

The silent lie — when you forget one re-render

Now — the pain. We add a new feature: a "Remove" button in the collection. In the code column, removeFromCollection looks correct:

function removeFromCollection(date) {
  favorites = favorites.filter(f => f.date !== date);
  renderCollection();   // the row disappears — looks done!
  renderHome();         // the counter ticks down
  // ...but we FORGOT renderGallery().
}

As you write it, you think about what you see — the collection you're clicking "Remove" in, and the counter. You re-render those — looks finished. But the same picture is also in the gallery, and there its ♡ stayed filled. The app now says "saved" when it isn't.

Reproduce it yourself:

1. Save a picture (its ♡ fills in the gallery).
2. Go to the collection, click "Remove".
3. Go back to the gallery → that same picture STILL has a filled ♡.

No error in the console. No warning. Tests pass (the collection did update). The bug ships, and a user finds it. This is the silent lie: the DOM shows one thing, the data says another.

And the point isn't that you were "careless". The point is structural: every action must know the full set of views depending on the data it touches — and nothing enforces it. The more actions and views, the more "action × view" pairs there are, and forgetting one is only a matter of time.

The cure — in lesson 9. Instead of each action calling each view, the state announces "I changed" once, and every view updates itself. That's subscribe/notify (pub/sub). An action stops caring about views; it only cares about data.

Gotcha — the forgotten re-render

Manual state management doesn't break immediately — it breaks silently and later. "Don't forget to re-render every dependent view" isn't a code rule; it's discipline. And discipline doesn't scale. This is exactly why state-management libraries and frameworks exist — not fashion, but this specific pain.

main.js MODIFY 24 lines changed

Edit this file in 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();