Lab

Pure functions

PURE-101 Easy · Build ~15 min

Select the accounts due for a reminder

The backend can calculate one trial’s remaining days. A reminder job now needs the accounts expiring within a supplied window. The starter selects every non-expired trial, including ones too far in the future.

Accounts outside the reminder window appear in the batch. The caller also needs the original account collection for another calculation.

Reproduce

Select the sample at day 40 with a 2-day window. The account ending on day 50 should stay out; the accounts ending on day 42 and day 40 should remain, in that order.

Acceptance criteria

Return only accounts inside the inclusive window.
Keep the input’s relative order.
Leave the supplied collection and its records unchanged.
Use the supplied day and window on every call, including a repeated request after another day.

Check work runs these cases against your code once you sign in.

Not run:Only the inclusive reminder window, in input order
selectDue([{"id":"later","endsOn":50},{"id":"near","endsOn":42},{"id":"past","endsOn":39},{"id":"today","endsOn":40}], 40, 2)
Not run:An account expiring today remains due
selectDue([{"id":"near","endsOn":42}], 42, 0)
Not run:Yesterday is outside the window
selectDue([{"id":"near","endsOn":42}], 43, 5)
Not run:An empty collection is a valid input
selectDue([], 40, 2)
Not run:A different day does not change a repeated request
selectDue([{"id":"near","endsOn":42}], 40, 2); selectDue([{"id":"near","endsOn":42}], 43, 2); selectDue([{"id":"near","endsOn":42}], 40, 2)
Not run:A narrower policy excludes tomorrow
selectDue([{"id":"near","endsOn":42}], 40, 1)
Not run:Due accounts retain the supplied order
selectDue([{"id":"z","endsOn":42},{"id":"a","endsOn":41}], 40, 2)

Notes

Inputs are already validated: unique nonempty account IDs, whole day indices from 0 to 10000, and a reminder window from 0 to 30. The service has already chosen its calendar convention; do not parse dates or read a clock.
An account is due when 0 ≤ endsOn − today ≤ window, including expiry day. Keep input order and leave supplied records unchanged.
The sent list is a local delivery stand-in, not an email service. Each case creates fresh state; all requests inside that case use one service. Sending twice is two explicit sends, not deduplication.
Keep the supplied entry points and data fields. Alternate loops and helpers are welcome. The checks observe outputs, input preservation and the supplied sent list; they cannot prove arbitrary code has no other side effects.

Hints

Reference answerTry the cases first

type Trial = { id: string; endsOn: number };


function selectDue(trials: Trial[], today: number, window: number): Trial[] {
  return trials.filter(trial => {
    const daysLeft = trial.endsOn - today;
    return daysLeft >= 0 && daysLeft <= window;
  });
}

Selection is another calculation from values. The caller supplies a day and window; the function selects into a new collection, preserving order. TypeScript’s new array still refers to the original trial objects; the contract does not promise a deep copy. Go appends value copies of these simple structs, whose fields are only a string and an integer. Rust clones the small records from a shared slice. Each implementation leaves the supplied records unchanged.

Sign in to run your code

Read the brief and the starter here. With a free account you can edit it, run the sample, step through it and check your work, and your progress is kept.

type Trial = { id: string; endsOn: number };


function selectDue(trials: Trial[], today: number, window: number): Trial[] {
  return trials.filter(trial => {
    const daysLeft = trial.endsOn - today;
    return daysLeft >= 0;
  });
}