DEV Community: Karen Cohen

Calendars Are State Machines in Disguise: Building a Deterministic Date Engine in JavaScript

Karen Cohen — Sat, 26 Sep 2026 15:29:18 +0000

Most calendar bugs are not caused by complicated algorithms.

They are caused by unclear boundaries.

A calendar UI looks simple:

previous month
next month
7 columns
28–31 numbered cells
maybe a selected date

But underneath that interface is a surprisingly rich state machine.

A user can cross month boundaries.

A month can cross year boundaries.

Weeks can begin on different days.

The same calendar may need to render on a screen, in print, inside a PDF, or in a mobile interface.

And if date math is mixed directly into the UI, every new feature increases the number of assumptions the application has to remember.

I wanted to explore a different way to think about calendar software:

Treat the calendar as a deterministic state machine first, and as a visual grid second.

That single change makes the architecture much easier to test.

1. Start with state, not HTML

Imagine the visible calendar currently shows March 2027.

The minimum state is surprisingly small:

const state = {
  year: 2027,
  month: 3
};

That is enough to answer a large number of questions:

how many days are in the month?
which weekday contains day 1?
what comes before this month?
what comes after it?
how many leading cells are required?
how many rows are needed?

The UI should not be responsible for discovering those answers.

It should receive them.

This suggests an architecture like this:

User Action
    ↓
State Transition
    ↓
Calendar Model
    ↓
Renderer

The renderer becomes almost boring.

That is a good thing.

2. Month navigation is a state transition

A common implementation of "next month" starts accumulating conditions:

if (month === 12) {
  month = 1;
  year++;
} else {
  month++;
}

Then the same logic appears again for previous month.

Then somewhere else for a date picker.

Then again for a yearly calendar.

Instead, month navigation can be expressed as a single transformation.

function shiftMonth(year, month, amount) {
  const index = year * 12 + (month - 1) + amount;

  return {
    year: Math.floor(index / 12),
    month: ((index % 12) + 12) % 12 + 1
  };
}

Now:

shiftMonth(2027, 3, 1);

returns:

{
  year: 2027,
  month: 4
}

And:

shiftMonth(2027, 1, -1);

returns:

{
  year: 2026,
  month: 12
}

Notice what disappeared.

There is no special January branch.

No special December branch.

Year boundaries are just a consequence of arithmetic.

That is one of my favorite characteristics of good date code:

Edge cases stop looking like edge cases.

3. Define invariants before writing more features

An invariant is something that must always remain true.

For a calendar month model, useful invariants might include:

1 <= month <= 12

28 <= daysInMonth <= 31

0 <= firstWeekday <= 6

grid.length % 7 === 0

every visible day belongs to the requested month

These rules are more important than individual examples.

Why?

Because examples answer:

Does March 2027 work?

Invariants answer:

Can an entire class of invalid calendar states exist?

That distinction becomes powerful when testing.

4. Generate the month as data

Suppose we want a six-row calendar.

Instead of generating HTML directly, create a data structure.

function daysInMonth(year, month) {
  return new Date(
    Date.UTC(year, month, 0)
  ).getUTCDate();
}

function firstWeekday(year, month) {
  return new Date(
    Date.UTC(year, month - 1, 1)
  ).getUTCDay();
}

Now build the cells:

function createMonthGrid(
  year,
  month,
  weekStartsOn = 0
) {
  const totalDays = daysInMonth(year, month);

  const first =
    (firstWeekday(year, month) - weekStartsOn + 7) % 7;

  return Array.from({ length: 42 }, (_, index) => {
    const day = index - first + 1;

    if (day < 1 || day > totalDays) {
      return {
        type: "empty"
      };
    }

    return {
      type: "day",
      year,
      month,
      day
    };
  });
}

The important part is not the 42 cells.

The important part is that this function knows absolutely nothing about:

HTML
React
Vue
CSS
printing
localization
animations

It returns calendar information.

Nothing else.

5. Why I prefer tagged cells over `null`

A simpler implementation might return:

[
  null,
  null,
  null,
  1,
  2,
  3
]

That works.

But explicit data becomes more useful as the system grows.

For example:

{
  type: "day",
  year: 2027,
  month: 3,
  day: 14
}

Later, the model can evolve naturally:

{
  type: "day",
  year: 2027,
  month: 3,
  day: 14,
  isToday: false,
  isSelected: true,
  events: []
}

Meanwhile an empty cell remains:

