feat: integrate built-in AI provider support#16
Conversation
- Added support for a new built-in AI provider, allowing users to select between OpenAI-compatible and built-in AI options. - Updated the App component to manage provider selection and model handling accordingly. - Enhanced the SettingsModal to include provider selection and adjusted form handling based on the selected provider. - Updated README with configuration instructions for the new built-in AI provider. - Refactored components to accommodate the new provider logic and ensure seamless user experience.
|
Note Other AI code review bot(s) detectedCodeRabbit has detected other AI code review bot(s) in this pull request and will avoid duplicating their findings in the review comments. This may lead to a less comprehensive review. WalkthroughAdds a selectable provider model: either OpenAI-Compatible (API-based, model sync) or Built-in AI (no API key, automatic availability/download). Updates app state, settings, UI props, routing, and runtime checks to handle provider-specific flows and built-in download/availability lifecycle. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant App
participant Settings
participant OpenAI as OpenAI-Compatible
participant BuiltIn as Built-in AI
User->>Settings: open settings
Settings->>User: show provider choice
User->>Settings: select provider & save
Settings->>App: set providerKind
alt provider == openai-compatible
App->>OpenAI: syncModels (if configured)
OpenAI-->>App: model list
App->>User: enable model selector
else provider == built-in
App->>BuiltIn: check availability
BuiltIn-->>App: status (downloadable/downloading/available)
App->>User: show built-in status & progress
end
User->>App: send text / predict
alt provider == openai-compatible
App->>OpenAI: request with API key & model
OpenAI-->>App: response
else provider == built-in
App->>BuiltIn: local call (requires available)
BuiltIn-->>App: response or error
end
App->>User: display result or error
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes
Possibly related PRs
Suggested labels
Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: CodeRabbit UI Review profile: CHILL Plan: Pro 📒 Files selected for processing (2)
🧰 Additional context used🧬 Code graph analysis (2)src/App.tsx (1)
src/components/SettingsModal.tsx (1)
🔇 Additional comments (1)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (2)
src/components/Header.tsx (1)
8-10: Model selector/status UX for provider switching is well‑structuredThe
modelSelectorDisabled,modelPlaceholder, andmodelStatusprops cleanly separate the “selectable list” vs “status display” modes, and the conditional rendering around the Select is straightforward. You might optionally consider addingrole="status"(and possiblyaria-live) to the status<div>to improve screen‑reader feedback, but functionally this looks solid.Also applies to: 33-35, 46-63
src/App.tsx (1)
117-120: Provider‑specific routing for chat vs text is consistent; consider a minor UX tweak
syncModelsearly‑returns whenproviderKind !== "openai-compatible", and the header’smodelSelectorDisabledmirrors that, so models are only fetched/used for the OpenAI‑compatible path.handleTextPredict, theview === "text" && providerKind === "built-in"toast, and theTextCompletionViewprops (isPredictDisabled/disabledReason) all consistently enforce “built‑in supports chat only”.handleSendroutes correctly between OpenAI and built‑in by usingusingOpenAIand conditionally callingensureBuiltInModelReady.If you want to reduce user friction further, you could optionally disable or hide the “Text” view in the header when
providerKind === "built-in"instead of allowing selection then showing an error toast.Also applies to: 160-160, 326-331, 468-471, 520-534, 559-562, 673-680, 802-810, 822-822
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
bun.lockis excluded by!**/*.lock
📒 Files selected for processing (7)
README.md(1 hunks)package.json(1 hunks)src/App.tsx(16 hunks)src/components/Header.tsx(3 hunks)src/components/SettingsModal.tsx(3 hunks)src/components/TextCompletionView.tsx(3 hunks)src/types.ts(1 hunks)
🧰 Additional context used
🧬 Code graph analysis (2)
src/components/SettingsModal.tsx (1)
src/types.ts (1)
ProviderKind(21-21)
src/App.tsx (1)
src/types.ts (1)
ProviderKind(21-21)
🪛 markdownlint-cli2 (0.18.1)
README.md
15-15: Hard tabs
Column: 1
(MD010, no-hard-tabs)
16-16: Hard tabs
Column: 1
(MD010, no-hard-tabs)
🔇 Additional comments (5)
package.json (1)
15-15: Built-in AI core dependency wiring looks consistentThe added
@built-in-ai/coredependency aligns with its usage insrc/App.tsxand the new providerKind flow; no issues from this file alone.src/types.ts (1)
20-21: ProviderKind union type is clear and future‑proofThe
"openai-compatible" | "built-in"union is a good, explicit discriminant for provider-specific logic and keeps call sites type-safe.src/components/TextCompletionView.tsx (1)
6-7: Predict button disable behavior is correctly integrated
isPredictDisabledwith a default offalse, combined withdisabledReasonmapped totitle, cleanly gates the Predict action while still allowing Stop when generating. No issues here.Also applies to: 16-17, 45-47
src/components/SettingsModal.tsx (1)
1-8: Provider‑aware settings flow is correctly wired
- Including
providerKindinSettingsFormValuesand default/reset values keeps the modal in sync with app state.- The provider
<Select>pluswatch("providerKind")and conditional rendering of base URL/API key and “Sync from API” only for"openai-compatible"behaves as expected.- Validation rules tied to
selectedProvider === "openai-compatible"avoid forcing credentials when using the built‑in provider.Overall, the modal’s new provider logic looks consistent and safe.
Also applies to: 11-17, 23-27, 33-47, 61-75, 76-108
src/App.tsx (1)
1-1: Built‑in AI lifecycle and providerKind persistence look robustThe new
providerKindstate,providerKindKeypersistence,builtInStatus(with progress), andbuiltInModelRefcombined withensureBuiltInModelReadygive a clear, fault‑tolerant path for using the built‑in model. Availability checks, progress updates, and error toasts are all handled, and resettingbuiltInStatuswhen switching back to the OpenAI‑compatible provider avoids stale UI. No correctness issues stand out here.Also applies to: 29-50, 60-80, 164-167, 191-196, 197-212
- Refactored the App component to replace built-in model status management with a new BuiltInAvailability type. - Enhanced the SettingsModal to include download progress and error handling for the built-in AI model. - Updated the logic for checking and downloading the built-in model, improving user feedback during the process. - Adjusted the integration of built-in AI provider to streamline availability checks and model readiness.
- Adjusted formatting for the provider selection instructions to enhance readability. - Ensured consistent indentation for better visual structure in the documentation.
|
@codex review |
There was a problem hiding this comment.
Actionable comments posted: 3
♻️ Duplicate comments (1)
README.md (1)
14-16: Hard tabs violation on lines 15-16 already flagged in previous reviewThis issue was already identified in a previous review. Lines 15-16 contain leading tab characters that violate the
no-hard-tabsmarkdownlint rule (MD010). Replace the leading tabs with spaces.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
README.md(1 hunks)src/App.tsx(16 hunks)src/components/SettingsModal.tsx(3 hunks)src/types.ts(1 hunks)
🧰 Additional context used
🧬 Code graph analysis (2)
src/App.tsx (1)
src/types.ts (2)
ProviderKind(21-21)BuiltInAvailability(23-28)
src/components/SettingsModal.tsx (1)
src/types.ts (2)
ProviderKind(21-21)BuiltInAvailability(23-28)
🔇 Additional comments (7)
src/types.ts (1)
21-28: LGTM! Clean type definitions for the dual-provider modelThe new
ProviderKindandBuiltInAvailabilitytypes are well-defined and appropriately model the state space for the built-in AI integration.src/components/SettingsModal.tsx (2)
98-157: LGTM! Comprehensive built-in model download flow with proper error handlingThe
handleDownloadModelfunction correctly handles all availability states, provides progress feedback, and includes proper cleanup in thefinallyblock. The guard conditions prevent invalid state transitions.
214-296: Well-structured provider-specific UI branchingThe conditional rendering based on
selectedProvidercleanly separates OpenAI-Compatible inputs from Built-in AI status/download UI. The form validation correctly appliesrequiredonly when the OpenAI-Compatible provider is selected.src/App.tsx (4)
124-126: Correct early-exit for non-OpenAI providersThe guard prevents unnecessary model syncing when using the built-in provider, aligning with the dual-provider design.
206-210: Good: Clear active model when switching to built-in providerThis effect correctly resets the active model when switching to built-in, since built-in AI doesn't use the model list.
519-532: Provider-specific validation is clear and comprehensiveThe conditional validation for OpenAI vs. built-in providers is well-structured, with descriptive error messages for each failure mode.
638-652: Settings persistence and provider-specific behavior handled correctlyThe save handler properly persists
providerKind, then triggers the appropriate behavior: syncing models for OpenAI-Compatible or clearing the active model for built-in.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
…Modal - Removed the normalizeAvailability function from both App and SettingsModal components. - Updated built-in availability handling to directly cast the availability response to BuiltInAvailability type. - Streamlined the logic for setting built-in availability, enhancing code clarity and maintainability.
…ngsModal - Updated the logic for checking built-in availability to ensure it only triggers when the selected provider is "built-in" and the availability status is "unknown". - Enhanced dependency array in useEffect hooks for better performance and clarity.
…to OpenAI - Introduced a new `force` parameter to bypass the provider compatibility check for "openai-compatible". - Updated the logic in the App component to utilize the `force` option when setting the active model, enhancing flexibility in provider management.
1 participant
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.