历史与确认页：两个小而致命的细节The history and confirmation pages: two small details that decide pass or fail

In one line: arr.slice(-3) takes the last three; arr.slice(0, 3) takes the first three.

Start from how the data is ordered: updateBookedCabDetails uses [...rideHistory, details], so new records are appended at the tail. The array runs oldest to newest.

Notice how sneaky slice(0, 3) is: toHaveLength(3) passes, because there really are three rows. Only that final queryByText(/Ford Fusion/) line catches it.
Which is precisely why test 4 has that line — counting is not enough; you have to check that what should be gone is gone.

Follow-up: “What does slice(-3) do with fewer than three entries?” — it is safe. With one entry it returns that one; with an empty array it returns an empty array; no error and no undefined padding. So test 1 (empty) and test 3 (one entry) need no special handling.
Worth remembering: slice never throws on out-of-range, which is one reason it beats a hand-written index loop.

In one line: reverse() mutates the array it is called on, but slice() hands back a new array — so slice(-3).reverse() reverses the copy and never touches state.

What a bare rideHistory.reverse() would do:

• The state array is flipped in place — it now runs newest to oldest;
• React has no idea (the reference did not change, so not even a re-render is triggered);
• The next [...rideHistory, details] appends to an already-reversed array, and the ordering is now meaningless;
• And it flips again on every render, so the order oscillates between two arrangements.

The bug is wildly unstable because it depends on the render count — StrictMode renders twice in development, two flips cancel out, so it looks right while you develop and is wrong in production.

Which array methods mutate:

The three people forget are sort / reverse / splice — they read like computations and are really mutations.
Follow-up: “Are there non-mutating versions?” — yes: toSorted() / toReversed() / toSpliced(), added in ES2023 and available in Node 20+ and current browsers. But slice(-3).reverse() here is already safe, so there is no need to switch — just know they exist.

In one line: bookedCabDetails starts as null, and null.name throws a TypeError, so you write ?.name.

When it really is null:

• Right after the app starts, before the user has picked anything — but CabConfirmation is not rendered then, so nothing breaks;
• The moment somebody renders CabConfirmation on its own — say in a component-level unit test — it throws immediately;
• Or add a “view your last ride” entry point later and open it with no rides: blank screen and one console line reading Cannot read properties of null (reading 'name').

What optional chaining does: when the left side is null or undefined, the whole expression short-circuits to undefined instead of throwing. And React renders nothing at all for {undefined} (not the literal string “undefined”), so the page is just missing a phrase rather than crashing.

It only guards null and undefined — with bookedCabDetails as {}, ?.name is still undefined, but that is a missing property, not a crash. ?. protects against the property access itself blowing up.

Follow-up: “Should I add ?. everywhere then?” — no. Sprinkling it everywhere flattens the signal “this might be absent” into noise, and the places that genuinely can be empty stop standing out.
The rule: add it only where the value really can be missing. Here bookedCabDetails starts as null, so it earns one; ride.name comes from iterating records that always have a name to be in the array at all, so it does not.