{
  type: "empty"
}

Now the renderer can switch on intent:

for (const cell of grid) {
  if (cell.type === "empty") {
    renderEmptyCell();
    continue;
  }

  renderDayCell(cell);
}

This is much clearer than attaching meaning to magic values.

6. Don't let the renderer calculate dates

This is a boundary I try to keep strict.

Bad direction:

UI
├── calculates month length
├── calculates weekday offset
├── changes year
├── formats dates
└── renders cells

Better direction:

Calendar Engine
├── calculates month length
├── calculates offset
├── handles transitions
└── produces model

Renderer
└── displays model

The renderer should ideally be replaceable.

For example, the same model could become HTML:

function renderHTML(grid) {
  return grid.map(cell => {
    if (cell.type === "empty") {
      return `<div class="cell"></div>`;
    }

    return `
      <div class="cell">
        ${cell.day}
      </div>
    `;
  }).join("");
}

Or plain text:

function renderText(grid) {
  return grid
    .map(cell =>
      cell.type === "day"
        ? String(cell.day).padStart(2, " ")
        : "  "
    )
    .join(" ");
}

Or a printable layout.

The data model doesn't care.

7. This is where print architecture gets interesting

I ran into this distinction repeatedly while working around printable calendar systems and resources at JW Calendar.

Screen rendering and print rendering are related, but they are not the same problem.

A screen cares about:

viewport
interaction
responsive behavior
scrolling
dynamic resizing

A printed page cares about:

physical dimensions
page orientation
margins
page breaks
print scaling
ink and contrast

If the calendar engine produces neutral data, both environments can consume exactly the same month model.

That is much cleaner than making the date layer aware of A4 paper or CSS breakpoints.

8. Time zones should enter the system as late as possible

This is where many date-heavy applications become unnecessarily difficult.

Suppose the system needs to represent:

March 14, 2027

If that value represents a calendar cell, it does not inherently need:

hours
minutes
seconds
UTC offset
timezone

Those properties belong to different concepts.

Compare:

Calendar date:
2027-03-14

Meeting:
2027-03-14 at 09:00 America/New_York

Instant:
2027-03-14T13:00:00Z

These values are related.

They are not interchangeable.

A useful architectural rule is:

Don't introduce time-zone semantics into date-only data unless the domain actually requires them.

It reduces the number of transformations the application has to perform.

It also makes testing much easier.

9. Property-based thinking is perfect for calendars

Calendar systems have a huge input space.

Testing a few hand-picked months is useful.

But properties are often more powerful.

For example:

for (let year = 1900; year <= 2100; year++) {
  for (let month = 1; month <= 12; month++) {
    const grid = createMonthGrid(year, month);

    if (grid.length !== 42) {
      throw new Error(
        `Invalid grid size: ${year}-${month}`
      );
    }
  }
}

Now test the number of visible days:

for (let year = 1900; year <= 2100; year++) {
  for (let month = 1; month <= 12; month++) {
    const grid = createMonthGrid(year, month);

    const visibleDays = grid.filter(
      cell => cell.type === "day"
    );

    const expected = daysInMonth(year, month);

    if (visibleDays.length !== expected) {
      throw new Error(
        `Wrong day count: ${year}-${month}`
      );
    }
  }
}

Instead of testing twelve carefully selected calendars, we just tested 2,412 months.

That still runs almost instantly.

10. Test reversibility

A useful property of month navigation is reversibility.

If we move forward by one month and then backward by one month, we should return to the original state.

function assertSameMonth(a, b) {
  return (
    a.year === b.year &&
    a.month === b.month
  );
}

Then:

for (let year = 1900; year <= 2100; year++) {
  for (let month = 1; month <= 12; month++) {
    const original = { year, month };

    const next = shiftMonth(year, month, 1);

    const back = shiftMonth(
      next.year,
      next.month,
      -1
    );

    if (!assertSameMonth(original, back)) {
      throw new Error(
        `Transition failure: ${year}-${month}`
      );
    }
  }
}

This catches an entire category of boundary bugs.

Especially:

December → January
January → December

without writing separate tests for either transition.

11. Test composition

Month shifting should also compose correctly.

These two operations:

shiftMonth(2027, 3, 12);

and:

shiftMonth(
  shiftMonth(2027, 3, 6).year,
  shiftMonth(2027, 3, 6).month,
  6
);

should produce the same result.

More generally:

shift(a + b)
=
shift(a), then shift(b)

That gives us another property to verify.

