Camera-Based Barcode Scanning (Frontend)

Food Tracker (FastAPI)

Chapter 4 · Camera-Based Barcode Scanning (Frontend)

This is the one chapter in this entire course with no FastAPI involvement at all — the same is true of every sibling course's own Chapter 4. What's genuinely different here is the frontend it's written against: plain JavaScript, no React, no hooks, no component lifecycle to lean on.

Requesting Camera Access

const stream = await navigator.mediaDevices.getUserMedia({
  video: { facingMode: "environment" },
});

facingMode: "environment" requests the rear camera — the same call every sibling course's own scanning chapter starts with, since decoding a barcode client-side has nothing to do with which framework, or lack of one, sits around it.

Decoding, Written as Plain Functions

The same BarcodeDetector-with-ZXing-fallback logic every sibling course uses, here with no useEffect, no useRef — just a module-level variable holding the active stream, and two exported functions:

// static/scanner.js
let currentStream = null;

async function startScanner(videoEl, onDetected) {
  currentStream = await navigator.mediaDevices.getUserMedia({
    video: { facingMode: "environment" },
  });
  videoEl.srcObject = currentStream;
  await videoEl.play();

  if ("BarcodeDetector" in window) {
    const detector = new BarcodeDetector({ formats: ["ean_13", "upc_a"] });
    const scan = async () => {
      if (!currentStream) return;  // stopScanner() already ran
      const barcodes = await detector.detect(videoEl);
      if (barcodes.length > 0) {
        onDetected(barcodes[0].rawValue);
        return;
      }
      requestAnimationFrame(scan);
    };
    scan();
  } else {
    // fall back to ZXing's BrowserMultiFormatReader here
  }
}

function stopScanner() {
  currentStream?.getTracks().forEach((track) => track.stop());
  currentStream = null;
}

Wiring It Into the App's Views

This app has no client-side router — Chapter 1's static-file setup serves one index.html, and separate "views" are plain <div> sections shown and hidden with a CSS class, toggled by JavaScript:

// static/app.js
function showScanView() {
  hideAllViews();
  document.getElementById("scan-view").classList.remove("hidden");

  const video = document.getElementById("scanner-video");
  startScanner(video, async (barcode) => {
    stopScanner();
    const response = await fetch(`/api/lookup/${barcode}`);
    const data = await response.json();
    showAddItemView(data);
  });
}

document.getElementById("cancel-scan-btn").addEventListener("click", () => {
  stopScanner();
  showHomeView();
});

A real cost of choosing no framework

Every one of this quartet's three React-based siblings gets camera cleanup automatically — a useEffect's own return function runs whenever the component unmounts, with no way to forget it once it's written. Vanilla JS has no equivalent lifecycle concept at all: there's no "unmount" event when a plain <div> gets hidden by a CSS class. stopScanner() has to be called explicitly, by name, at every single place a user could leave the scan view — a successful scan, a cancel button, even a back-button handler if one existed. Miss even one path and the camera silently keeps running, with nothing in the language or the DOM to catch the mistake. This is the honest, direct cost of Chapter 1's own "deliberately minimal, no framework" choice: fewer moving parts, but every lifecycle guarantee React provides for free here becomes the developer's own manual responsibility instead.

Every navigation path needs its own stopScanner() call

The example above calls stopScanner() in two places — once inside onDetected, once in the cancel button's handler — specifically because there are two distinct ways to leave the scan view. Adding a third way to leave later (a global nav menu, say) without also adding a third stopScanner() call would leave the camera running in the background, exactly the same underlying bug the React-based siblings' own cleanup functions exist to prevent automatically.

Desktop testing doesn't tell the whole story

A laptop webcam is a poor stand-in for a real phone camera — no autofocus hunting, none of the resolution constraints a phone actually has. Test on a real phone against an HTTPS URL before trusting that scanning genuinely works.

Where This Course Is Headed

The add-item flow next — combining this chapter's scan result with a manual-entry fallback, a POST endpoint, and Pydantic validation errors surfaced directly to the user.

Hands-On Exercises

Exercise 1

Explain why this course's own cleanup discipline is described as a real cost of choosing no framework, contrasting it directly with how the three React-based sibling courses handle the same cleanup problem.

📄 View solution

Exercise 2

Explain why showScanView's code calls stopScanner() in two separate places, and what would happen if a third way to leave the scan view were added without a matching third call.

📄 View solution

Exercise 3

Explain what the if (!currentStream) return; check inside the scan function actually guards against, and why it's necessary given that requestAnimationFrame keeps calling scan() repeatedly.

📄 View solution

Chapter 4 Quick Reference

Same decoding logic as every sibling course: facingMode: "environment", BarcodeDetector with a ZXing fallback
Written as plain functions: startScanner/stopScanner, a module-level variable instead of a React ref
Real cost of no framework: cleanup is manual and explicit at every navigation path — no automatic useEffect equivalent
Every exit path needs its own stopScanner() call — a successful scan, a cancel button, and any future navigation path added later
The if (!currentStream) return guard: stops a stale scan loop from continuing after stopScanner() already ran
Next chapter: Building the Add-Item Flow