DEV Community: Tara Timmerman

Your Code Isn't Reba: Decoupling State from Storage

Tara Timmerman — Fri, 20 Jun 2025 20:13:31 +0000

Robust, maintainable code starts with one rule: don’t tie your core logic to how its data is stored.

A common mistake is locking a central class to a specific storage method. What starts as a quick localStorage.getItem() quickly turns into a mess when you want to test, refactor, or adopt a new storage mechanism.

The Problem: A `Model` Doing Too Much

At first, my Model was doing it all. Managing state and worrying about persistence.

It was like Reba, a single mom, juggling too many roles at once. Too much for one class!

Example of tight coupling:

export class Model {
  private state: GameState = { /* ... default state ... */ };
  constructor() {
    // Directly reading from localStorage
    this.state.scores.player = parseInt(localStorage.getItem('playerScore') || '0', 10);
    // ... many more localStorage.getItem calls
  }

Why This Was a Problem

👎 Tests weren’t isolated (every test depends on localStorage).
⚡️ Low flexibility (switching to IndexedDB or an API means rewriting the Model).
❌ Single Responsibility violated (business logic + storage concerns combined).

The Solution: Helping `Model` Get a Break

Break the coupling by introducing an interface:

export interface IGameStorage {
  getScore(participant: Participant): number;
  setScore(participant: Participant, value: number): void;
  removeScore(participant: Participant): void;

  getRoundNumber(): number;
  setRoundNumber(value: number): void;
  removeRoundNumber(): void;

