3.8 Saving and Loading Data

Step 1 — Run the conversion: JSON.stringify accepts any JSON-compatible value, and arrays are one of them.

$$\texttt{JSON.stringify([1, 2, 3])} \rightarrow \texttt{"[1,2,3]"}$$

Step 2 — Check the type: The result is always a string, whatever the input was. typeof on the result gives "string".

Answer: It produces the string "[1,2,3]", whose type is string. Arrays convert just like objects do.

Step 1 — Parse the string: JSON.parse('{"n": 5}') builds a real object { n: 5 }, where n is the number 5.

Step 2 — Do the arithmetic: Since v.n is a number, v.n + 1 is numeric addition:

$$5 + 1 = 6$$

Step 3 — Why not "51": String concatenation would only happen if n had come back as the string "5" (e.g. if the JSON contained "n": "5"). Parsing restores numbers as numbers, so + adds instead of joining.

Answer: v.n + 1 is 6. It is not "51" because JSON.parse converts the number in the JSON into an actual JavaScript number, so + performs addition rather than concatenation.

Step 1 — Consider what each function receives: JSON.stringify always starts from a real JavaScript value you already have in memory, so there is nothing about it to be invalid. (It is not literally incapable of failing — an object that contains itself makes it throw — but that is a shape you built yourself, not text handed to you from outside.)

Step 2 — Consider what parse receives: JSON.parse starts from text, often text loaded from storage, a file, or a network that you did not write at the same moment. That text can be truncated, hand-edited, written by an older version of your program, or simply garbage.

Step 3 — What happens on bad input: JSON.parse throws a SyntaxError when the text is not valid JSON. Without a try...catch, that error stops the program; with one, you can fall back to defaults and keep running.

Answer: Because stringify starts from a valid JavaScript value while parse starts from text that may be malformed — and malformed text makes parse throw, so the call must be wrapped in try...catch to recover gracefully.

Step 1 — Recall what storage holds: localStorage holds strings only. Saving the number 5 converts it to the string "5" on the way in.

Step 2 — Evaluate the expression: So localStorage.getItem("count") returns "5", and:

$$\texttt{"5" + 1} = \texttt{"51"}$$

The + joins two strings instead of adding two numbers.

Step 3 — Fix it: Convert the retrieved value back to a number before doing arithmetic:

Number(localStorage.getItem("count")) + 1   // 6

Answer: It gives the string "51". Fix it by wrapping the read in Number(...) (or parseInt) so the addition happens numerically: Number(localStorage.getItem("count")) + 1 gives 6.

Step 1 — Identify the return value: A key that was never saved gives back null — not undefined, and not an empty string.

Step 2 — Why a load function must test for it: On a first run, nothing has been saved yet, so every read returns null. If the load function passes that straight to JSON.parse, note that JSON.parse(null) does not throw — it quietly returns null — so the missing-data case would slip through unnoticed and downstream code would crash trying to use null as an object.

Step 3 — The correct pattern: Test explicitly before parsing:

const text = localStorage.getItem("settings");
if (text === null) {
  return defaults;
}

Answer: It returns null. A load function must test for null first because a missing key means "nothing saved yet," and skipping the test lets null flow silently through parsing into code that expects a real object.

Step 1 — Recall the sandbox rule: A web page runs JavaScript written by someone else — a stranger's server sends code to your computer every time you visit. If that code could open any file by name, merely visiting a page would expose your documents to whoever wrote the page.

Step 2 — What the browser allows instead: The browser gives a page no filesystem access at all. It gets its own isolated storage (like localStorage, kept separate per site), plus two doors that require a person's action: a file the user picks through a file-chooser dialog, or a download the user chooses to save.

Answer: Because any page could then read your files just because you visited it. The browser deliberately provides no filesystem access so that visiting a page is safe; reading a local file requires the user to choose it.

Step 1 — Explain what it means: [object Object] is the default string form of any object in JavaScript. Seeing it means somewhere an object was turned into text the lazy way — e.g. by concatenating it ("" + obj) or interpolating it into a template string — instead of being converted properly.

Step 2 — Why it signals data loss: The label carries none of the object's properties. There is no way back from [object Object]; the name, values, and nested structure are all gone.

Step 3 — What should have been written instead: Use JSON.stringify(obj) to produce a faithful text version that keeps every property and can be restored later with JSON.parse.

Answer: [object Object] means an object was converted to text without JSON.stringify, destroying all its data. The fix is JSON.stringify(obj), which preserves the structure as readable, restorable JSON.

Step 1 — Build the object: Create an object with a title (string), a number, and an array of two tags.

const book = {
  title: "Eloquent JavaScript",
  pages: 472,
  tags: ["programming", "javascript"]
};

Step 2 — Print compact JSON: Call stringify with no extra arguments — compact output is smaller and meant for programs.

console.log(JSON.stringify(book));

{"title":"Eloquent JavaScript","pages":472,"tags":["programming","javascript"]}

Step 3 — Print indented JSON: Pass null (the unused filter) and 2 (indent width) for human-readable output.

