• pnpm-lock.yaml: Language not supported

apps/sqlrooms-cli-ui/src/createDashboardCommands.ts (1)

109-118: ⚠️ Potential issue | 🟠 Major

createDashboardCreateSheetCommand.execute still doesn't select the new sheet.

The description says "Create a new dashboard sheet and select it", but execute only calls createDashboardSheet(title) and never sets the newly created sheet as current. The generic createSheetCommand helper above (line 80) correctly calls getState().cells.setCurrentSheet(sheetId) — mirror that here so the dashboard command matches its contract and is consistent with the other create commands.

🔧 Suggested fix

     execute: ({getState}, input) => {
       const {title} = (input as CreateSheetCommandInput | undefined) ?? {};
       const sheetId = getState().dashboard.createDashboardSheet(title);
+      getState().cells.setCurrentSheet(sheetId);
       return {
         success: true,
         commandId: 'dashboard.create-sheet',
         message: `Created dashboard sheet "${sheetId}".`,
         data: {sheetId},
       };
     },

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/sqlrooms-cli-ui/src/createDashboardCommands.ts` around lines 109 - 118,
The execute implementation in createDashboardCommands (the execute function that
calls getState().dashboard.createDashboardSheet(title)) creates a sheet but
doesn't select it; update this execute to call
getState().cells.setCurrentSheet(sheetId) after obtaining sheetId (mirror the
behavior from the generic createSheetCommand helper) so the new dashboard sheet
is set as the current sheet before returning the success response.

examples/mosaic/src/components/DataSourcesPanel.tsx (1)

59-61: Remove commented-out AddDataModal block.

Dead/commented code adds noise; drop it or convert to a TODO with a tracked issue if the modal is still planned.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@examples/mosaic/src/components/DataSourcesPanel.tsx` around lines 59 - 61,
Remove the commented-out AddDataModal block to eliminate dead code: delete the
commented JSX lines referencing AddDataModal, isOpen, and handleModalClose in
DataSourcesPanel.tsx; if the modal is still intended to be implemented later,
replace the commented block with a concise TODO comment referencing a tracking
issue (e.g., "TODO: implement AddDataModal - see ISSUE-###") so intent is
preserved without leftover commented JSX.

examples/canvas/src/components/DataSourcesPanel.tsx (1)

7-9: Align with codebase convention by using type-only import for FC.

The repository consistently uses import type for type-only imports throughout the codebase. Change to import type {FC} to maintain consistency.

♻️ Proposed fix

-import {FC} from 'react';
+import type {FC} from 'react';

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@examples/canvas/src/components/DataSourcesPanel.tsx` around lines 7 - 9, The
import of React's FC should be a type-only import to match repo conventions;
change the top import to use a type-only import (e.g., import type { FC } from
'react') and ensure the component declaration DataSourcesPanel: FC remains
unchanged so only type information is imported.

packages/ui/src/components/tab-strip.tsx (1)

136-141: TAB_STRIP_BUTTON_CLASSNAMES mixes sizing/padding classes into surfaces that also pass size="icon".

TAB_STRIP_BUTTON_CLASSNAMES bakes in px-6 py-1 and min-h-7, and is applied to:

• the TabsTrigger (a text tab — expected),
• the search dropdown trigger which is a Button size="icon" (line 586),
• TabStripButton which is also Button size="icon" (line 765).

For the two icon buttons, the shared classes override size="icon"'s own padding/size via tailwind-merge, which works but couples all three surfaces to a single shape. If the text-tab padding (px-6) is ever tuned, the icon buttons silently change too.

Consider splitting this into two groups — a focus/hover ring set shared by all, and a padding/sizing set applied only to the tab trigger — so the icon-button surfaces stop paying for text-tab padding. Not blocking.

Also applies to: 194-203, 581-592, 762-775

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/ui/src/components/tab-strip.tsx` around lines 136 - 141,
TAB_STRIP_BUTTON_CLASSNAMES currently mixes focus/hover ring classes with
sizing/padding (px-6 py-1, min-h-7) which overrides Button size="icon"; split
this constant into two: e.g. TAB_STRIP_SURFACE_CLASSNAMES (shared
focus/hover/ring/overflow classes) and TAB_STRIP_TEXT_PADDING_CLASSNAMES
(padding/min-height for text tabs), then update uses so TabsTrigger and the text
tab composition include both arrays but the search dropdown trigger and
TabStripButton (Button size="icon") only receive TAB_STRIP_SURFACE_CLASSNAMES so
their intrinsic size/padding from size="icon" is preserved.

