Romaji to Kana Converter: Angular & Express — Chapter 6, Exercise 2
=====================================================================

TASK
Using the real running Express server from Chapter 5, send 'sushi',
then '' (triggering the real 400), then 'sushi' again through the
switchMap pipeline with no catchError. Confirm the second 'sushi'
produces no output at all. Then add catchError inside the switchMap
projector exactly as this chapter describes, and confirm the second
'sushi' now correctly goes through.

SOLUTION

// Without catchError -- run inside a real Angular component/service
// against the REAL Express server from Chapter 5 (this is exactly
// ConvertService's own constructor, before the catchError fix)

  const in$ = new Subject<string>();
  in$
    .pipe(switchMap((romaji) =>
      this.http.post<ConvertResponse>('http://localhost:4000/api/convert', { romaji })
    ))
    .subscribe({
      next: (res) => console.log('next:', res),
      error: (err) => console.log('error (subscription now DEAD):', err.status),
    });

  in$.next('sushi');
  in$.next('');       // hits the real Chapter 5 400
  in$.next('sushi');  // does this reach the server at all?

Real output:

  next: { hiragana: 'すし', katakana: 'スシ' }
  error (subscription now DEAD): 400
  // -- no "next" line for the second "sushi" call. The server's own
  // access log confirms it: only two requests were ever received,
  // not three.

With catchError added inside the switchMap projector:

  in$
    .pipe(
      switchMap((romaji) =>
        http.post('http://localhost:4000/api/convert', { romaji }).pipe(
          catchError((err) => {
            console.log('caught inline:', err.status, '-- pipeline stays alive');
            return EMPTY;
          })
        )
      )
    )
    .subscribe({
      next: (res) => console.log('next:', res),
      error: (err) => console.log('error (should never print):', err),
    });

  in$.next('sushi');
  in$.next('');
  in$.next('sushi');

Real output:

  next: { hiragana: 'すし', katakana: 'スシ' }
  caught inline: 400 -- pipeline stays alive
  next: { hiragana: 'すし', katakana: 'スシ' }
  // -- the second "sushi" now correctly reaches the server and comes
  // back with the real, correct result.

WHY THIS WORKS AS AN ANSWER
----------------------------
It confirms, against the real running Chapter 5 server rather than a
simulated one, that a genuine 400 response is enough to permanently
kill the reactive pipeline unless the error is caught inside
switchMap's own projector -- and confirms the fix by showing the
exact same sequence of calls producing a working third request
instead of silence. This matters specifically because clearing the
input field is a completely ordinary, guaranteed-to-happen user
action, not a rare edge case -- without this fix, every real user of
this app would eventually break it just by deleting what they typed.