function shiftTwice(year, month, a, b) {
  const first = shiftMonth(year, month, a);

  return shiftMonth(
    first.year,
    first.month,
    b
  );
}

Then compare:

const direct = shiftMonth(2027, 3, 17);

const composed = shiftTwice(
  2027,
  3,
  8,
  9
);

If the transition system is correct:

assertSameMonth(direct, composed);

should always be true.

This is the point where calendar code starts feeling less like UI programming and more like a small algebra.

12. A reducer makes the state machine explicit

Once interactions become more complex, a reducer can make transitions easy to reason about.

function calendarReducer(state, action) {
  switch (action.type) {
    case "NEXT_MONTH":
      return shiftMonth(
        state.year,
        state.month,
        1
      );

    case "PREVIOUS_MONTH":
      return shiftMonth(
        state.year,
        state.month,
        -1
      );

    case "NEXT_YEAR":
      return shiftMonth(
        state.year,
        state.month,
        12
      );

    case "PREVIOUS_YEAR":
      return shiftMonth(
        state.year,
        state.month,
        -12
      );

    case "GO_TO_MONTH":
      return {
        year: action.year,
        month: action.month
      };

    default:
      return state;
  }
}

Now every user interaction becomes an explicit state transition.

state = calendarReducer(state, {
  type: "NEXT_MONTH"
});

That makes debugging much easier.

Instead of asking:

Which click handler changed this value?

you can ask:

Which action moved the machine into this state?

13. Invalid states should be difficult to represent

This principle has become increasingly important to me.

If the calendar expects months from 1 to 12, allowing this:

{
  year: 2027,
  month: 938
}

through the entire application is unnecessary risk.

Validate at the boundary:

function createCalendarState(year, month) {
  if (!Number.isInteger(year)) {
    throw new TypeError("year must be an integer");
  }

  if (
    !Number.isInteger(month) ||
    month < 1 ||
    month > 12
  ) {
    throw new RangeError(
      "month must be between 1 and 12"
    );
  }

  return {
    year,
    month
  };
}

After that point, internal functions can operate under stronger assumptions.

This reduces defensive code everywhere else.

Instead of checking the same condition in ten components, check it once at the system boundary.

14. Separate domain state from interface state

Not every piece of UI state belongs inside the calendar model.

For example:

{
  year: 2027,
  month: 3,
  sidebarOpen: true,
  animationDirection: "left",
  modalVisible: false
}

mixes unrelated concerns.

A cleaner distinction is:

const calendarState = {
  year: 2027,
  month: 3
};

and:

const interfaceState = {
  sidebarOpen: true,
  modalVisible: false
};

Why does this matter?

Because the calendar engine should still work if tomorrow you delete the sidebar completely.

Domain state survives interface redesigns.

UI state does not.

15. Determinism is an underrated feature

Given the same inputs:

createMonthGrid(2027, 3, 1);

should always return the same output.

No browser locale.

No current clock.

No hidden timezone.

No DOM state.

No network request.

That property is extremely valuable.

A deterministic calendar model is:

easy to cache
easy to test
easy to serialize
easy to render on a server
easy to reproduce during debugging
easy to reuse in different interfaces

If a user reports:

March 2027 renders incorrectly with Monday-first weeks

you only need three values to reproduce it:

year = 2027
month = 3
weekStartsOn = 1

That is a very nice debugging surface.

16. Avoid reading "now" inside pure calendar functions

Consider this:

function createCell(day) {
  const today = new Date();

  return {
    day,
    isToday:
      day === today.getDate()
  };
}

Now the function is time-dependent.

Its output changes even when its explicit input doesn't.

That makes testing harder.

Instead, inject the reference date:

function createCell(
  year,
  month,
  day,
  today
) {
  return {
    year,
    month,
    day,
    isToday:
      year === today.year &&
      month === today.month &&
      day === today.day
  };
}

Now:

createCell(
  2027,
  3,
  14,
  {
    year: 2027,
    month: 3,
    day: 14
  }
);

is deterministic.

The current clock belongs at the boundary of the system.

Not buried inside the model.

17. The final architecture is intentionally boring

After stripping away framework-specific details, the design becomes:

INPUT
  │
  ↓
VALIDATION
  │
  ↓
CALENDAR STATE
  │
  ↓
STATE TRANSITIONS
  │
  ↓
MONTH MODEL
  │
  ├── WEB RENDERER
  ├── MOBILE RENDERER
  ├── PRINT RENDERER
  └── PDF RENDERER

