DEV Community: Patrick Mbithi

What a Calorie Counter Taught Me About Inputs I Didn't Know I Needed to Learn

Patrick Mbithi — Wed, 10 Jun 2026 19:44:00 +0000

A calorie counter sounds like one of those beginner projects that teaches you basic math and maybe some DOM stuff. Set a budget, log meals, subtract, done. I figured I'd knock it out in an afternoon.

The math part took twenty minutes. The rest of it was humbling.

Regex was the first wall

I'd seen regex before and mostly avoided it. This project forced me to actually write some.

The problem is user input. People type things like +200 or - 150 into calorie fields. Technically valid numbers. But if you pass those strings directly to Number(), you get NaN, which breaks everything quietly. The fix is a cleaning function that strips the noise before parsing:

function cleanInputString(str) {
  const regex = /[+-\s]/g;
  return str.replace(regex, '');
}

Simple enough. But I had to actually understand why the + and - need to be inside the character class [] rather than sitting outside it, and what \s is catching, and why the g flag matters. None of that was hard once I looked it up. I just hadn't looked it up before.

The second regex was stranger. Browsers will accept scientific notation in a type="number" field. Type 1e10 and the input won't complain. Your app will then cheerfully try to add ten billion calories to breakfast. So there's a second check that specifically catches that pattern and rejects it:

function isInvalidInput(str) {
  const regex = /\d+e\d+/i;
  return str.match(regex);
}

I would not have thought to look for that on my own. Good thing the curriculum did.

How functions handle failure

The project uses a global isError flag a boolean that resets to false at the start of every calculation, then flips to true inside getCaloriesFromInputs if bad input is found. The main calculation function checks it after gathering all the values and returns early if something went wrong.

It works fine. But sitting with it made me think about the other ways you could handle this. Return null and check for it upstream. Throw an error and catch it. Return an object with a status field. Each approach shifts where the responsibility sits.

I hadn't thought about that before. This project was the first time I had to actually notice the choice being made, even if I didn't make it myself.

Building the DOM on the fly

The "Add Entry" button injects new form fields into whatever meal category the user has selected. It does that with insertAdjacentHTML:

targetInputContainer.insertAdjacentHTML('beforeend', HTMLString);

The HTML is a template literal with the entry number and category name baked into the id and for attributes. That's what keeps labels connected to their inputs as you keep adding rows. If those attributes don't match, clicking a label does nothing.

Before I saw this pattern I would have assumed you'd need a framework for dynamic forms. Turns out you don't. You just need to understand what insertAdjacentHTML does and why the attributes matter.

The clear function almost felt like a reward

After all of that, the form reset was almost relaxing. Loop through the input containers, set innerHTML to an empty string, clear the budget field, hide the output div. Four things. No edge cases. Done.

function clearForm() {
  const inputContainers = Array.from(document.querySelectorAll('.input-container'));
  for (const container of inputContainers) {
    container.innerHTML = '';
  }
  budgetNumberInput.value = '';
  output.innerText = '';
  output.classList.add('hide');
}

I appreciated that.

What I actually took away

Going in, I thought this was a project about arithmetic and maybe some querySelector practice. What it actually drilled was input handling all the ways user input can be malformed, all the places where "valid" and "correct" are two different things, and how much of your validation logic exists specifically to close the gap between what the browser accepts and what your math can safely process.

That's probably obvious to experienced devs. For me, it was the thing I didn't know I was going to learn.

Learning JavaScript With freeCodeCamp: What the RPG Project Teaches You

Patrick Mbithi — Thu, 04 Jun 2026 16:49:45 +0000

tags: javascript, beginners, webdev, freecodecamp

I've tried to "learn JavaScript" more times than I want to admit. Courses, YouTube videos, the usual. I'd get through loops and think I understood them, then open a blank file and have nothing to show for it.

freeCodeCamp's RPG project is different. Not because it's fun (it is), but because it forces you to actually use the concepts instead of just nodding at them.

What you're building

It's a browser-based RPG. You fight monsters -- a slime, a fanged beast, a dragon -- collect gold, buy weapons, manage health. The whole thing lives in index.html with a JavaScript file doing the heavy lifting. No frameworks. No libraries. Just you and the DOM.

Here's what that looks like when it clicks:

const locations = [
  { name: "town square", "button text": ["Go to store", "Go to cave", "Fight dragon"] },
  { name: "store", "button text": ["Buy 10 health (10 gold)", "Buy weapon (30 gold)", "Go to town square"] },
  // ...
];

That array of objects is the entire game state engine. When you first write it out, it looks like a lot of typing. Then you realize: every button, every screen transition, every monster is just pulling from this one structure. That's when data structures stop being an abstract concept.

The thing nobody tells you about arrays of objects

I spent probably 45 minutes confused about why locations[3].name worked but location.name didn't. Obvious in hindsight. At the time it felt like the floor had dropped out.

What actually made it click was the update function -- one function that takes a location object and rewires the whole UI:

function update(location) {
  monsterStats.style.display = "none";
  button1.innerText = location["button text"][0];
  button2.innerText = location["button text"][1];
  button3.innerText = location["button text"][2];
  button1.onclick = location["button functions"][0];
  button2.onclick = location["button functions"][1];
  button3.onclick = location["button functions"][2];
  text.innerText = location.text;
}

Every time the player clicks something, you're not writing new HTML. You're just swapping the data the function reads. That pattern -- separate your data from your rendering -- is something I now see everywhere.

Where it gets genuinely tricky

The combat system. You need to track player health, monster health, the current weapon, and whether the monster is still alive. And you need to update the DOM after every single action without losing track of any of it.

I got it wrong twice before I understood why global variables exist in small programs like this. Not because they're good practice forever -- they're not -- but because the alternative (passing state through every function) gets complicated fast. This project teaches you why people care about state management. Not as a concept. As a problem you personally ran into.

The Easter egg that teaches you something real

There's a secret number guessing minigame hidden in the RPG. The randomness that powers it uses the same Math.floor(Math.random() * X) pattern as the combat system. The first time I noticed I'd written the same two lines in three different places, I understood what "don't repeat yourself" actually means as a constraint, not just advice.

What I'd tell someone starting this project

Don't read ahead. Seriously. The temptation is to look at the full solution when you get stuck on the buyWeapon function or the monster health math. That's the exact moment where fighting through it pays off. Google the specific thing you don't understand. That's different from looking at the answer.

Also, the dragon fight is hard by design. You're probably not missing something. It's just hard.

I'm still early in my JavaScript journey, but this project changed how I think about learning to code. Writing something that runs -- that has a win condition, a lose condition, and a secret cheat code -- is worth more than any number of practice exercises where you guess what the output will be.

If you're somewhere in the middle of the freeCodeCamp JavaScript curriculum and this project is next: you're going to be fine. It's longer than it looks. It's also better than it looks.

Built with: vanilla JS, freeCodeCamp's JavaScript Algorithms and Data Structures curriculum