  // …other getters/setters as needed
}

Then implement it:

export class LocalStorageGameStorage implements IGameStorage {
  getScore(participant: Participant): number {
    return parseInt(localStorage.getItem(`${participant}Score`) || '0', 10);
  }
  // …
}

The Refactor: Small, Test‑Driven Changes

With a test suite in place, the refactor became a series of manageable steps:

✅ Confirm all existing tests were green.
✅ Replace one localStorage.getItem() call with gameStorage.getScore().
✅ Run the test suite. Failures point to the next area that needs adjustment.
✅ Refine test setup by mocking IGameStorage where needed.
✅ Repeat until every piece of state was abstracted.

Each test acted like a roadmap, making the refactor predictable and manageable.

The Refactored Model: Storage Abstraction in Action

export class Model {
  constructor(gameStorage: IGameStorage = new LocalStorageGameStorage()) {
    this.gameStorage = gameStorage;

    this.state.scores.player = this.gameStorage.getScore(PARTICIPANTS.PLAYER);
    this.state.scores.computer = this.gameStorage.getScore(PARTICIPANTS.COMPUTER);
  // ... no more direct persistence calls; Model is now truly persistence-agnostic
}

Result: The Model no longer knows (or cares) where its data comes from. All storage details are abstracted, making it easy to evolve and test.

What This Shows

✅ Abstraction makes code more flexible and testable.
✅ Tests turn refactoring into a safe, incremental process.
✅ Small changes reduce risk and save time in the long run.

The takeaway: Decoupling doesn’t have to be hard. Sometimes it’s as simple as extracting a few direct localStorage calls and introducing an interface. The payoff (clarity, testability, maintainability) is worth it.

Remember: Much like Reba, who eventually finds help and balance, your code can too! 🫡

🔥 From O(n) to O(1): Smarter Game State for Smarter Code

Tara Timmerman — Wed, 28 May 2025 20:46:46 +0000

What started as a simple feature in a Rock-Paper-Scissors game (tracking the most common move) quickly revealed a classic performance pitfall.

Here's how I refactored an inefficient O(n) approach into a snappy O(1) solution.

🐢 The Slow Way: Recalculate from history every time

My state looked like this:

history: {
  player: ['rock', 'paper', 'rock', ...],
  computer: ['scissors', 'rock', ...]
}

To get the most common move, I was doing this:

function determineMostCommonMove(moves: StandardMove[]): StandardMove | null {
  if (moves.length === 0) return null;

  const counts: Record<StandardMove, number> = { rock: 0, paper: 0, scissors: 0 };

  for (const move of moves) {
    counts[move]++;
  }

  return Object.entries(counts).reduce((a, b) => (b[1] > a[1] ? b : a))[0] as StandardMove;
}

Totally functional. Totally unnecessary. Every time I needed the most common move, I was reprocessing the entire move history.

That’s O(n) time complexity, where n is the number of moves played. For short games, no big deal. But if players go hundreds or thousands of rounds, the cost adds up fast.

To visualize the difference this makes:
📈 Performance Growth (Time)
^
| O(n) 🐌
| /
| /
| /
| /
| /
| /
|====================== O(1) ⚡️
+----------------------------------> Input Size (n)

⚡ The Fix: Track move counts as I go

Instead of recalculating, the core idea was to cache the counts as moves were made.

I added a new moveCounts object to my state:

moveCounts: {
  player: { rock: 0, paper: 0, scissors: 0 },
  computer: { rock: 0, paper: 0, scissors: 0 }
}

Now, every time a move is played, I just increment the relevant count:

private incrementMoveCount(key: Participant, move: StandardMove): void {
  this.state.moveCounts[key][move] += 1;
}

And do a quick pass over the counts to get the most common move:

private determineMostCommonMove(moveCounts: MoveCount): StandardMove | null {
  let mostCommonMove: StandardMove | null = null;
  let highestCount = 0;
  let hasMoveFrequencyTie = false;

  // Iterate over the fixed number of possible moves (rock, paper, scissors)
  // not the entire, ever-growing, game history.
  for (const [move, count] of Object.entries(moveCounts)) {
    if (count > highestCount) {
      highestCount = count;
      mostCommonMove = move as StandardMove;
      hasMoveFrequencyTie = false;
    } else if (count === highestCount && count !== 0) {
      hasMoveFrequencyTie = true;
    }
  }

  // In case of a tie in move frequency (e.g., rock: 5, paper: 5),
  // return null as there's no single "most" common move.
  return hasMoveFrequencyTie ? null : mostCommonMove;
}

This change also addresses a later-found bug related to handling ties in move frequency (where multiple moves occurred an equal number of times).

Now, the determineMostCommonMove function iterates only over the fixed number of possible moves (rock, paper, scissors), which is always 3. While technically O(k) where k is the number of possible moves, since k is a tiny constant and does not grow with the game history, this operation is effectively constant time, O(1)!

This means its execution time is entirely independent of how long a game may go.

✅ Before & After

Before:

Most common move was recalculated every time from the full history. O(n). Clunky.

After:

Counts are updated in real time and checked instantly. O(1). More efficient, more scalable, and simpler to reason about.

Architecture: Your future self will thank you

Tara Timmerman — Mon, 26 May 2025 01:21:57 +0000

Hey, we've all been there. You're hyped to build something awesome, and "architecture" feels like homework you can skip. But imagine building something you genuinely love, then watching it become a tangled mess because you didn't quite know how to keep it organized. Or, worse, someone else tries to help, and it's pure chaos.

Good news: it doesn't have to be that way. Learning a little bit about how to structure your code can save you a ton of headaches (and future tears).

What Is Architecture?

It's just structure. Think of it like organizing your playlists, but for your code, it's about how all those files and pieces work together. It's a way to keep your code from turning into a spaghetti monster 3 weeks from now.

Done right, it makes your code easier to:

Maintain, because no project is ever really “done”
Expand, because of course you’re going to add that feature
Understand, because future-you deserves mercy

Meet MVC

One of the most well-established patterns out there is MVC: Model–View–Controller. It’s been around forever, and for good reason... it works.

Why learn MVC (or any architecture pattern) before a frontend framework?

React, Angular, Vue, they all enforce some kind of architecture for you. But if you don’t already understand why that structure matters, or how to do it from scratch, you’re going to hit a ceiling fast.

If you can pull off a tiny app in vanilla JS using MVC, you’ll be 10× more confident later. You'll also stop mistaking “framework magic” for “your own genius.” Ask me how I know.

The Five Moving Parts

Regardless of the pattern, you’ll generally have five moving parts:

Presentation Logic (UI Layer): Displays stuff on screen. Nothing more, nothing less.
Application Logic (Router): Responds to navigation and UI events. Maps user actions to app behavior.
Business Logic: Solves actual business problems like matching you with the perfect TikTok sound, calculating XP for your game, or splitting your Venmo bill.
State: Keeps track of your app’s data. Ideally without losing its mind when the user clicks around too much.
HTTP Library: Handles sending/receiving data (optional, but in real-world apps, almost always necessary).

Mapping It to MVC

MVC Layer	What It Does	Includes
Model	The brain	Business Logic, State
View	The face	Presentation Logic
Controller	The glue	Application Logic
(Utility)	(Communication)	HTTP Library

The Controller is the bridge between the Model and the View. The Model knows nothing about the View, and vice versa. Data flows from the Model → Controller → View. The Controller also listens for user actions and decides what needs to happen.

Why I Bothered Learning This

I didn’t always get this stuff. I came out of a 7-month bootcamp fast-tracked straight into frameworks. I could build fast, but I didn’t really understand where JavaScript ended and the frameworks began.

The better I understood what JavaScript was doing on its own, the more I built maintainable, easy to debug web apps.

That’s why this stuff matters. When your project gets more complex, (more contributors, more features, more tools) architecture becomes your best friend. And when you understand the pieces underneath those frameworks, they stop feeling like mysterious magic tricks. You stop guessing, start debugging, and maybe even feel kind of powerful.

Go forth and architecture! 🙌

Mocking localStorage in Jest (w/o breaking your brain 😂)

Tara Timmerman — Mon, 12 May 2025 18:04:44 +0000

This guide is for a TypeScript setup. If you're using plain JavaScript, you'll still find it helpful, just tweak the type-y bits!

⚡ TL;DR (Copy-Paste Ready)

Install dev deps

npm install --save-dev jest ts-jest @types/jest jest-localstorage-mock

Update jest.config.js

// jest.config.js
module.exports = {
  preset: "ts-jest",
  testEnvironment: "jsdom",
  setupFilesAfterEnv: ["jest-localstorage-mock"],
  // …other config…
};

Write tests

describe("localStorage mock", () => {
  beforeEach(() => localStorage.clear());

  it("stores and retrieves a value", () => {
    localStorage.setItem("key", "value");
    expect(localStorage.getItem("key")).toBe("value");
  });
  // …more tests…
});

Ever had a test accidentally wipe out your real browser data? Or tests fail intermittently because of leftover localStorage? I have, and all I can say is:

"No, thank you." - Me

But fear not! Mocking localStorage in Jest is the solution. It keeps your tests clean, safe, and gloriously isolated.

🎯 Why Bother Mocking?

Mocking localStorage with jest-localstorage-mock gives you:

🔁 A fresh, clean slate for every test.
🧼 Zero pollution across test cases.
🧪 Predictable behavior, no sneaky real browser interactions.
⚡ Faster, more reliable test runs.

🧰 What You’ll Need

Assuming you're working in a TypeScript project, install these dev dependencies to get started:

npm install --save-dev jest ts-jest @types/jest jest-localstorage-mock

This will install:

jest: The testing engine.
ts-jest: So Jest can understand TypeScript.
@types/jest: For autocomplete and type checking.
jest-localstorage-mock: The localStorage mock you didn’t know you needed.

🛠️ Setting Up Jest for localStorage Mocking

Create or update your jest.config.js at the root of your project:

// jest.config.js

/** @type {import('ts-jest').JestConfigWithTsJest} */
module.exports = {
  preset: "ts-jest",
  testEnvironment: "jsdom",
  transform: {
    "^.+\\.tsx?$": "ts-jest",
  },
  testMatch: ["**/?(*.)+(spec|test).[jt]s?(x)"],
  setupFilesAfterEnv: ["jest-localstorage-mock"], // Mocks localStorage before each test
};

With this setup, Jest will:

Run TypeScript using ts-jest,
Mock localStorage using jest-localstorage-mock,
Fake a browser with jsdom because localStorage is a browser API so we need a pretend browser to make it work.

🧪 Example Tests Using localStorage

With localStorage mocked, you can now write tests that interact with it just like you would in your app’s actual code.

describe("localStorage mock", () => {
  beforeEach(() => {
    localStorage.clear();
  });

  test("should store and retrieve a simple value", () => {
    localStorage.setItem("theme", "dark");
    expect(localStorage.getItem("theme")).toBe("dark");
  });

  test("should handle JSON data", () => {
    const settings = { notifications: true };
    localStorage.setItem("app-settings", JSON.stringify(settings));

    const saved = JSON.parse(localStorage.getItem("app-settings") || "{}");
    expect(saved.notifications).toBe(true);
  });

  test("should remove an item", () => {
    localStorage.setItem("activeTab", "dashboard");
    localStorage.removeItem("activeTab");

    expect(localStorage.getItem("activeTab")).toBe(null);
  });

  test("should clear all items", () => {
    localStorage.setItem("a", "1");
    localStorage.setItem("b", "2");
    localStorage.clear();

    expect(localStorage.getItem("a")).toBe(null);
    expect(localStorage.getItem("b")).toBe(null);
  });
});

💡 Quick Reality Check: Don’t Store Sensitive Stuff

This part’s serious: don’t store sensitive data like tokens, passwords, or anything personal in localStorage, especially outside tests.

It’s readable via browser dev tools and wide open to XSS attacks. Your tests won’t care, but real users will.

🙌 That’s It. Go Forth and Test!

✨ Copy, Paste, Test: A simple Jest setup for TypeScript apps

Tara Timmerman — Thu, 08 May 2025 00:46:46 +0000

Spinning up a small app? It’s tempting to skip testing. It can feel like overkill. But unit tests are like seatbelts for your code. You don't need them until you really, really do.

Here's how to quickly set up Jest with TypeScript, with minimal boilerplate. No stress, just copy and paste.

🚀 Quick setup: Copy & paste this

1. Install what you need

npm install --save-dev jest ts-jest @types/jest

This will install:

Jest: The testing framework.
ts-jest: A TypeScript preprocessor for Jest, so it can run TypeScript code.
@types/jest: Type definitions for Jest, so TypeScript understands Jest's global variables and methods.

2. Create your Jest config (`jest.config.js`)

/** @type {import('ts-jest').JestConfigWithTsJest} */
module.exports = {
  preset: "ts-jest",
  testEnvironment: "jsdom", // Use "node" if testing Node.js environments
  transform: {
    "^.+\\.tsx?$": "ts-jest",
  },
  testMatch: ["**/?(*.)+(spec|test).[jt]s?(x)"],
};

3. Create your TypeScript config (`tsconfig.json`)

If you already have a tsconfig.json, just make sure:

"jest" is in your compilerOptions.types array.
Your include section covers both your source code and test files

{
  "compilerOptions": {
    "target": "ES2022",
    "module": "ESNext",
    "lib": ["ES2022", "DOM"],
    "outDir": "./dist",
    "rootDir": "./src",
    "strict": true,
    "moduleResolution": "node",
    "esModuleInterop": true,
    "forceConsistentCasingInFileNames": true,
    "skipLibCheck": true,
    "types": ["jest"] // <--- ADD "jest" to your types array
  },
  "include": [
    "src", // <--- ENSURE YOUR MAIN SOURCE DIRECTORY IS INCLUDED
    "**/*.test.ts",
    "**/*.test.tsx",
    "**/*.spec.ts",
    "**/*.spec.tsx"
  ]
}

4. Add a test script to `package.json`

// Inside your package.json, under the "scripts" section:
"scripts": {
  "test": "jest"
}

🧪 Just to make sure this thing is actually working

Say you’ve got a utility function in src/utils/add.ts:

export function add(a: number, b: number): number {
  return a + b;
}

Now, create a test for it in src/utils/add.spec.ts:

import { add } from "./add";

describe("add", () => {
  it("adds two numbers", () => {
    expect(add(2, 3)).toBe(5);
  });
});

Run your tests with npm test, and boom, green means go. 🟢

💡 Notes & Customizations

Keep these points in mind for your project:

Source Location: Assumes main code is in src/. If yours is elsewhere (e.g., root, app/), update the include path(s) in tsconfig.json.
Test Environment: Default is jsdom (browser). For pure Node.js, change to "node" in jest.config.js.
Existing Test Script: If package.json has a test script, rename yours (e.g., "test:unit": "jest") or merge commands to avoid conflicts.
Minimal Setup: This is a quick-start config. Explore advanced Jest options (reporters, mocking, coverage, etc.) as needed.

🧱 Unit Tests are worth it (Even for tiny apps)

Unit tests sit at the base of the test pyramid. They’re small, fast, and often the most valuable tier of the testing process. Here’s why:

⚡ Fast: Unit tests run super quickly, so you can check things as you go.

🛡️ Safe: They help catch bugs early, before they spread.

💡 Great for Refactoring: You can tweak code without crossing your fingers.

Let’s say you need to change the add function to handle floating point numbers. Make the change, run your tests, and if something breaks, you’ll know right away.

🙌 That’s it. Now go write tests like you mean it.

How to fix a borked Elixir install on Windows

Tara Timmerman — Mon, 24 Apr 2023 16:26:03 +0000

So you borked the Elixir installation on your Windows machine. Same. Hopefully I can save you some trouble.

About 1.5 years ago, I was fresh out of dev school and managed to install Elixir on my PC without a package manager. Which is all fine and dandy until one needs to update it. Surely I could just follow the Erlang/Elixir Windows web installer instructions and I’ll be on my way, right? WRONG. Oh, so very wrong.

I was met with the dreaded crash dump:

{"init terminating in do_boot",{'cannot get bootfile','C:\\Program Files\\erl-24.1.7/bin/start.boot'}} init terminating in do_boot ({cannot get bootfile,C:\Program Files\erl-24.1.7/bin/start.boot})

Crash dump is being written to: erl_crash.dump...done.

Here’s how I fixed it:

Remove every existing trace of Erlang and Elixir installations from your PC. This might take some doing, depending on how creative your previous install was, but ya gotta do it. We want a clean slate here, people.
- Verify Erlang has been removed by running erl in your terminal.
- Verify Elixir has been removed by running iex in your terminal.
  - In both cases, if your terminal returns something along the lines of “command not found”, you’re golden.
  - If your terminal still crashes, or tries to look for old files, you have more clean up to do.
Choose and install a Windows software manager.
- I chose Chocolatey since I’ll only be using this machine for side projects and am content with sticking to their latest available software versions.
Install Erlang with Chocolatey first. This is important because Elixir runs on the Erlang VM, which is also another reason why we’re not using the aforementioned web installer.
- Test that the first installation was successful by running erl in your terminal.
  - If the Eshell starts, your install was successful.
Install Elixir with Chocolatey second.
- Your terminal will return a directory where the Elixir commands were installed.
  - Mine was: C:\ProgramData\chocolatey\lib\Elixir\tools\bin
Add that directory to your PATH.
Test that the second installation was successful by running iex in your terminal.
- If the Interactive Elixir shell starts, you’ve made it, congratulations. 🎉

Happy hacking!

Why Lambda School is worth it

Tara Timmerman — Thu, 27 May 2021 20:55:15 +0000

Eight months ago, I worked as a customer service consultant and had nearly zero programming experience. This month, I had the opportunity to work remotely with a team of nine developers to build a full-stack web application for a real-world client: Family Promise. Yeah, my mind is blown too.

Family Promise is a charitable organization that helps families experiencing homelessness and low-income families achieve lasting independence through community response. My team was part of the second Lambda School cohort that helped develop a Family Promise Service Tracking app. The project aims to offer our stakeholders a way to monitor and evaluate their impact and track their services on the go. As a new developer, this was a daunting task; I didn't want to let down my first client!

The bumpiest bump in the road

I decided to work server-side and pair programmed with two teammates to implement new database and API features. The project was smooth until the front-end development team found a blocker in our service logs. At the time, the React application had to submit separate GET requests to four different database tables to display the necessary information.

I realized the need for a new database model to export customized functions that integrate data from service entries, recipients, service types and status tables. The most difficult part of the implementation of the new service entry model was to find the correct SQL query to successfully join the tables and then convert the query into Knex. After some pair programming and help from our team lead, here is how we solved this problem:

// OLD CODE
// This old knex query is too simple now
// and has to be used for each individual table

const findAll = async (table) => {
  return await knex(table);
};

// NEW CODE
// This new knex query joins all needed tables in one call
// Efficiency at last!

const findAll = async () => {
  return await knex('service_entries')
    .leftJoin('recipients', {
      'service_entries.recipient_id': 'recipients.id',
    })
    .rightJoin('service_types', {
      'service_entries.service_type_id': 'service_types.id',
    })
    .rightJoin('statuses', {
      'service_entries.status_id': 'statuses.id',
    })
    .select(
      knex.raw(
        'service_entries.*, to_json(recipients.*) as recipient, to_json(service_types.*) as service_type, to_json(statuses.*) as status'
      )
    )
    .groupBy(
      'service_entries.id',
      'recipients.id',
      'service_types.id',
      'statuses.id'
    );
};

I ship it

It is safe to say that the team successfully met the MVP roadmap in four weeks.
Here's a complete list of what we've shipped:

1. Tablet-First:

The application supports tablet screens for data entry and general application use and users can easily use the application on a computer.

2. Service Management:

Users can log a service into the system, check service logs, and edit or delete a service log.

3. Recipients:

Users can add a service recipient to the system, search for recipients, and edit or delete a recipient.
Users can also track recipients on an individual and household basis.

4. Metrics:

I built four simple endpoints and queries that fetch the following metrics:

Amount of unique service recipients
Amount of logged services
New recipients created in the last 7 days
New services completed in the last 7 days

It was an excellent ride, chaps

I am thrilled about where this app will go. The stakeholder’s main vision is to have a full-screen, interactive map for a Family Promise employee or volunteer to monitor and evaluate their service analytics. My team spent significant time laying down the foundations and designing future possible implementations for the next step in metrics, and I am pleased with our work.

Sadly, our time to work together on this project has come to a close. I am so grateful for the opportunity to offer the 950 hours of coding experience I gained during my time at Lambda School to Family Promise, and I hope my contribution brings them closer to their goal of changing the lives of one million children by 2030. I know that developing a service tracking application teaches relevant skills for professional web development, and I look forward to applying this knowledge to future projects.