Load conversation dashboard apps

[juliomuhlbauer]

What changed

• Load conversation dashboard apps in Chat.tsx using useDashboardApps({ displayType: 'conversation' }).
• Extend useDashboardApps to support sidebar, conversation, and all, with per-type caches.
• Add a regression test that verifies conversation apps reach ChatTabs.
• Add a test setup fallback for localStorage / sessionStorage in Vitest.

Why

• The chat page was keeping dashboardApps as an empty local array, so ChatTabs never received conversation apps.

Validation

• npm test -- src/pages/Customer/Chat/__tests__/Chat.spec.tsx
• npm test -- src/components/layout/MainLayout.spec.tsx
• npm run build

Summary by Sourcery

Load conversation-specific dashboard apps in the chat page using the shared dashboard apps hook and ensure they reach the chat tabs while improving test environment storage support.

New Features:

• Support multiple dashboard app display types (sidebar, conversation, all) in the shared dashboard apps hook with per-type caching.
• Load conversation dashboard apps in the customer chat page and pass them into the chat tabs component.

Enhancements:

• Refine dashboard apps loading logic to filter apps by display type and cache results separately per type for reuse.

Tests:

• Add a chat page test to assert that conversation dashboard apps are passed down into the ChatTabs component.
• Extend the Vitest setup with in-memory localStorage and sessionStorage fallbacks for environments lacking native implementations.

[sourcery-ai]

Reviewer's Guide

Loads conversation-specific dashboard apps into the Chat page via an extended useDashboardApps hook that now supports per-display-type caching, adds a Vitest memory-backed Web Storage fallback, and introduces a test ensuring conversation apps are passed through to ChatTabs.

Sequence diagram for loading conversation dashboard apps into ChatTabs

sequenceDiagram
  actor User
  participant Chat
  participant useDashboardApps
  participant integrationsService
  participant ChatTabs

  User->>Chat: open Chat page
  Chat->>useDashboardApps: useDashboardApps(displayType='conversation')
  activate useDashboardApps
  useDashboardApps->>useDashboardApps: loadApps()
  alt [no cached apps and no existing promise]
    useDashboardApps->>integrationsService: getDashboardApps()
    activate integrationsService
    integrationsService-->>useDashboardApps: DashboardAppsResponse
    deactivate integrationsService
    useDashboardApps->>useDashboardApps: filterDashboardApps(data,'conversation')
    useDashboardApps->>useDashboardApps: cache apps by 'conversation'
  else [apps cached or promise in progress]
    useDashboardApps->>useDashboardApps: reuse cached data/promise
  end
  useDashboardApps-->>Chat: apps (conversation)
  deactivate useDashboardApps
  Chat->>ChatTabs: render ChatTabs(dashboardApps=apps)

Loading

File-Level Changes

Change	Details	Files
Extend useDashboardApps to support displayType filtering and per-type caching.	Introduce DashboardAppsDisplayType union and displayType option with default of 'sidebar'. Replace single global cache and promise with Maps keyed by display type, pre-seeded for sidebar, conversation, and all. Add filterDashboardApps helper to filter by display_type or return all apps, and apply it both when awaiting existing promises and new requests. Wire hook state initialization and loadApps logic to read/write from the per-type caches and promises, and depend on displayType in the loadApps callback.	src/hooks/useDashboardApps.ts
Provide in-memory localStorage and sessionStorage fallbacks for the Vitest environment.	Implement createMemoryStorage utility that mimics the Storage interface using a Map and exposes required methods and length/key support. Conditionally define globalThis.localStorage and globalThis.sessionStorage via Object.defineProperty when missing or lacking getItem/setItem.	src/test/setup.ts
Load conversation dashboard apps into Chat and verify they reach ChatTabs.	Replace the Chat component's local dashboardApps state with useDashboardApps configured for displayType 'conversation'. Enhance Chat tests to mock useDashboardApps with a conversation-type app, capture ChatTabs props, and assert that conversation dashboard apps are passed through. Reset captured ChatTabs dashboardApps between tests to avoid cross-test contamination.	src/pages/Customer/Chat/Chat.tsx src/pages/Customer/Chat/__tests__/Chat.spec.tsx

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sourcery-ai]

Sorry @juliomuhlbauer, you have reached your weekly rate limit of 500000 diff characters.

Please try again later or upgrade to continue using Sourcery

[sourcery-ai]

Hey - I've found 1 issue

Prompt for AI Agents

Please address the comments from this code review:

## Individual Comments

### Comment 1
<location path="src/hooks/useDashboardApps.ts" line_range="6-9" />
<code_context>
 import { DashboardApp } from '@/types/integrations';
+import type { DashboardAppsResponse } from '@/types/integrations';
+
+type DashboardAppsDisplayType = 'sidebar' | 'conversation' | 'all';

 interface UseDashboardAppsOptions {
</code_context>
<issue_to_address>
**question:** Clarify whether caching per displayType is intentional given a single backend call.

Right now the hook creates separate cache entries per `displayType`, but `integrationsService.getDashboardApps()` seems to always return all apps. That means a `sidebar` call and a later `conversation` call will each hit the network. If the backend indeed always returns the full list, consider caching that single raw response once and deriving per-`displayType` views in memory to avoid redundant requests.
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[sourcery-ai]

question: Clarify whether caching per displayType is intentional given a single backend call.

Right now the hook creates separate cache entries per displayType, but integrationsService.getDashboardApps() seems to always return all apps. That means a sidebar call and a later conversation call will each hit the network. If the backend indeed always returns the full list, consider caching that single raw response once and deriving per-displayType views in memory to avoid redundant requests.