# 02 - M1.8 Revision Sheet & Interview Q&A

Short revision guide for **Milestone 1.8**.

---

## 1. Quick Summary

- **What We Built:** Implemented client-side session persistence using `localStorage.getItem` and `localStorage.setItem` scoped by `siteId`.
- **First Visit:** Widget calls `POST /api/v1/session/init`, receives new `sessionId`, and saves it under `chatbot_session_${siteId}`.
- **Page Reload:** Widget retrieves stored `sessionId` from `localStorage` and reuses it without making unnecessary backend `/session/init` API calls.
- **Error Handling:** Wrapped `localStorage` in `try...catch` helpers to gracefully handle restricted browser privacy modes.

---

## 2. 5 Key Interview Q&As

#### Q1: Why is `localStorage` used for session persistence instead of `sessionStorage`?
**Answer:** `sessionStorage` expires as soon as the browser tab is closed. `localStorage` persists across tab closures and page reloads, ensuring the visitor maintains their active conversation thread.

#### Q2: Why is the `localStorage` key formatted as `chatbot_session_${siteId}`?
**Answer:** Scoping the key by `siteId` guarantees multi-tenant isolation, preventing different websites on the same origin from overwriting each other's session IDs.

#### Q3: What happens on page reload when a stored session exists?
**Answer:** The widget reads the stored `sessionId` from `localStorage`, sets `currentSessionId`, logs `"Widget session restored from localStorage"`, and skips calling `/api/v1/session/init`.

#### Q4: What happens if `localStorage` is disabled or blocked in the user's browser?
**Answer:** The `try...catch` wrapper logs a warning and falls back to storing `sessionId` in JavaScript runtime memory, ensuring the page never crashes.

#### Q5: Did M1.8 require any backend code changes?
**Answer:** No. M1.8 is purely client-side persistence logic in `widget/src/widget.js`. All 10 backend pytest unit tests pass without modification.