console.log(JSON.stringify(book, null, 2));

{
  "title": "Eloquent JavaScript",
  "pages": 472,
  "tags": [
    "programming",
    "javascript"
  ]
}

Answer: Compact: {"title":"Eloquent JavaScript","pages":472,"tags":["programming","javascript"]}. Indented: the same object printed across multiple lines with two-space indentation via JSON.stringify(book, null, 2).

Step 1 — Parse the string: Convert the JSON text into a usable object.

const data = JSON.parse(json);

Step 2 — Navigate the nesting: data.items is an array of objects inside the object (Section 3.5.4 nesting). The second item is index 1, so its price is data.items[1].price.

Step 3 — Add 10 and print: The parsed price is a real number, so addition works directly.

console.log(data.items[1].price + 10);   // 15
console.log(data.items[1].name);         // Pad

Answer: data.items[1].price + 10 prints 15 (the second item, "Pad", has price 5).

Step 1 — Wrap the parse in try...catch: Attempt the parse; if the text is invalid, JSON.parse throws a SyntaxError which the catch block intercepts.

function safeParse(text) {
  try {
    return JSON.parse(text);
  } catch (err) {
    return "unreadable";
  }
}

Step 2 — Test both paths: Valid JSON parses normally; garbage triggers the catch and returns the fallback string.

console.log(safeParse('{"ok":true}'));   // {"ok":true}
console.log(safeParse("{oops"));         // unreadable

Answer:

function safeParse(text) {
  try {
    return JSON.parse(text);
  } catch (err) {
    return "unreadable";
  }
}

It returns the parsed value for valid JSON and the string "unreadable" otherwise.

Step 1 — State what happens: The method is dropped silently. JSON has no way to represent a function, so JSON.stringify simply omits it — no error, no warning.

const counter = { count: 5, describe: function () { return "..."; } };
JSON.stringify(counter);   // {"count":5}

Step 2 — Explain why it is not a bug: JSON stores data, not behaviour. A method is a property whose value is a function, and functions are exactly the thing JSON was never able to carry. When you save an object and load it back without its methods, nothing went wrong — you saved the data, which is all JSON can represent. (In practice, methods are reattached by defining them on the object's shape after loading.)

Answer: The method vanishes from the JSON output, dropped silently along with undefined values. This is not a bug because JSON represents data only — functions are behaviour, and behaviour is expected to be rebuilt by the program after loading.

Step 1 — Recall what spread copies: { ...obj } creates a new object but copies only the top-level properties. A property holding a nested object still points at the same inner object shared with the original.

Step 2 — Trace the difference: With obj = { size: { width: 10 } }, changing shallowCopy.size.width also changes obj.size.width, because both .size properties reference one object.

Step 3 — What the round trip does: JSON.parse(JSON.stringify(obj)) serializes everything to text and rebuilds it from scratch, so even the nested object is brand-new and completely independent — a deep copy.

const original = { size: { width: 10, height: 4 } };
const copy = JSON.parse(JSON.stringify(original));
copy.size.width = 999;
console.log(original.size.width);   // 10 — unaffected

Answer: { ...obj } is a shallow copy: the nested object is shared with the original, so changes through either name affect both. The stringify/parse round trip rebuilds every level from text, producing a fully independent deep copy.

Step 1 — Write saveSettings: Stringify the settings object and store it under a key. Storage holds strings, so the object must be converted to JSON text first.

function saveSettings(settings) {
  localStorage.setItem("settings", JSON.stringify(settings));
}

Step 2 — Write loadSettings with three checks: First, is anything stored? (getItem returns null if not.) Second, can it be read? (try...catch around the parse.) Third, what to use if either answer is no? (the defaults.)

const defaults = { theme: "light", fontSize: 14 };

function loadSettings() {
  const text = localStorage.getItem("settings");
  if (text === null) {
    return defaults;
  }
  try {
    return JSON.parse(text);
  } catch (err) {
    return defaults;
  }
}

Step 3 — Verify both failure paths: No key saved → returns defaults; corrupt text like "{ not json" throws inside the try → catch returns defaults. Good text → parsed object comes back.

Answer:

function saveSettings(settings) {
  localStorage.setItem("settings", JSON.stringify(settings));
}

function loadSettings() {
  const text = localStorage.getItem("settings");
  if (text === null) return defaults;
  try {
    return JSON.parse(text);
  } catch (err) {
    return defaults;
  }
}

It handles all three cases: nothing stored, corrupt text, and valid data.

Step 1 — Pick data worth saving: A player's progress — current level, score, or position. Losing it would mean the player restarts from scratch every time they close the page, which defeats the purpose of playing across sessions.

Step 2 — Pick data not worth saving: Transient state such as the positions of enemies mid-animation, particles currently on screen, or the contents of a menu that is open right now. This state is regenerated fresh each run and saving it could even restore the game into an inconsistent state.

Answer: Worth saving: the player's high score or level progress, because it must survive between sessions to have meaning. Not worth saving: transient per-frame state like particle positions, because it is recreated every run and persisting it adds complexity with no benefit.