feat(narratives): PR 2 - print optimization, naming standardizations,…

[ddebasmita-lab]

Overview

Second PR for the narratives Data Agent UI. PR 1 (#363) landed the shell —
routing, branding, and the streaming scaffold. This PR builds the actual chat
experience on top of it: multi-session conversations, real chart rendering via
Data Commons web components, a config-driven Key Metrics dashboard, and
single-answer print/PDF export. It also folds in the code-review feedback from
this PR's own earlier rounds (naming standardizations and print hardening).

Scope is the narratives/ frontend only (TypeScript + React 19 + Vite +
Tailwind v4). ~42 files, no backend changes.

Background / motivation

PR 1 rendered a single ephemeral conversation with placeholder charts. To make
the Data Agent usable we needed: conversations that survive navigation and
refresh; charts that show correct per-place data with real source attribution;
a metrics landing page an instance owner can configure without code; and a way
to export an answer for sharing. Each of those is one section below.

Changes made

Multi-session chat (persisted). Conversations are stored in localStorage
and exposed through a context provider, so turns survive SPA navigation and
browser refresh. A session drawer lists past chats with new/switch/delete;
empty "New chat" drafts are collapsed so the list stays tidy. Desktop shows a
left-rail list; mobile uses a two-level slide-in panel.
Files: hooks/chat_session_context.tsx, components/drawer_session.tsx,
components/sidebar.tsx.

Data Commons web-component charts. Replaced the custom Recharts layer with
official <datacommons-*> components, wrapped by DataCommonsComponent. Each
component owns its own data fetch, source caption, "About this data" / "API
code" footer, and metadata modal, wired to the actual DCIDs the agent returned.
This fixes the prior bug where charts with missing placeDcids defaulted to
country/USA.
Files: utils/datacommons_component.tsx, components/tile_chart.tsx.

Config-driven Key Metrics dashboard. The metrics page renders tiles from a
metrics config rather than hardcoded charts, so an instance can re-skin it
without touching components.
Files: components/metrics_page.tsx, types/metrics.ts.

Print / PDF export. Export one Q&A panel via a scoped @media print
strategy that hides everything outside the selected subtree. Hardened against
detached targets and concurrent print runs, with cleanup in finally.
Files: utils/print_element.ts, components/button_export_pdf.tsx, index.css.

Streaming, follow-ups, citations. SSE streaming with a stop control and a
single-stream guard (no concurrent connections), agent follow-up questions, and
inline [N] citation chips.
Files: hooks/use_sse_chat.ts, components/data_agent.tsx,
components/questions_follow_up.tsx, components/chip_citation.tsx.

[gemini-code-assist]

Code Review

This pull request adds multi-session chat management with localStorage persistence, integrates official Data Commons web components via a new <DC> wrapper, and updates the Key Metrics dashboard to be config-driven. Key feedback includes resolving case-sensitive import paths for Icons.tsx to prevent compilation failures on Linux, guarding the SSE send function against concurrent streaming invocations, and refactoring the <DC> component to use document.createElement instead of innerHTML to preserve camelCase attributes. Finally, TypeScript's strict mode should be re-enabled in tsconfig.json to maintain type safety.

[juliawu]

Thanks for the new additions! I see a lot of refactoring, especially in making changes compatible with the updates made in the last PR -- great job! I left some comments that should be quick fixes.

Could you also fill out the PR description? It'll be really helpful down the line to have that context.

[nick-nlb]

Thank you Debasmita! A few comments added in below.

[nick-nlb]

Here we are explicitly setting the size of the icon directly in the consuming component. This is a magic number, and will have the effect of making standardizing (and adjusting) the icons difficult.

There are some different options for handling this, but I would lean towards having size be of type "sm" | "md" | "lg", and having the pixel size of these defined on the theme level (with "md" being 22, "lg" 24 for example.

[ddebasmita-lab]

will cover this and the color tokens in the next PR

[nick-nlb]

I've noticed that there are a substantial number of hard-coded color references in the app (bg-white, border-gray-200). These should all be derived from the theme.

This might be a sizable job in itself, and can be set aside for a subsequent PR, but can we make sure we have the task lined up to make sure that all items that might reasonably vary from theme-to-theme be derived from theme tokens rather than being hard-coded?

[nick-nlb]

Following up on that previous comment about icon sizing:

We could requisition this size prop to standardize the sizing across the application (i.e. have it take "sm", "md", "lg").

We could make this easier here by having a non-exported base Icon component that takes the size, looks up the pixel value that represents in the theme, and uses that pixel value.

The other components would then wrap this new base Icon component.

Another thing we could do, to make these components as flexible as possible, is to have them take SVG props and spread them in (something we do in base DC - although we could do it a bit differently here).

We could use a hook to handle the conversion of common props (like size) into something the icon would understand:

// Ultimately we would want these to come right out of the theme (in the branding context?)
const ICON_SIZES = {
  sm: 20,
  md: 22,
  lg: 24,
} as const;

export type IconSizeToken = keyof typeof ICON_SIZES;

export interface IconProps extends SVGProps<SVGSVGElement> {
  size?: IconSizeToken;
}
export function getSvgProps(size: IconSizeToken = "md", props: SVGProps<SVGSVGElement> = {}) {
  const dimension = ICON_SIZES[size];
  return {
    width: dimension,
    height: dimension,
    fill: "currentColor",
    "aria-hidden": true,
    ...props,
    className: `shrink-0 select-none ${props.className ?? ""}`.trim(),
  };
}

And then one of the actual icons:

export function SomeIcon({ size = "lg", ...props }: IconProps) {
  return (
    <svg
      viewBox="0 -960 960 960"
      {...getSvgProps(size, props)}
    >
      <path d="..."/>
    </svg>
  );
}

I played around and tested with the above and it seems to work, but haven't fully vetted it. Feel use any of this.

[ddebasmita-lab]

Will be addressed in the next PR

[nick-nlb]

These should be rolled out into the Icons library.

But importantly as we do that, the icons should not be responsible for their rotation - i.e., ChevronDown is not a special case of "an icon that can be rotated". Any icon should be rotatable (and that would be controlled from outside of the icon).

Once we have moved our icons to accept SVG props (see the earlier comments), we will be in a position to do that, where we could rotate the icon with something like:

<ChevronDownIcon 
  className={`transition-transform duration-150 ${open ? "rotate-0" : "-rotate-90"}`} 
/>

[ddebasmita-lab]

will be addressed in next PR

[nick-nlb]

This should also be rolled into the icon library. While doing that - since this is Material icon from the same set as the other icons, it could be updated to have the same viewbox (and of course, with the paths updated to fit).

[ddebasmita-lab]

will be covered in next PR

[nick-nlb]

Thank you for all the updates Debasmita (and noting the deferrals to a subsequent PR for some of the changes - I think that's a good idea in the interest of keeping the PRs small where possible).