Each layer has one job.

Validation prevents invalid state.

Transitions modify state.

The month model derives calendar data.

Renderers decide how that data looks.

None of those layers need to know everything about the others.

And that is probably the biggest lesson I have taken from building date-heavy interfaces:

Complexity becomes manageable when responsibilities stop leaking across boundaries.

Final thought

A calendar is visually simple enough that it invites shortcuts.

That is exactly what makes it interesting.

The interface encourages us to think:

It's just seven columns.

But underneath those seven columns are:

state transitions
arithmetic
invariants
regional configuration
deterministic modeling
boundary testing
accessibility
print rendering
timezone semantics
serialization
validation

The surprising part is that none of these require a complicated architecture.

In fact, the more complicated the requirements become, the more valuable a small deterministic core becomes.

The best calendar engine may be the one that knows almost nothing about calendars as a user interface.

It only knows how calendar state behaves.

And everything else is presentation.

What other "simple" UI component have you worked on that turned out to hide a much deeper domain model?

I Thought a Calendar Was Just a 7-Column Grid Until I Started Building One

Karen Cohen — Sat, 26 Sep 2026 15:16:01 +0000

A calendar looks like one of the simplest interfaces on the web.

Seven columns. A few rows. Some numbers. Maybe a previous and next button.

That was roughly how I thought about calendars too.

Then I started looking more closely at how calendar interfaces actually work, and the "simple grid" turned into a surprisingly interesting engineering problem.

Dates are not always timestamps.

Weeks don't start on the same day everywhere.

Months aren't the same length.

Printing has completely different constraints from screens.

Accessibility changes how the structure should be built.

And then there are time zones.

Here are the things that surprised me most.

1. A calendar date is not necessarily a timestamp

Consider this:

const date = new Date("2027-01-01");

console.log(date);

At first glance, this seems perfectly reasonable.

We want January 1, 2027.

But JavaScript's Date represents a point on a timeline. A calendar date and an instant in time are not always the same concept.

Think about a birthday.

If someone says:

My birthday is January 1.

They usually don't mean:

My birthday occurs at exactly midnight UTC.

They mean a date on a calendar.

That difference matters.

A simple calendar date is conceptually closer to:

year:  2027
month: January
day:   1

No hour.

No minute.

No timezone.

This distinction becomes especially important when the same interface needs to work across locations.

For date-only data, adding a timezone too early can create problems instead of solving them.

2. Separate calendar math from presentation

Another thing I learned quickly: don't make one function responsible for everything.

It is tempting to start with something like:

function renderMonth(year, month) {
  // calculate dates
  // generate HTML
  // format labels
  // decide week start
  // create CSS classes
  // handle empty cells
}

That can work for the first version.

Then you want a yearly layout.

Then a printable version.

Then another locale.

Then Monday-first weeks.

Suddenly the function knows far too much.

A cleaner model is:

DATE CALCULATIONS
        ↓
   MONTH MODEL
        ↓
  PRESENTATION
        ↓
WEB / MOBILE / PRINT

For example, the date layer can remain very small:

function getMonthData(year, month) {
  const firstDay = new Date(
    Date.UTC(year, month - 1, 1)
  );

  const daysInMonth = new Date(
    Date.UTC(year, month, 0)
  ).getUTCDate();

  return {
    year,
    month,
    firstWeekday: firstDay.getUTCDay(),
    daysInMonth
  };
}

That function doesn't care how the month will eventually look.

It can feed:

a desktop calendar
a mobile calendar
a yearly overview
a printable page
a PDF generator

The boring architecture turned out to be the useful architecture.

3. A month grid is mostly an offset problem

At the UI level, one of the most important questions is:

Which cell should contain day 1?

Imagine a Sunday-first calendar where the first day of the month is Friday:

SUN MON TUE WED THU FRI SAT
                     1   2
 3   4   5   6   7   8   9
10  11  12  13  14  15  16
17  18  19  20  21  22  23
24  25  26  27  28  29  30
31

The month is basically:

leading empty cells
+
actual dates
+
trailing empty cells

A reusable grid generator can look like this:

function buildMonthGrid(
  year,
  month,
  weekStartsOn = 0
) {
  const firstDay = new Date(
    Date.UTC(year, month - 1, 1)
  );

  const daysInMonth = new Date(
    Date.UTC(year, month, 0)
  ).getUTCDate();

  const offset =
    (firstDay.getUTCDay() - weekStartsOn + 7) % 7;

  return Array.from({ length: 42 }, (_, index) => {
    const day = index - offset + 1;

    return day >= 1 && day <= daysInMonth
      ? day
      : null;
  });
}

