DEV Community: tem chelsy

How I Implemented the SM-2 Spaced Repetition Algorithm in My Flashcard App

tem chelsy — Thu, 05 Mar 2026 10:16:35 +0000

What Is Spaced Repetition?

Here's the problem with traditional studying: you review everything equally, whether you know it or not. That's inefficient.

Spaced repetition flips this. Cards you struggle with come back sooner. Cards you know well get pushed further into the future. Over time, you spend your energy exactly where it's needed.

The SM-2 algorithm (developed by Piotr Wozniak in 1987) is the math behind this. It's the same core logic used in Anki — one of the most popular study tools in the world.

📐 The SM-2 Formula Explained

Every card tracks three values:

Variable	Meaning
`repetitions`	How many times you've answered correctly in a row
`easeFactor` (EF)	How "easy" the card is (starts at 2.5, min 1.3)
`interval`	Days until next review

After each review, the user rates their recall from 0 to 5:

0–2 = Failed (didn't remember)
3 = Barely remembered
4 = Correct with some hesitation
5 = Perfect recall

Here's the core logic:

function sm2(card, quality) {
  // quality: 0-5 rating from the user

  if (quality < 3) {
    // Failed — reset streak, review again soon
    card.repetitions = 0;
    card.interval = 1;
  } else {
    // Passed — calculate next interval
    if (card.repetitions === 0) {
      card.interval = 1;
    } else if (card.repetitions === 1) {
      card.interval = 6;
    } else {
      card.interval = Math.round(card.interval * card.easeFactor);
    }
    card.repetitions += 1;
  }

  // Update ease factor
  card.easeFactor = card.easeFactor + (0.1 - (5 - quality) * (0.08 + (5 - quality) * 0.02));

  // Ease factor never drops below 1.3
  if (card.easeFactor < 1.3) card.easeFactor = 1.3;

  // Set next review date
  card.nextReviewAt = new Date();
  card.nextReviewAt.setDate(card.nextReviewAt.getDate() + card.interval);

  return card;
}

That's it. The whole algorithm fits in about 20 lines.

How I Modeled This in the Database

In my Laravel backend, each card record in the cards table stores its SM-2 state:

// database/migrations/create_cards_table.php

Schema::create('cards', function (Blueprint $table) {
    $table->id();
    $table->foreignId('deck_id')->constrained()->cascadeOnDelete();
    $table->text('front');
    $table->text('back');

    // SM-2 fields
    $table->integer('repetitions')->default(0);
    $table->float('ease_factor')->default(2.5);
    $table->integer('interval')->default(1);
    $table->timestamp('next_review_at')->nullable();

    $table->timestamps();
});

When a study session ends, the frontend sends the user's rating to the API, and the backend runs the SM-2 calculation and updates these fields.

🔁 The Study Session Flow

Here's how a full study session works end-to-end:

1. Fetch due cards (Laravel Controller)

// CardController.php

public function getDueCards($deckId)
{
    $cards = Card::where('deck_id', $deckId)
        ->where(function ($query) {
            $query->whereNull('next_review_at')
                  ->orWhere('next_review_at', '<=', now());
        })
        ->get();

    return response()->json($cards);
}

Cards are "due" if next_review_at is null (never studied) or in the past.

2. User studies & rates each card (Vue 3 frontend)

<!-- StudySession.vue -->
<template>
  <div class="card-container">
    <div class="card" @click="flipped = !flipped">
      <div v-if="!flipped">{{ currentCard.front }}</div>
      <div v-else>{{ currentCard.back }}</div>
    </div>

    <div v-if="flipped" class="rating-buttons">
      <button v-for="rating in [0, 1, 2, 3, 4, 5]"
              :key="rating"
              @click="submitRating(rating)">
        {{ ratingLabel(rating) }}
      </button>
    </div>
  </div>
</template>

<script setup>
import { ref } from 'vue'
import { useStudyStore } from '@/stores/studyStore'

const store = useStudyStore()
const flipped = ref(false)
const currentCard = computed(() => store.currentCard)

async function submitRating(quality) {
  flipped.value = false
  await store.rateCard(currentCard.value.id, quality)
}

function ratingLabel(q) {
  const labels = ['Blackout', 'Wrong', 'Wrong (familiar)', 'Hard', 'Good', 'Easy']
  return labels[q]
}
</script>

3. Backend applies SM-2 and saves

// StudySessionController.php

public function rateCard(Request $request, $cardId)
{
    $card = Card::findOrFail($cardId);
    $quality = $request->input('quality'); // 0-5

    // Run SM-2
    if ($quality < 3) {
        $card->repetitions = 0;
        $card->interval = 1;
    } else {
        if ($card->repetitions === 0) {
            $card->interval = 1;
        } elseif ($card->repetitions === 1) {
            $card->interval = 6;
        } else {
            $card->interval = round($card->interval * $card->ease_factor);
        }
        $card->repetitions += 1;
    }

    $newEF = $card->ease_factor + (0.1 - (5 - $quality) * (0.08 + (5 - $quality) * 0.02));
    $card->ease_factor = max(1.3, $newEF);
    $card->next_review_at = now()->addDays($card->interval);

    $card->save();

    return response()->json($card);
}

What I Learned Building This

1. SM-2 is deceptively simple. The algorithm itself is tiny — the complexity is in building the session UX around it (card flipping, ratings, progress tracking).

2. The ease factor is the secret sauce. Cards you consistently ace get pushed further and further apart automatically. Cards you keep failing stay frequent. You don't need to configure anything — it self-adjusts.

3. "Due cards" queries need an index. Once you have thousands of cards, querying by next_review_at gets slow. I added a database index on that column and it made a noticeable difference:

$table->index('next_review_at');

4. Failed cards should NOT reset interval to 0. A common mistake is setting interval = 0 on failure, which means the card shows up immediately in the same session forever. Setting it to 1 (review tomorrow) feels much better in practice.

What's Next

The SM-2 algorithm is from 1987 — it works, but there are newer alternatives. The FSRS algorithm (Free Spaced Repetition Scheduler) is a modern neural-network-based approach that reportedly outperforms SM-2. It's on my roadmap to implement next.

If you're curious about the full project — including AI card generation with Groq LLaMA, community decks, and Google OAuth — the repo is here: github.com/chelsynew72/flashcard-app and the live demo is at flashcard-app-five-gamma.vercel.app.

Have you built anything with spaced repetition? I'd love to hear how you approached it — drop a comment below!

Next.js Finally Made Caching Make Sense — At Least to Me

tem chelsy — Fri, 20 Feb 2026 15:07:26 +0000

Okay so I have to be honest. When I first started learning Next.js, caching was the thing that broke my brain the most. I'd make a change to my data, refresh the page in production, and nothing would update. I'd Google it, find some Stack Overflow answer about revalidatePath or no-store, paste it in, and sometimes it worked. Sometimes it didn't. I never really understood why.

Turns out I wasn't alone. A lot of developers — including experienced ones — found Next.js caching confusing. And with Next.js 16, the team actually did something about it.

What Was the Problem?

In older versions of Next.js, caching happened automatically behind the scenes. Your pages were cached by default, and if you wanted fresh data, you had to know exactly which option to add, where to add it, and in what kind of file. The framework was making decisions for you without really telling you.

For a junior dev like me, that's really hard to debug. You don't know if the problem is your code, your fetch call, your deployment, or the framework itself quietly doing something you didn't ask for.

The New Way: `"use cache"`

Next.js 16 introduces something called Cache Components, and the main idea is just one line: "use cache".

You put it at the top of a component, a page, or even a single function — and that's what gets cached. If you don't write it, the page runs fresh on every request by default. That's it. You're in control now.

"use cache"

export default async function BlogPost() {
  const post = await fetchPost()
  return <article>{post.content}</article>
}

For me, this is so much easier to reason about. I can look at any file and immediately know: does it have "use cache" or not? That's my answer. No more digging through docs trying to figure out why my data is stale.

Pages Can Now Be Both Fast and Fresh

There's also something called Partial Pre-Rendering, and Next.js 16 is where it actually starts to click.

Here's the idea: imagine you have a blog post page. Most of it never changes — the title, the text, the author. But there's a comment counter at the bottom that should always be live. Before, you had to choose: make the whole page fast and static, or make the whole page dynamic and slower. There was no in-between.

Now you can cache the parts that don't change and let the live parts load in separately. The page still loads instantly. The comment counter catches up right after. Users get both.

That's genuinely cool and something I struggled to do cleanly before.

Dev Server Is So Much Faster Now

Next.js 16 also makes Turbopack the default bundler. I didn't fully understand what a bundler was when I started, but what I do know is that my dev server used to take a while to start and Fast Refresh sometimes felt slow on bigger projects.

With Turbopack, it's noticeably faster. And now it caches stuff between restarts, so when you stop and start your dev server, it doesn't have to redo everything from scratch. Small thing, but when you're restarting your server ten times a day while debugging, you feel it.

Less Boilerplate With the React Compiler

This one I'm still wrapping my head around, but basically — if you've ever been told to use useMemo or useCallback to stop your components from re-rendering too much, Next.js 16 includes the React Compiler which handles a lot of that automatically.

I'll be honest, I've copy-pasted useCallback without fully understanding it more than once. Knowing the compiler can handle some of that optimization for me is reassuring.

I'm still learning Next.js every day, and I don't have all the answers. But Next.js 16 is the first version where I feel like the framework is working with me instead of quietly doing things I can't see. The caching changes alone would have saved me hours of confusion when I was starting out.

If you're also a junior dev trying to figure this stuff out — yeah, it was confusing before. It's better now.