Tech322/desktop#2
Conversation
This reverts commit 9ec9638.
…into tech322/desktop
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
|
Warning Rate limit exceeded@techeng322 has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 24 minutes and 48 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. WalkthroughThe pull request introduces several modifications to the Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant Chat
participant ChatInput
participant Messages
participant SubmitButton
User->>Chat: Open chat interface
Chat->>Messages: Render messages
Chat->>ChatInput: Render input field
ChatInput->>User: Display placeholder "Ask me anything about the music industry..."
User->>ChatInput: Type message
ChatInput->>SubmitButton: Check if can submit
SubmitButton->>Chat: Submit message
Chat->>Messages: Update message list
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (1)
components/Chat/ChatInput.tsx (1)
Line range hint
19-32: Consider these suggestions for improved maintainability and performance:
To enhance maintainability, consider moving all styles to a separate CSS file or using a CSS-in-JS solution. This would make the component more readable and easier to maintain.
The textarea might benefit from a
rowsprop to control its initial height. For example:<textarea rows={3} // ... other props />The
Boolean()wrapper in the SubmitButton prop is unnecessary. You can simplify it to:<SubmitButton canSubmit={!!input} />Or even:
<SubmitButton canSubmit={input.length > 0} />This would be more explicit about the condition for submission.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (4)
- components/Chat/Chat.tsx (1 hunks)
- components/Chat/ChatInput.tsx (1 hunks)
- components/Chat/Messages.tsx (1 hunks)
- components/Chat/SubmitButton.tsx (1 hunks)
✅ Files skipped from review due to trivial changes (1)
- components/Chat/Messages.tsx
🧰 Additional context used
🪛 Biome
components/Chat/SubmitButton.tsx
[error] 3-3: Don't use 'Boolean' as a type.
Use lowercase primitives for consistency.
Safe fix: Use 'boolean' instead(lint/complexity/noBannedTypes)
🔇 Additional comments (5)
components/Chat/SubmitButton.tsx (1)
Line range hint
4-15: LGTM for the rest of the implementation.The component's logic and rendering are implemented correctly. The conditional styling based on the
canSubmitprop is appropriate, and the use of aria-label for accessibility is commendable.🧰 Tools
🪛 Biome
[error] 3-3: Don't use 'Boolean' as a type.
Use lowercase primitives for consistency.
Safe fix: Use 'boolean' instead(lint/complexity/noBannedTypes)
components/Chat/Chat.tsx (2)
10-10: Improved layout for better content presentation.The addition of
mx-auto max-w-3xlclasses for the case when there are no messages is a good improvement. It centers the content and limits its maximum width, which should enhance readability and visual appeal on larger screens.
13-13: Updated prompt text for broader applicability.The change from "How is Luh Tyler's 3D Game Performing?" to "What can I help you ship?" makes the prompt more generic and potentially applicable to a wider range of scenarios. This aligns well with making the component more versatile.
Could you please clarify if this change in context is intentional and if it affects the overall purpose or use case of the chat component? To assist in verifying the impact, I can run the following script:
✅ Verification successful
Updated search commands to correctly target TypeScript files.
No references to the old prompt text found in the codebase.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Search for references to the old prompt text in other files # Test: Search for the old prompt text rg --type typescript --type javascript "How is Luh Tyler's 3D Game Performing?" # Test: Search for any mentions of Luh Tyler or 3D Game rg --type typescript --type javascript "Luh Tyler|3D Game"Length of output: 215
Script:
#!/bin/bash # Description: Search for references to the old prompt text in other files # Test: Search for the old prompt text rg --glob '*.ts' --glob '*.tsx' "How is Luh Tyler's 3D Game Performing?" # Test: Search for any mentions of Luh Tyler or 3D Game rg --glob '*.ts' --glob '*.tsx' "Luh Tyler|3D Game"Length of output: 131
components/Chat/ChatInput.tsx (2)
19-19: LGTM: Improved layout with centered, width-constrained input area.The addition of
max-w-3xl mx-autoclasses enhances the chat input's layout by centering it horizontally and limiting its maximum width. This change improves readability and user experience, especially on larger screens.
25-25: LGTM: Updated placeholder text for better user guidance.The placeholder text has been updated to "Ask me anything about the music industry...", which provides more specific guidance to users about the kind of questions they can ask. This change aligns well with the purpose of the chat interface and should improve user engagement.
| import { ArrowUpRightIcon } from "lucide-react"; | ||
|
|
||
| const SubmitButton = ({ canSubmit }: { canSubmit: boolean }) => { | ||
| const SubmitButton = ({ canSubmit }: { canSubmit: Boolean }) => { |
There was a problem hiding this comment.
💡 Codebase verification
Revert the type change from Boolean to boolean.
The type of the canSubmit prop in SubmitButton.tsx is currently set to Boolean. This should be changed back to the primitive boolean type for the following reasons:
booleanis the appropriate primitive type in TypeScript, whileBooleanrefers to the object wrapper type.- Using the primitive
booleanensures better performance and type safety. - This change aligns with TypeScript best practices and common conventions.
Location:
components/Chat/SubmitButton.tsx, line 3
-const SubmitButton = ({ canSubmit }: { canSubmit: Boolean }) => {
+const SubmitButton = ({ canSubmit }: { canSubmit: boolean }) => {🔗 Analysis chain
Revert the type change from Boolean to boolean.
The type of the canSubmit prop has been changed from boolean to Boolean. This change is not recommended in TypeScript for the following reasons:
booleanis the primitive type, whileBooleanis the object wrapper type.- Using primitive types is generally preferred for better performance and type inference.
- This change goes against TypeScript best practices and common conventions.
Please apply the following fix:
-const SubmitButton = ({ canSubmit }: { canSubmit: Boolean }) => {
+const SubmitButton = ({ canSubmit }: { canSubmit: boolean }) => {Let's verify if this change impacts other parts of the codebase:
This will help us understand if the type change was intentional and if it affects other parts of the codebase.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for usage of SubmitButton component and its prop types
# Search for SubmitButton usage
echo "Searching for SubmitButton usage:"
rg --type typescript --type typescriptreact "SubmitButton" -C 2
# Search for any Boolean type usage in the codebase
echo "Searching for Boolean type usage:"
rg --type typescript --type typescriptreact "\: Boolean" -C 2
Length of output: 393
Script:
#!/bin/bash
# Description: Check for usage of SubmitButton component and its prop types
# Search for SubmitButton usage
echo "Searching for SubmitButton usage:"
rg --glob '*.{ts,tsx}' "SubmitButton" -C 2
# Search for any Boolean type usage
echo "Searching for Boolean type usage:"
rg --glob '*.{ts,tsx}' ": Boolean" -C 2
Length of output: 1485
🧰 Tools
🪛 Biome
[error] 3-3: Don't use 'Boolean' as a type.
Use lowercase primitives for consistency.
Safe fix: Use 'boolean' instead(lint/complexity/noBannedTypes)
| > | ||
| <p className="font-sans font-semibold text-2xl mb-2 text-center"> | ||
| {`How is Luh Tyler's 3D Game Performing?`} | ||
| What can I help you ship? |
There was a problem hiding this comment.
Please keep the text as it was in your previous PR.
| onChange={handleInputChange} | ||
| onKeyDown={handleKeyDown} | ||
| placeholder="Ask recoupable a question..." | ||
| placeholder="Ask me anything about the music industry..." |
- Add google/gemini-3-pro-preview as top featured model - Display as 'Gemini 3 Pro' with 'New' badge - Move Claude Sonnet 4.5 to position #2 - Mark as pro model (requires subscription) New featured models order: 1. Gemini 3 Pro (New) 2. Claude Sonnet 4.5 3. GPT-5 4. Nano Banana 5. Gemini 2.5 Flash 6. GPT-5 Mini 7. Gemini 2.5 Pro 8. Grok 4
… gates the bootstrap E2E found two POSTs on initial mount: one with `artist_id: null`, one with `artist_id: <saved-selection>`. Cause: in react-query v5 `isLoading` is `isPending && isFetching` — it's false when the query is disabled. While `useArtistsRoster` waits for `userData` from `UserProvider` to land, `enabled: false`, `isLoading: false`. The bootstrap effect saw "settled, empty roster" and fired POST #1 with `artistId: undefined`. Once `userData` arrived, the query enabled, artists resolved, selection moved to the saved artist, and the mutation effect re-fired with the real `artistId` (POST #2). Switch to `isPending` (true while disabled OR fetching) so the loading flag stays true through the entire "we don't know the roster yet" window. Surfaced as `isLoading` to keep the consumer interface stable. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…1759) * feat(chat): stamp sessions with selected artist; refactor useArtists Tags every newly-provisioned session with `selectedArtist.account_id` via `POST /api/sessions { artistId }` (api#628 already accepts it), so the sidebar's artist filter (#1756) groups chats under the right artist. Each artist switch mints a fresh session under the new context. The hard part wasn't passing the field — it was making the bootstrap fire exactly once per (artistId, orgId). Earlier iterations stacked refs on top of `useState` to police a duplicate POST that fired because `useArtists` resolved `selectedArtist` across two renders (commit A: `isLoading` flips false with `selectedArtist=null`; commit B: saved selection restored). Both commits independently satisfied the bootstrap's effect gate, both started a POST, both wrote to `sessions.artist_id`. Refs guarded the symptom; the real fix is to make `selectedArtist` resolve in a single render. ### `useArtists` — react-query + derived selection - Roster comes from `useQuery`, keyed on `(accountId, orgId)`. No imperative `getArtists` effect, no `setIsLoading` lifecycle. - `selectedArtist` is a single `useMemo` deriving from `(artists, savedSelections, orgKey, userOverride)`. Precedence: user override (this session) → saved (localStorage, per-org) → artists[0] auto-pick → null. - The race is gone *by construction*. There is no longer a render where `artists` is populated but `selectedArtist` is still null. - `useInitialArtists` deleted — its restoration effect folds into the memo; the sync-on-org-change effect is implicit (memo recomputes when `orgKey` changes). - `setArtists` mirrors React's `setState` signature (array | updater) so `useArtistPinToggle` and `useDeleteArtist` keep working without changes; under the hood it's `queryClient.setQueryData`. - `getArtists(artistId?)` becomes `queryClient.fetchQuery` + an optional `setSelectedArtist` post-fetch, preserving the existing call sites in `useArtistPinToggle`, `useDeleteArtist`, the `CreateArtistToolResult` / `UpdateArtistInfoSuccess` / `UpdateArtistSocialsSuccess` tool result components, and `saveSetting`. ### `useNewChatBootstrap` — useMutation, no refs - POST is semantically a mutation. `useMutation` owns the in-flight / success / error state instead of a hand-rolled state machine. - Effect gates on `mutation.variables` (react-query's own last-mutated args) plus `isPending` / `isSuccess`. Incidental re-renders re-enter the effect but bail idempotently. No refs. - Artist or org change → mutation.variables no longer matches → fresh `mutate()` fires under the new context. Orphan session from the old context is accepted (rare in practice). ### `Artist.tsx` — narrow the hard-nav - Hard-navigates to `/chat` only when switching artists from a tagged chat URL (`/sessions/{sid}/chats/{cid}` or legacy `/chat/{roomId}`). On bare `/chat` the bootstrap re-fires in place when `artistId` changes — no nav, no remount flicker. - `window.location.href` (not `router.replace`) because `useVercelChat`'s `silentlyUpdateUrl` writes via `history.replaceState`, leaving Next's internal router state out of sync with the URL bar — a client-side replace can no-op. ### `lib/sessions/createSession.ts` - `CreateSessionInput` gains optional `artistId`. Wire-compatible with `api/lib/sessions/validateCreateSessionBody.ts`. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * refactor(chat): extract artist selection + chat-session provisioning per OCP Addresses sweetmantech's review comments on lines `useArtists.tsx:80` and `useNewChatBootstrap.ts:107` — net-new logic was being added inline to existing hooks instead of being given its own module. Two extractions: 1. `hooks/artists/useArtistSelection.ts` — owns the per-org artist selection: `useLocalStorage` for saved picks, `userOverride` state for explicit this-session pick/deselect, and the derived `selectedArtist` memo (precedence: override → saved → first). `useArtists.tsx` now just calls it with `(orgKey, artists)`. 2. `lib/sessions/provisionChatSession.ts` — combines `createSession` + `createSandbox` into one function. `useNewChatBootstrap.ts` now wraps that in `useMutation` and owns the trigger / input-change re-fire logic only. No behavior change — both hooks return the same shape and respond to the same inputs. Just smaller files with clearer single responsibility. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(chat): throw on missing Privy token in useArtists queryFn Addresses CodeRabbit feedback on `hooks/useArtists.tsx:61`. The previous shape silently resolved to `[]` when `getAccessToken()` came back null transiently — `useQuery` marked the query successful, `isLoading` flipped false, and `useNewChatBootstrap` saw a "settled, empty roster" and POSTed a session with `artistId: undefined`. Throw so the query goes to `isError` and the bootstrap stays gated. Same fix on the imperative `getArtists` callback for consistency. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * refactor(chat): extract roster + provisioner hooks per OCP Two more OCP extractions, addressing the remaining inline-net-new-code comments on `useArtists.tsx` and `useNewChatBootstrap.ts`: 1. `hooks/artists/useArtistsRoster.ts` — owns the react-query fetch keyed on `(userId, orgId)`, the `setArtists` optimistic-update helper, and the `refetchArtists` imperative refetch. `useArtists` now consumes it via `useArtistsRoster({ userId, orgId })`. 2. `hooks/sessions/useProvisionChatSession.ts` — owns the mutation lifecycle: the `useMutation` setup, the `useEffect` with `sameInputs` guard, and the state-mapping from mutation state to the discriminated `ProvisionChatSessionState`. `useNewChatBootstrap` shrinks to a thin provider-wiring shim (~30 LOC). Each existing hook now has a single clear responsibility: - `useArtists` composes roster + selection + per-artist settings - `useNewChatBootstrap` wires Privy/Org/Artist providers into the provisioner No behavior change. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(chat): gate useArtistsRoster on authenticated, drop the throw Matches `useConversations` / `useCredits` — they gate the query on Privy's `authenticated` rather than throwing inside the queryFn for the transient-null-token case. Now this hook does the same: the query won't fire until Privy is ready, and if the token is still null in some pathological case the network call 401s and the query goes to `isError` (same outcome the throw produced). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(chat): use isPending in useArtistsRoster so disabled-query window gates the bootstrap E2E found two POSTs on initial mount: one with `artist_id: null`, one with `artist_id: <saved-selection>`. Cause: in react-query v5 `isLoading` is `isPending && isFetching` — it's false when the query is disabled. While `useArtistsRoster` waits for `userData` from `UserProvider` to land, `enabled: false`, `isLoading: false`. The bootstrap effect saw "settled, empty roster" and fired POST #1 with `artistId: undefined`. Once `userData` arrived, the query enabled, artists resolved, selection moved to the saved artist, and the mutation effect re-fired with the real `artistId` (POST #2). Switch to `isPending` (true while disabled OR fetching) so the loading flag stays true through the entire "we don't know the roster yet" window. Surfaced as `isLoading` to keep the consumer interface stable. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Co-authored-by: Sweets Sweetman <sweetmantech@gmail.com>
Summary by CodeRabbit
New Features
Bug Fixes
Refactor