DEV Community: Yuriy Stasyuk

Three CSVs In, 1,272 Food Pages Out: PregNut's Boring Static Build

Yuriy Stasyuk — Tue, 27 Oct 2026 17:29:45 +0000

PregNut is a free pregnancy food lookup I've been building since 2018. You search a food and see how 100 grams of it stacks up against the daily amounts pregnancy asks for. It has 1,272 foods and 13 nutrients, and each food gets its own page.

There's no database server behind it. It's an Eleventy site that builds from three CSV files and deploys to Cloudflare Pages. I like boring stacks for side projects, and this one has stayed easy to work on through three pregnancies, so here's how it fits together.

The inputs

The database/ folder has three files: FoodList.csv, NutrientList.csv and daily requirements.csv. The food list has the USDA NDB number, name, food group and a warning field. The nutrient list is long and skinny, one row per food per nutrient with a value and a unit. The requirements file has the daily reference amount for each nutrient as a label like "1000 mg" or "0.3 g."

All of it comes from a fixed snapshot of the USDA's SR Legacy data. USDA's final Standard Reference release was in 2018, so the numbers are frozen. For a reference site I count that as a feature. A value doesn't change under you between builds. The cost is that newer data and current product labels can differ, and the About page says that.

A tiny build script instead of a dependency

scripts/build-fooddata.js reads the CSVs and writes one JSON file the site uses everywhere. I wrote a minimal CSV parser for it, small enough to read in one sitting. It handles quoted fields and doubled quotes, and it strips a byte order mark if there is one. That BOM will quietly rename your first column header if you don't strip it.

The requirements file has a reference list under the main table, so the parser stops when it hits the SourceId row. Reference amounts get parsed with a small regex into a number and a unit.

One choice I'd make again. If the CSVs aren't present but the JSON already exists, the script prints a warning and keeps the existing JSON instead of failing. That lets a deploy work from the committed JSON alone.

One page per food with pagination

Eleventy's pagination does the heavy lifting. The food page template paginates over a data file with size: 1, so every item becomes its own page. The permalink is /food/{{ food.slug }}/, and the slug starts with the USDA number: /food/15151-shrimp-cooked/, /food/15152-shrimp-canned/. Food names repeat a lot in USDA data. The number keeps every URL unique without me thinking about it.

The data file is also where per-page decisions live. Title overrides for pages that get search traffic, related blog posts, and special cases. The human milk record, for example, stays in the dataset but is labeled as a historical data record only and left out of the food listings.

Units needed a helper. DHA is stored in grams and its benchmark is 0.3 g, while other nutrients are in mg or mcg. There's a small conversion function so comparisons always happen in the same unit.

Each page shows two columns: per 100 g, and a serving based on FDA reference amounts. Cooked shrimp shows 3 oz (85 g) next to 100 g. The 100 g column is for comparing foods. The serving column is closer to what's on a plate.

What the data can't do

The dataset has no iodine values. Rather than fake it, the site has an iodine guide and says the data is missing. Folate is shown as DFE, which isn't the same thing as the folic acid number on a prenatal label, so that gets its own guide too.

PregNut is an educational reference and isn't medical advice. Every page says so in the footer.

Deploys and one contact form

A GitHub Actions workflow runs npm run build and deploys with wrangler. Pushes to master go to pregnut.com. Pull requests get a preview deploy, and the link gets posted on the PR. Previews are only built for branches in the repo, and the actions are pinned to commit SHAs. The *.pages.dev hosts send X-Robots-Tag: noindex from _headers, so Google only indexes the real domain.

The one dynamic piece is /api/contact, a Cloudflare Pages Function. I wanted a free email relay and picked FormSubmit, which turned out to refuse requests coming from Workers. So the function does validation, a honeypot, a timing check and rate limiting, and only then hands the browser the relay endpoint to send to. Bots that fail the checks never see it.

If you want to see the output, open any food page on pregnut.com and view source. The numbers and the notes are right there in the HTML.

Things That Bit Me Wrapping the YouTube IFrame API for a Kids' App

