fix(ui): spin Code indicator during in-code streaming (#220)

[charliecreates]

Restore the spinning state of the Code indicator while an AI response is actively streaming inside a code segment.

Context

Regression: the Code icon stopped spinning during streaming, even when the stream was currently producing code. Prior logic tied the loading state to overall streaming/code presence rather than whether the active stream position was inside a code fence.

Changes

• Detect "streaming inside code" from the current AI message text by counting unpaired triple-backtick fences and derive a boolean.
• Override the code control's loading flag in the header based on that boolean so the Code icon spins only while the stream is inside code.
• Keep all other controls/behaviors unchanged.
• Tests: add integration-style tests that simulate streaming with code blocks (single and multiple segments) and assert the indicator spins.

Impact

• Code icon now spins while streaming in-code and stops otherwise (aligned with the original UX expectation of Issue code indicator should spin when ai response is streaming and in a code segment #220).
• No changes to data, preview, or settings controls.

Verification

pnpm check
# format: ok
# typecheck: ok
# tests: 66 files, 364 passed, 4 skipped

Closes #220

[netlify]

✅ Deploy Preview for fireproof-ai-builder ready!

Name	Link
🔨 Latest commit	b98e6c6
🔍 Latest deploy log	https://app.netlify.com/projects/fireproof-ai-builder/deploys/689a6c9f9bd15700080ad131
😎 Deploy Preview	https://deploy-preview-221--fireproof-ai-builder.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[charliecreates]

• Overriding viewControls.code with a fabricated fallback may unintentionally enable the Code control and alter its appearance when it was meant to be absent/disabled.
• Tests dynamically re-mock dependencies without resetting the module cache, which can cause mocks to be ignored on subsequent imports and produce brittle results.
• Consider adding a negative test to ensure the indicator stops spinning when the trailing code fence is closed (or when streaming stops) to fully lock in intended behavior.

Additional notes (1)

• Maintainability | tests/code-indicator-streaming.test.tsx:157-210
  Test coverage only verifies the positive case (spins inside an open code fence). Consider adding a negative case to lock in behavior when the last fence is closed (or when isStreaming is false), ensuring the indicator does not spin.

Summary of changes

• Added useMemo-based detection of whether the active AI stream is currently inside a Markdown code fence by counting occurrences of triple backticks in selectedResponseDoc.text and checking parity.
• Introduced adjustedViewControls that overrides only the code control's loading state based on the new in-code detection, and wired it into the header via ResultPreviewHeaderContent.
• Created new integration-style tests (tests/code-indicator-streaming.test.tsx) that mock the UI shell and simulate streaming with single and multiple code blocks to assert that the Code indicator spins when the trailing code fence is open.
• Minor import change: added useMemo in home.tsx imports.

[charliecreates]

Creating a fallback code control when viewControls.code is falsy risks enabling the Code control in contexts where it was intentionally absent/disabled, and may also introduce an unexpected icon/label. To keep behavior identical outside of the streaming-in-code override, only modify the code control when it already exists and otherwise return viewControls unchanged.

Suggestion

Replace the adjustedViewControls block with a guard that only overrides when viewControls.code is present:

const adjustedViewControls = useMemo(() => {
  const code = viewControls.code;
  if (!code) return viewControls; // preserve absence/disabled state
  return {
    ...viewControls,
    code: {
      ...code,
      loading: isStreamingInCode,
    },
  };
}, [viewControls, isStreamingInCode]);

Reply with "@CharlieHelps yes please" if you'd like me to add a commit with this change.

[charliecreates]

Each test re-mocks useSimpleChat and then dynamically imports the module under test, but the module cache is never reset. This can cause the second test to reuse the previously cached ../app/routes/home module and ignore the updated mock, leading to brittle results dependent on import order. Reset the module graph between tests to ensure vi.doMock takes effect for each import.

Suggestion

Reset modules and clear mocks in beforeEach to ensure fresh imports per test:

beforeEach(() => {
  vi.resetModules();
  vi.clearAllMocks();
});

Alternatively, call vi.resetModules() immediately before each dynamic import('../app/routes/home').

Reply with "@CharlieHelps yes please" if you'd like me to add a commit with this change.