examples/get-started/src/components/MainView.tsx (1)

10-12: Use import type for FC since it's only used as a type.

FC is only used as a TypeScript type annotation and is never referenced at runtime. Using import type clarifies intent and prevents accidental runtime references.

Proposed fix

-import {FC} from 'react';
+import type {FC} from 'react';

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@examples/get-started/src/components/MainView.tsx` around lines 10 - 12,
Change the runtime import of FC to a type-only import: replace the current
import of FC with a type import (use "import type { FC } from 'react';") so FC
is erased at runtime; keep the component declaration export const MainView: FC =
() => { ... } unchanged. This ensures FC is only used as a TypeScript type and
prevents accidental runtime references.

examples/cosmos-embedding/src/components/DataSourcesPanel.tsx (1)

83-85: Remove the commented-out AddDataModal block.

Stale debug/dead code; either restore it as a tracked TODO with context or drop it to keep the example clean.

🧹 Proposed cleanup

-      {/* {AddDataModal ? (
-        <AddDataModal isOpen={isOpen} onClose={handleModalClose} />
-      ) : null} */}
     </RoomPanel>

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@examples/cosmos-embedding/src/components/DataSourcesPanel.tsx` around lines
83 - 85, Remove the stale commented-out JSX block referencing AddDataModal (the
fragment containing "<AddDataModal isOpen={isOpen} onClose={handleModalClose}
/>") from DataSourcesPanel; either delete the commented lines entirely or, if
you want to preserve intent, replace them with a short tracked TODO comment
explaining why AddDataModal was removed and what props (isOpen,
handleModalClose) it used to require so future restoration is clear.

examples/minimal/src/room.tsx (1)

9-9: Use import type for the React FC type.

FC is used only in a type annotation. Using import type improves code clarity by explicitly marking it as a type-only dependency.

Proposed diff

-import {FC} from 'react';
+import type {FC} from 'react';

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@examples/minimal/src/room.tsx` at line 9, The import in room.tsx currently
brings in FC as a regular value import; change it to a type-only import to
reflect that FC is used only in type annotations by replacing the import of FC
with an `import type` declaration (e.g., import type { FC } from 'react') so the
symbol FC is treated as a type-only dependency and bundlers/typecheckers can
optimize accordingly; update the import statement where FC is referenced.

examples/deckgl-mosaic/src/store.ts (1)

27-28: Minor: as const on z.enum argument is redundant.

When passing an array literal directly to z.enum(...), the literal union is inferred without as const. The assertion can be dropped. Additionally, declaring the runtime const and the inferred type with the same identifier (RoomPanelTypes) is confusing at call sites — consider using RoomPanelType for the type instead.

Proposed change

-export const RoomPanelTypes = z.enum(['left', 'data', 'main'] as const);
-export type RoomPanelTypes = z.infer<typeof RoomPanelTypes>;
+export const RoomPanelTypes = z.enum(['left', 'data', 'main']);
+export type RoomPanelType = z.infer<typeof RoomPanelTypes>;

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@examples/deckgl-mosaic/src/store.ts` around lines 27 - 28, The z.enum call
uses an unnecessary "as const" and the runtime and type share the same name
which is confusing; update the declaration by removing the "as const" from the
z.enum argument (keep export const RoomPanelTypes = z.enum(['left', 'data',
'main'])) and rename the inferred type to a distinct singular name (export type
RoomPanelType = z.infer<typeof RoomPanelTypes>); also search for any usages of
the old type name RoomPanelTypes in the code and replace them with
RoomPanelType.

examples/query-motherduck/src/components/MainView.tsx (1)

22-22: Move shared token constants out of the root App module.

Line 22 makes this child component depend on ../App just to read MD_TOKEN_KEY. A neutral constants module avoids root-component coupling and circular-import surprises as the Room/MainView tree evolves.

♻️ Proposed refactor

+// examples/query-motherduck/src/constants.ts
+export const MD_TOKEN_KEY = 'motherduck-token';

 // examples/query-motherduck/src/App.tsx
 import {ThemeProvider} from '@sqlrooms/ui';
 import {FC, useEffect, useState} from 'react';
+import {MD_TOKEN_KEY} from './constants';
 import {MdConnectPane} from './components/MdConnectPane';
 import {Room} from './Room';
 
-export const MD_TOKEN_KEY = 'motherduck-token';
-
 export const App: FC = () => {

 // examples/query-motherduck/src/components/MainView.tsx
-import {MD_TOKEN_KEY} from '../App';
+import {MD_TOKEN_KEY} from '../constants';
 import {useRoomStore} from '../store';

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@examples/query-motherduck/src/components/MainView.tsx` at line 22,
MainView.tsx currently imports MD_TOKEN_KEY from ../App which couples the child
component to the root; create a neutral constants module (e.g., export
MD_TOKEN_KEY from a new module like tokenConstants or constants) and move the
MD_TOKEN_KEY definition there, then update MainView.tsx and App (and any other
consumers) to import MD_TOKEN_KEY from the new module (ensure the symbol name
MD_TOKEN_KEY is exported as-is to avoid breaking usages).

examples/query-motherduck/src/store.ts (1)

19-19: 'left' enum value is a container id, not a panel type.

RoomPanelTypes is used both as the layout node id for the tabs container (Line 51) and as keys into layout.panels (Lines 70, 73). The 'left' value is only used for the container and has no corresponding entry in panels, which conflates two different namespaces in one enum. Consider either adding a separate type for container ids, or documenting that 'left' is intentionally a container slot without a panels entry, to avoid confusion for downstream consumers who iterate RoomPanelTypes.options.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@examples/query-motherduck/src/store.ts` at line 19, RoomPanelTypes currently
mixes a container id ('left') with actual panel keys causing confusion when
iterating RoomPanelTypes.options and indexing layout.panels; split the
namespaces by creating a new enum (e.g., ContainerIds = z.enum(['left'] as
const)) and change RoomPanelTypes to only include real panel keys (e.g.,
z.enum(['data','main'] as const)), then update usages that refer to the tabs
container id to use ContainerIds (or add a clarifying comment if you
intentionally keep 'left' in the enum) and ensure code that indexes
layout.panels uses RoomPanelTypes only.

examples/query/src/components/DataPanel.tsx (1)

7-9: Use import type for type-only imports.

FC is only used in a type position here. While the repository does not currently enforce this via stricter TypeScript configs, importing type-only symbols with import type is a best practice that improves clarity and aligns with the pattern used in other packages in this repository.

♻️ Proposed fix

-import {FC} from 'react';
+import type {FC} from 'react';

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@examples/query/src/components/DataPanel.tsx` around lines 7 - 9, The import
of FC from 'react' in the DataPanel component is type-only; change the import to
a type import by replacing "import {FC} from 'react'" with a type-only import
(e.g., "import type { FC } from 'react'") so the DataPanel: FC declaration uses
a type import rather than a runtime import.

examples/pivot/src/App.tsx (1)

4-6: Make the React FC import type-only.

FC is only used as a type annotation; prefer import type to avoid issues with stricter TypeScript module emit settings.

♻️ Proposed fix

-import {FC} from 'react';
+import type {FC} from 'react';

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@examples/pivot/src/App.tsx` around lines 4 - 6, The import of the React type
FC in App.tsx is not type-only; update the import statement that brings in FC so
it is a type-only import (used by the App: FC annotation) to avoid runtime
import emission under stricter TS settings—replace the regular import of FC with
a type-only import and keep the App component signature as App: FC.

examples/pivot/src/components/DataPanel.tsx (1)

7-9: Use import type for the FC import.

FC is only used as a type annotation here. While this codebase doesn't have verbatimModuleSyntax enabled, using import type is a best practice to ensure the import is properly tree-shaken and avoid any unnecessary runtime overhead.

♻️ Proposed fix

-import {FC} from 'react';
+import type {FC} from 'react';

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@examples/pivot/src/components/DataPanel.tsx` around lines 7 - 9, The import
of FC is only used as a type; change the import statement to a type-only import
so it won't be kept at runtime. Update the top-level import from "import {FC}
from 'react';" to use "import type" for the FC symbol, leaving the DataPanel: FC
usage unchanged; ensure the symbol FC is imported via a type-only import to
allow proper tree-shaking.

packages/layout/src/docking/dock-layout.ts (1)

117-128: Gate or remove docking debug logs.

These logs run from core docking/size paths and can spam production consoles during panel rearrangement. Prefer a debug logger or remove them before release.

Also applies to: 149-164, 342-348, 434-447, 472-476, 559-574

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/layout/src/docking/dock-layout.ts` around lines 117 - 128, The
console.log in dock-layout.ts (inside equalizeChildren) and the other debug
prints at the indicated ranges should be gated or removed so production consoles
aren't spammed; replace direct console.log calls with a debug-level logger or
guard them behind a runtime/dev flag (e.g., only run when DEBUG_DOCKING or
NODE_ENV !== 'production') and keep the same structured payload (references:
equalizeChildren, getLayoutNodeId, getSizeProps) so behavior is unchanged when
enabled; do this for all instances (lines ~117-128, 149-164, 342-348, 434-447,
472-476, 559-574). Ensure no console.* calls remain unguarded in
DockLayout-related functions.

examples/layout/src/components/ResultsPanel.tsx (1)

17-32: Minor: column header/data field naming mismatch.

The header is labelled created_at (Line 17) but the row objects use date (Lines 22-26, rendered via row.date on Line 32). Since the SchemaPanel advertises a created_at: TIMESTAMP column, renaming the field to created_at would make the demo data self-consistent.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@examples/layout/src/components/ResultsPanel.tsx` around lines 17 - 32, The
table header uses created_at but the mock rows use date; update the mock data
objects and render access in ResultsPanel (the array of rows and the JSX that
reads row.date) to use created_at instead of date so the header, rendered cell
(row.created_at) and the advertised SchemaPanel column (created_at: TIMESTAMP)
are consistent.

packages/layout/src/docking/DockDragOverlay.tsx (1)

15-30: Consider clamping badge position to viewport.

Near the right/bottom edges the badge can extend past the viewport (adding BADGE_OFFSET unconditionally). Consider flipping to the opposite side or clamping against window.innerWidth/innerHeight minus the badge size when it would overflow. Low priority since it’s cosmetic.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/layout/src/docking/DockDragOverlay.tsx` around lines 15 - 30, The
badge currently places itself at cursorPosition + BADGE_OFFSET in
DockDragOverlay (used when activePanelTitle and cursorPosition exist) which can
overflow the viewport; update the positioning logic used for the createPortal
inline style to clamp or flip coordinates against
window.innerWidth/window.innerHeight so the badge stays fully visible: measure
or approximate the badge size (via a ref or known constants) and if
cursorPosition.x + BADGE_OFFSET + badgeWidth > window.innerWidth then position
it to the left of the cursor (cursorPosition.x - BADGE_OFFSET - badgeWidth) and
similarly for vertical overflow use cursorPosition.y - BADGE_OFFSET -
badgeHeight, otherwise use the original offset; ensure BADGE_OFFSET,
cursorPosition, and createPortal usage in DockDragOverlay are updated to apply
these computed left/top values.

packages/layout/src/docking/DockingProvider.tsx (1)

121-144: Cursor tracking breaks under non-pointer sensors.

handleDragMove reads event.activatorEvent.clientX/Y to seed the cursor position. Today you only register a PointerSensor, so this is safe, but any future addition of KeyboardSensor (or similar) will make hasPointerCoordinates return false and the custom drag overlay will stop following the caret. Consider driving the overlay from translatedRect.left/top + window.scrollX/Y (which is available for any sensor) so this remains sensor-agnostic. Non-blocking today.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/layout/src/docking/DockingProvider.tsx` around lines 121 - 144, In
handleDragMove, avoid relying on event.activatorEvent.clientX/Y (used only by
pointer sensors); instead compute the overlay cursor from the translatedRect
coordinates plus page scroll so it works with non-pointer sensors—use
translatedRect.left/top combined with window.scrollX/window.scrollY (or similar)
to setCursorPosition; keep the existing hasPointerCoordinates branch only for
pointer-specific offsets and fallback to using translatedRect + scroll when
activatorEvent lacks pointer coordinates, updating the logic in handleDragMove
(and leaving updatePreview/setCursorPosition calls intact).

examples/layout/src/store.tsx (1)

289-348: Minor: redundant first lookup and lossy equal-size distribution.

Two observations on addChartToDashboard:

1. Redundant findNodeById — lines 294–304 look up and validate the dock on the original config, then lines 308–316 repeat the same lookup/validation on the cloned newConfig. Since you only mutate the clone, the first pass is redundant and can be dropped.
2. Math.floor(100 / totalChildren) loses percent (line 328) — e.g., 3 children → 33 each → 99% total; 6 → 96%. Depending on how the split renderer normalizes sizes this may cause a small residual gap or truncation. Consider distributing the remainder to the first child, or simply omitting defaultSize and letting the panel library normalize.

🛠️ Suggested simplification

-        const dockResult = findNodeById(config, dashboardId);
-        if (!dockResult || !isLayoutDockNode(dockResult.node)) {
-          return;
-        }
-
-        const dockNode = dockResult.node;
-
-        // Find the root split of the dock node
-        if (!isLayoutSplitNode(dockNode.root)) {
-          return;
-        }
-
-        // Clone the config and add the new chart panel to the dock's root split
-        const newConfig = JSON.parse(JSON.stringify(config)) as LayoutConfig;
+        // Clone up front and operate on the clone only.
+        const newConfig =
+          typeof structuredClone === 'function'
+            ? (structuredClone(config) as LayoutConfig)
+            : (JSON.parse(JSON.stringify(config)) as LayoutConfig);
         const newDockResult = findNodeById(newConfig, dashboardId);
         if (!newDockResult || !isLayoutDockNode(newDockResult.node)) {
           return;
         }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@examples/layout/src/store.tsx` around lines 289 - 348, In
addChartToDashboard: remove the initial lookup/validation against the original
config (the block using findNodeById(config) and isLayoutDockNode on the
original dock) and only perform the lookup/validation after cloning (use
newConfig and newDockResult/newDockNode), and change the equal-size assignment
so it doesn’t use Math.floor(100 / totalChildren) which drops the remainder —
either omit setting defaultSize so the panel library normalizes sizes, or
compute base = Math.floor(100 / totalChildren) and add the leftover (100 - base
* totalChildren) to the first child in newDockNode.root.children; update
references to totalChildren, equalSize (or base/leftover) accordingly before
calling setConfig(newConfig).

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

examples/layout/src/components/DynamicChartHeader.tsx (1)

22-45: Nit: unnecessary Fragment wrapper.

The <>...</> wraps a single LeafLayout.Header child and can be removed.

♻️ Proposed cleanup

   return (
-    <>
-      <LeafLayout.Header>
+    <LeafLayout.Header>
         <div className="text-muted-foreground flex h-8 w-full border-b">
           ...
         </div>
-      </LeafLayout.Header>
-    </>
+    </LeafLayout.Header>
   );

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@examples/layout/src/components/DynamicChartHeader.tsx` around lines 22 - 45,
Remove the unnecessary React fragment wrapping the single LeafLayout.Header
element in DynamicChartHeader: delete the surrounding <> and </> so the
component returns the LeafLayout.Header directly (locate the return that
currently renders <> <LeafLayout.Header> ... </LeafLayout.Header> </> and
replace it with just <LeafLayout.Header> ... </LeafLayout.Header>). Ensure no
other JSX siblings are left at the same return level and keep existing props and
children (GripVerticalIcon, title, Button and handleRemove) unchanged.

packages/layout/src/node-renderers/leaf-node-renderer/useIsDockable.ts (1)

1-13: Nit: filename doesn't match the exported hook.

The file is useIsDockable.ts but the only export is useIsDockablePanel. Renaming the file to useIsDockablePanel.ts would keep import paths and symbol names aligned and make the module easier to discover.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/layout/src/node-renderers/leaf-node-renderer/useIsDockable.ts`
around lines 1 - 13, The exported hook is named useIsDockablePanel but the file
is useIsDockable.ts; rename the module file to useIsDockablePanel.ts so the
filename matches the exported symbol (useIsDockablePanel) and imports are
discoverable; update any imports that reference useIsDockable.ts to the new
filename if your tooling doesn't auto-update them.

packages/layout/src/node-renderers/leaf-node-renderer/LeafLayoutPanel.tsx (1)

49-58: Redundant opacity-100 class and dead branch when not dockable.

• opacity-100 is the default; the second object key only exists to cancel the first, so you can drop it.
• When isDockablePanel is false, isDragging can never be true (the draggable is disabled), so that condition is effectively isDragging alone. Simplifying makes intent clearer.

♻️ Suggested simplification

         className={cn(
           'group relative flex h-full w-full flex-col overflow-hidden',
-          {
-            'opacity-30': isDockablePanel && isDragging,
-            'opacity-100': isDockablePanel && !isDragging,
-          },
+          isDragging && 'opacity-30',
         )}

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/layout/src/node-renderers/leaf-node-renderer/LeafLayoutPanel.tsx`
around lines 49 - 58, The className object in LeafLayoutPanel's JSX (the cn call
using setNodeRef) contains a redundant 'opacity-100' branch and a dead branch
when !isDockablePanel; remove the 'opacity-100' entry and simplify the opacity
logic to only conditionally apply 'opacity-30' (e.g., 'opacity-30':
isDockablePanel && isDragging) so when not dockable no opacity classes are
toggled; update the className object in the component where setNodeRef, cn,
isDockablePanel, and isDragging are used.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

packages/room-shell/src/RoomShellSidebarButtons.tsx (2)

69-83: Minor: Inline fallback function creates new reference each render.

The (() => null) fallback creates a new function on every render when info?.icon is undefined. Consider extracting a stable fallback.

♻️ Suggested refactor

+const NoIcon: FC<{className?: string}> = () => null;
+
 const RoomShellSidebarButton: FC<{roomPanelType: string}> = ({
   // ...
   return (
     <SidebarButton
       key={roomPanelType}
       title={info?.title ?? ''}
       isSelected={visibleRoomPanels.includes(roomPanelType)}
       isDisabled={!initialized}
-      icon={info?.icon ?? (() => null)}
+      icon={info?.icon ?? NoIcon}
       onClick={() => togglePanel(roomPanelType)}
     />
   );

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/room-shell/src/RoomShellSidebarButtons.tsx` around lines 69 - 83,
The inline fallback (() => null) creates a new function each render; define a
stable NOOP_ICON function (e.g., const NOOP_ICON = () => null) outside the
component and replace the fallback in the SidebarButton prop from
icon={info?.icon ?? (() => null)} to icon={info?.icon ?? NOOP_ICON} so the icon
prop keeps a stable reference; update RoomShellSidebarButtons.tsx to declare
NOOP_ICON near the top of the module and use it in the render.

---

92-118: Memoize the filtered panel lists.

The filtering logic runs on every render, calling resolvePanelDefinition for each panel even when panels hasn't changed. Per coding guidelines, derived arrays should be computed with useMemo.

♻️ Suggested refactor

 const RoomShellSidebarButtons: FC<{className?: string}> = ({className}) => {
   const panels = useBaseRoomShellStore((state) => state.layout.panels);

+  const sidebarPanels = useMemo(() => {
+    if (!panels) return [];
+    return Object.keys(panels).filter((key) => {
+      const def = panels[key];
+      const resolved = def ? resolvePanelDefinition(def, {panelId: key}) : undefined;
+      return resolved?.placement === 'sidebar';
+    });
+  }, [panels]);
+
+  const sidebarBottomPanels = useMemo(() => {
+    if (!panels) return [];
+    return Object.keys(panels).filter((key) => {
+      const def = panels[key];
+      const resolved = def ? resolvePanelDefinition(def, {panelId: key}) : undefined;
+      return resolved?.placement === 'sidebar-bottom';
+    });
+  }, [panels]);
+
   return (
     <div className={cn('flex h-full grow flex-col', className)}>
       <div className="flex flex-col gap-2">
-        {panels
-          ? Object.keys(panels)
-              .filter((key) => {
-                const def = panels[key];
-                const resolved = def
-                  ? resolvePanelDefinition(def, {panelId: key})
-                  : undefined;
-                return resolved?.placement === 'sidebar';
-              })
-              .map((type) => (
-                <RoomShellSidebarButton key={type} roomPanelType={type} />
-              ))
-          : null}
+        {sidebarPanels.map((type) => (
+          <RoomShellSidebarButton key={type} roomPanelType={type} />
+        ))}
       </div>
       <div className="flex-1" />
       <div className="flex flex-col gap-2">
-        {Object.keys(panels)
-          .filter((key) => {
-            const def = panels[key];
-            const resolved = def
-              ? resolvePanelDefinition(def, {panelId: key})
-              : undefined;
-            return resolved?.placement === 'sidebar-bottom';
-          })
-          .map((type) => (
-            <RoomShellSidebarButton key={type} roomPanelType={type} />
-          ))}
+        {sidebarBottomPanels.map((type) => (
+          <RoomShellSidebarButton key={type} roomPanelType={type} />
+        ))}
       </div>
     </div>
   );
 };

As per coding guidelines: "When using Zustand/room-store selectors in React, do not create derived arrays/objects/functions inside the selector; instead select stable raw state first, then derive with React.useMemo in the component".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/room-shell/src/RoomShellSidebarButtons.tsx` around lines 92 - 118,
The component repeatedly filters `panels` and calls `resolvePanelDefinition` on
every render; wrap the two derived arrays (sidebar and sidebar-bottom) in
React.useMemo so they are recomputed only when `panels` changes. Specifically,
compute memoized arrays (e.g. sidebarPanelTypes and sidebarBottomPanelTypes)
using useMemo that iterate Object.keys(panels), call resolvePanelDefinition(def,
{panelId: key}) and filter by resolved.placement === 'sidebar' and
'sidebar-bottom' respectively, then map those memo values to render
<RoomShellSidebarButton roomPanelType={type} /> instead of filtering inline.