Yuriy Stasyuk — Tue, 27 Oct 2026 17:29:04 +0000

I built WiseTube because the YouTube sidebar kept leading my kids somewhere I didn't want them. It's a free library of hand-picked learning videos that play inside my own player, with YouTube's suggestions, Shorts and autoplay-to-the-next-thing taken out.

The covering-up part gets most of the attention. This post is about the smaller stuff that cost me evenings. If you're wrapping the IFrame API for anything, some of these will probably find you too.

1. The API script can hang, so give it a deadline

You load https://www.youtube.com/iframe_api and wait for onYouTubeIframeAPIReady. Most of the time it's fine. On a flaky connection it can sit there forever, and a kid staring at a spinner will go find another app.

I wrap the load in a promise, cache it so it only happens once, and clear the cache if the script errors so the next try starts clean. The player also starts a 15 second timer. If onReady hasn't fired by then, it shows "The film didn't load" with a retry button.

2. YouTube resets your playback speed

I save speed and volume to localStorage so a kid who likes 1.25x doesn't have to set it every time. I set the rate in onReady, and that isn't enough, because YouTube can reset the rate when a film starts playing. The fix is boring. On every PLAYING state change, read getPlaybackRate() and set it again if it doesn't match the saved value.

3. Autoplay for the chosen film still gets blocked sometimes

I want the film a kid picked to start right away, so the player is created with autoplay: 1. Browsers don't always allow it. There's no clean event for "autoplay was blocked," so after onReady I wait about 1.2 seconds and check the state. If it's still UNSTARTED or CUED, I show my own big play button.

That's the only autoplay in the app. When a film ends, nothing else starts on its own.

4. Don't let callbacks restart the player

The Player component takes onTick, onEnded and onError from the page. If those are effect dependencies, any parent re-render can tear down the iframe and build a new one mid-film. I use React's useEffectEvent for them, so the effect that mounts the player only depends on the video id, the retry count and the title.

Progress gets read every 250ms for the scrub bar but only reported up every 5 seconds. Saving progress four times a second felt silly.

5. Validate pasted links before you trust them

Parents can add a film by pasting a YouTube link. People paste everything: youtu.be links, /embed/ links, watch?v= links, Shorts. I parse the URL, accept the normal shapes, and reject anything under /shorts/ or /live/ with "Paste a normal YouTube link. Shorts stay out of WiseTube."

Then I call YouTube's oEmbed endpoint for the link. If it doesn't come back with a title and channel name, the film doesn't get added. That catches typos, private videos and videos that can't be embedded, before a kid ever taps them.

6. A PIN on a device with no server

There are no accounts. Profiles, progress and settings sit in localStorage. The four-digit parent PIN is stored as a SHA-256 hash with a random 16-byte salt, using crypto.subtle.

I'll be straight about what that buys. A four-digit PIN on a device the kid holds is a speed bump. It keeps a six-year-old out of the settings. A teenager with dev tools could get past it. For a free app with no backend, I'm fine with that, and I'd rather say it than pretend it's a vault.

Because everything is on one device, the parent settings have an export button that downloads a wisetube-library.json with profiles, PIN, added and hidden films, and progress. Import shows how many learners are in the file and asks before replacing anything.

7. Vite preview lies about routing

The site is a static build on Cloudflare Pages. Public pages are prerendered for search. Private app routes like /watch/:youtubeId and /parent are rewritten to a noindex app.html through public/_redirects, so a refresh doesn't 404.

vite preview ignores _redirects and Pages' 404 behavior, so a route can look fine locally and behave differently once deployed. I test routing with npx wrangler pages dev dist, which behaves like the real thing.

8. Tests for the catalog, too

The video list is data, and data drifts. npm run check runs TypeScript, oxlint and vitest, and the catalog tests fail if an import sneaks in a Short, a duplicate, an unknown topic, or a channel I already ruled out. That has caught more mistakes than any of my UI tests.

You can try the result at wisetube.yuriystasyuk.com. If you've wrapped the IFrame API and found a cleaner way around any of these, I'd love to hear it.