Why 42?

7 columns × 6 rows = 42 cells

Not every month needs six rows, but some do.

A fixed grid can also prevent the interface from jumping vertically when someone moves from one month to another.

Small detail, better experience.

4. Sunday-first and Monday-first should be configuration

This:

SUN MON TUE WED THU FRI SAT

and this:

MON TUE WED THU FRI SAT SUN

should not require two calendar engines.

They are simply different configurations.

buildMonthGrid(2027, 1, 0);
// Sunday-first

buildMonthGrid(2027, 1, 1);
// Monday-first

The rendering layer doesn't need to understand why the week begins on a particular day.

It only needs to support the choice.

That led me to a broader rule I like:

Regional behavior should usually be configuration, not architecture.

5. Don't hard-code what the platform already knows

Month names are another easy example.

You could write:

const months = [
  "January",
  "February",
  "March",
  "April",
  "May",
  "June",
  "July",
  "August",
  "September",
  "October",
  "November",
  "December"
];

Nothing is inherently wrong with that for a tiny English-only project.

But the browser already has internationalization tools:

const formatter = new Intl.DateTimeFormat(
  "en-US",
  {
    month: "long",
    timeZone: "UTC"
  }
);

const monthName = formatter.format(
  new Date(Date.UTC(2027, 0, 1))
);

console.log(monthName);
// January

Now localization belongs to the presentation layer rather than the calendar engine.

That separation becomes increasingly valuable as the project grows.

6. CSS Grid makes the visual part surprisingly straightforward

Once the data model is correct, the basic seven-column interface is almost boring:

.calendar-grid {
  display: grid;
  grid-template-columns: repeat(7, 1fr);
  gap: 1px;
}

.calendar-cell {
  min-height: 7rem;
  padding: 0.75rem;
  border: 1px solid #ddd;
}

Seven columns.

Done.

You can then adapt the presentation without changing the underlying dates:

@media (max-width: 700px) {
  .calendar-cell {
    min-height: 5rem;
    padding: 0.4rem;
  }
}

Or reuse the same month model inside a yearly layout:

.year-grid {
  display: grid;
  grid-template-columns:
    repeat(auto-fit, minmax(260px, 1fr));
  gap: 2rem;
}

This is where the separation starts paying off.

The data does not know whether it is being displayed in one column or twelve.

7. Print is a completely different medium

This has been one of the more interesting problems for me while working with calendar resources at JW Calendar.

Responsive web design asks:

How should this adapt to the viewport?

Printable design asks:

How do I make this fit correctly onto a physical sheet of paper?

Those are very different questions.

Suddenly you care about millimeters.

Margins.

Orientation.

Page boundaries.

Browser scaling.

Page breaks.

Printer behavior.

A simple print stylesheet might begin like this:

@media print {
  @page {
    size: A4 landscape;
    margin: 10mm;
  }

  .toolbar,
  .navigation,
  .no-print {
    display: none !important;
  }

  .calendar {
    width: 100%;
    break-inside: avoid;
  }

  body {
    print-color-adjust: exact;
    -webkit-print-color-adjust: exact;
  }
}

The same calendar now lives in two layout systems:

SCREEN
├── viewport
├── responsive breakpoints
├── interaction
└── dynamic resizing

PRINT
├── physical page size
├── margins
├── orientation
├── page breaks
└── printer/browser behavior

A calendar can look perfect in a browser and terrible in print preview.

So for printable interfaces, print CSS isn't just a finishing touch.

It is another rendering environment.

8. Semantic HTML matters

It is very easy to make a calendar out of anonymous <div> elements:

<div class="calendar">
  <div>Sun</div>
  <div>Mon</div>
  <div>Tue</div>
</div>

Visually, that may look fine.

But a calendar contains relationships.

A date belongs to a weekday.

A weekday belongs to a week.

Weeks belong to months.

For a static calendar, table semantics can sometimes express those relationships naturally:

