Task 1 · Add：提交表单，新笔记进入表格Task 1 · Add: submit the form and the new note appears in the table

“Submit the form → the new note enters the table”. Split open, that is three things:

1. The user fills in both inputs and clicks Add.
2. A complete Note comes into being, with a unique id.
3. That note shows up in the table, and everything already there stays.

The second one is already done by NoteForm (you read it in the previous module). So the only thing left for you is the third.

On the surface it is “append one item to an array”. What it really tests is three things:

• Whether you know where the data belongs. notes lives in NoteManager, not NoteForm.
• Whether you can do an immutable update.push makes the array longer, but the screen never moves.
• Whether you can follow props to the call chain. Where NoteForm’s onSubmit prop comes from, and what gets passed into it.

handleSubmit (over in NoteForm) does a handful of things, and step 3 is where the note gets built:

Look at id: noteToEdit ? noteToEdit.id : Date.now(): when adding, noteToEdit is null, so it takes Date.now() — the current millisecond timestamp, unique enough for an id (you would have to click twice inside one millisecond to collide, which you cannot).

And .trim(): the surrounding spaces are gone. So what reaches NoteManager is always clean data — you do not have to validate it again.

Then onSubmit(newNote) hands it off. That onSubmit comes from props, and what NoteManager passes in is exactly handleSubmitNote:

The answer to question 3, “everything old stays, one more at the end”, turns straight into [...prev, submittedNote]. Spread lays out every element of the old array, and the new one goes after them.

Step one: think about adding only, ignore editing. (Editing belongs to Task 3. Pretend it does not exist yet.)

Step two: switch to the functional update.setNotes([...notes, submittedNote]) passes the tests too, but the project uses the prev form throughout. The reason came up in the previous module: back-to-back calls never read a stale value.

Step three: leave room for editing. Task 3 adds a branch inside this same function. So the final shape is if (noteToEdit) {...} else { add }. For now write only the else half.

Read that one line piece by piece — setNotes((prev) => [...prev, submittedNote]):

• setNotes(...) — the only legal way to change it. Calling it means telling React “the value changed, please re-render”.
• (prev) => ... — the functional update. React hands you the newest notes at this moment as prev.
• [...prev, submittedNote] — a brand new array. The old items are laid out one by one and the new one is attached at the end. Because it is a new array, React can see the change.

After that it is the flow from the diagram in the previous module: state updates → NoteManager runs again → notes has one more item → NoteTable receives the new array → notes.map(...) produces one more NoteItem → React diffs and inserts one <tr> into the DOM.

userEvent.type types like a real person (one character at a time, each firing onChange), and userEvent.click clicks. The last line asserts that the text content of the notes-list element contains My Title.

Notice how loose this test is: it only checks that the text showed up. So even if you put the new note at the front ([submittedNote, ...prev]), it still passes. But the brief says “enters the table”, which normally means appending to the end — and the real answer does append. A loose test is no excuse for a sloppy answer.