<table>
  <caption>January 2027</caption>

  <thead>
    <tr>
      <th scope="col">Sunday</th>
      <th scope="col">Monday</th>
      <th scope="col">Tuesday</th>
      <th scope="col">Wednesday</th>
      <th scope="col">Thursday</th>
      <th scope="col">Friday</th>
      <th scope="col">Saturday</th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td></td>
      <td></td>
      <td></td>
      <td></td>
      <td></td>

      <td>
        <time datetime="2027-01-01">1</time>
      </td>

      <td>
        <time datetime="2027-01-02">2</time>
      </td>
    </tr>
  </tbody>
</table>

The point isn't that every calendar must use a table.

The point is:

Choose markup that preserves meaning.

A visually correct grid isn't automatically an accessible grid.

9. Empty cells aren't really empty

Look at this again:

SUN MON TUE WED THU FRI SAT
                     1   2

The first cells contain no date.

But they still communicate important information.

They tell us that day 1 belongs under Friday.

Remove those cells and you remove the spatial relationship.

I like this as a general UI lesson:

Sometimes absence is information.

Sometimes "nothing" is data.

10. Leap years are actually one of the easier edge cases

Leap years are probably the most famous calendar edge case.

But if the number of days is derived rather than manually stored, they become almost boring:

function daysInMonth(year, month) {
  return new Date(
    Date.UTC(year, month, 0)
  ).getUTCDate();
}

Now:

daysInMonth(2027, 2);
// 28

and:

daysInMonth(2028, 2);
// 29

No February-specific branch.

No separate lookup table.

No duplicated knowledge.

A useful rule appears again:

Prefer deriving truth from reliable primitives when possible.

11. Test the boundaries

If I were testing a calendar engine, I wouldn't spend most of my time on random dates in the middle of ordinary months.

I'd test the edges:

January → February
February → March
December → January
February 28
February 29
Sunday-first layouts
Monday-first layouts
months requiring six rows
year boundaries
locale changes

For example:

console.assert(
  daysInMonth(2028, 2) === 29
);

console.assert(
  daysInMonth(2027, 2) === 28
);

console.assert(
  daysInMonth(2027, 4) === 30
);

console.assert(
  daysInMonth(2027, 1) === 31
);

The middle of a system is usually where our assumptions work.

The edges are where those assumptions become visible.

12. Different date problems deserve different representations

Consider these four pieces of information:

Birthday:
January 12

Meeting:
January 12 at 14:00 in New York

Server event:
2027-01-12T19:00:00Z

Printed calendar cell:
January 12

They may look similar on a screen.

But they represent different concepts.

A useful calendar system might therefore use:

year/month/day data for calendar cells
an instant for machine events
timezone-aware data for scheduled meetings
locale formatting only when rendering

Trying to force every date-related concept into one representation can make the system harder to reason about.

Final thought

The most useful lesson I got from calendars has surprisingly little to do with calendars.

Simple interfaces can hide complicated domain rules.

Whenever something looks too easy, I now find it useful to ask:

What assumptions am I making simply because the UI looks simple?

Sometimes seven columns are just seven columns.

And sometimes they're hiding date arithmetic, localization, accessibility, responsive design, printing, regional conventions, and time zones.

I'd love to hear how other developers approach date-heavy interfaces.

What's the strangest calendar, timezone, or date bug you've ever had to fix?

DEV Community: Karen Cohen

Calendars Are State Machines in Disguise: Building a Deterministic Date Engine in JavaScript

1. Start with state, not HTML

2. Month navigation is a state transition

3. Define invariants before writing more features

4. Generate the month as data

5. Why I prefer tagged cells over null

6. Don't let the renderer calculate dates

7. This is where print architecture gets interesting

8. Time zones should enter the system as late as possible

9. Property-based thinking is perfect for calendars

10. Test reversibility

11. Test composition

12. A reducer makes the state machine explicit

13. Invalid states should be difficult to represent

14. Separate domain state from interface state

15. Determinism is an underrated feature

16. Avoid reading "now" inside pure calendar functions

17. The final architecture is intentionally boring

Final thought

I Thought a Calendar Was Just a 7-Column Grid Until I Started Building One

1. A calendar date is not necessarily a timestamp

2. Separate calendar math from presentation

3. A month grid is mostly an offset problem

4. Sunday-first and Monday-first should be configuration

5. Don't hard-code what the platform already knows

6. CSS Grid makes the visual part surprisingly straightforward

7. Print is a completely different medium

8. Semantic HTML matters

9. Empty cells aren't really empty

10. Leap years are actually one of the easier edge cases

11. Test the boundaries

12. Different date problems deserve different representations

Final thought

5. Why I prefer tagged cells over `null`