feat(stage-ui): Refactor providers and add credential validation#474
feat(stage-ui): Refactor providers and add credential validation#474nekomeowww merged 16 commits intomoeru-ai:mainfrom
Conversation
Introduces the `useProviderValidation` composable to centralize the UI logic for validating provider credentials. Previously, each provider settings page contained duplicated code for managing validation state, debouncing user input, and displaying feedback. This made the codebase difficult to maintain and prone to inconsistencies. This commit refactors all provider settings pages to use the new composable, which encapsulates the shared logic. This change significantly simplifies the component code, improves maintainability, and ensures a consistent validation implementation across the application.
✅ Deploy Preview for airi-docs ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
✅ Deploy Preview for airi-vtuber ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
There was a problem hiding this comment.
Summary of Changes
Hello @skirkru, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!
This pull request significantly refactors the provider configuration within "stage-ui" by introducing a reusable builder function for OpenAI-compatible providers, which drastically reduces code duplication. It also implements a real-time credential validation feature for an improved user experience, abstracting the logic into a dedicated Vue composable. Furthermore, it includes a critical fix for a CORS issue affecting the Anthropic provider.
Highlights
- Core Provider Refactoring: Introduced "buildOpenAICompatibleProvider" to centralize and simplify the definition of OpenAI-compatible providers, leading to cleaner and more maintainable code.
- Real-time Credential Validation: Implemented a user-facing feature that provides immediate feedback on API key and base URL validity, improving the onboarding and configuration experience.
- Reusable Validation Logic: Abstracted the credential validation mechanism into a "useProviderValidation" Vue composable, eliminating significant code duplication across numerous provider setting components.
- Anthropic CORS Resolution: Fixed a long-standing CORS issue with the Anthropic provider by implementing a custom fetch wrapper that injects the necessary "anthropic-dangerous-direct-browser-access" header.
- New Provider Integrations: Added new provider settings pages for Azure AI Foundry and vLLM, expanding the supported AI services.
- Enhanced Ollama Compatibility: Updated the Ollama provider's CORS warning message to include "http://tauri.localhost", improving guidance for local development environments.
Using Gemini Code Assist
The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.
Invoking Gemini
You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.
| Feature | Command | Description |
|---|---|---|
| Code Review | /gemini review |
Performs a code review for the current pull request in its current state. |
| Pull Request Summary | /gemini summary |
Provides a summary of the current pull request in its current state. |
| Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in issue comments and review comments. |
| Help | /gemini help |
Displays a list of available commands. |
Customization
To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.
Limitations & Feedback
Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.
You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.
Footnotes
-
Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩
There was a problem hiding this comment.
Code Review
This pull request introduces a significant and valuable refactoring by creating the useProviderValidation composable and buildOpenAICompatibleProvider builder function. This greatly reduces code duplication and improves maintainability across provider settings pages. The fix for the Anthropic CORS issue is also a welcome addition.
However, I've identified a few issues that should be addressed to ensure consistency and prevent loss of functionality:
- The new
azure-ai-foundry.vuecomponent does not use the newuseProviderValidationcomposable, re-introducing the duplication this PR aims to solve. - The refactoring of
ollama.vuehas removed the ability to configure custom headers, which is a feature regression. - The speech and transcription provider pages have lost their interactive testing playgrounds.
apps/stage-tamagotchi/src/pages/settings/providers/openai-compatible-audio-speech.vue
Show resolved
Hide resolved
apps/stage-tamagotchi/src/pages/settings/providers/openai-compatible-audio-transcription.vue
Show resolved
Hide resolved
packages/stage-ui/src/stores/providers/openai-compatible-builder.ts
Outdated
Show resolved
Hide resolved
packages/stage-ui/src/components/Scenarios/Dialogs/Onboarding/Onboarding.vue
Show resolved
Hide resolved
| </div> | ||
| </template> | ||
| </Alert> | ||
| <Alert v-if="isValid && isValidating === 0" type="success"> |
There was a problem hiding this comment.
can you elaborate more?
| const responseChat = await fetch(`${config.baseUrl as string}chat/completions`, { headers: { Authorization: `Bearer ${config.apiKey}`, ...additionalHeaders }, method: 'POST' }) | ||
| responseModelList = await fetch(`${config.baseUrl as string}models`, { headers: { Authorization: `Bearer ${config.apiKey}`, ...additionalHeaders } }) |
There was a problem hiding this comment.
Should we use @xsai/models and @xsai/generate-text for this?
There was a problem hiding this comment.
@nekomeowww its check its behavior, there is no need to use there are built in functions that support it
There was a problem hiding this comment.
But xsai handles endpoint, apikey, and everything well enough, xsai is part of Moeru AI, which is also part of AIRI, feel free to use it, small and compact.
There was a problem hiding this comment.
I just reviewed how the implementation there
https://github.com/moeru-ai/xsai/blob/main/packages/model/src/utils/list-models.ts
https://github.com/moeru-ai/xsai/blob/main/packages/shared/src/utils/response-catch.ts
and .https://github.com/moeru-ai/xsai/blob/main/packages/generate-text/src/index.ts
Well we can use that, but the implementation will be quite longer, but sure
I just preventing using chainsaw when saw work fine
There was a problem hiding this comment.
I can't get the same thing with those dependency
There was a problem hiding this comment.
There was a problem hiding this comment.
you missed the point why its there, its not checking whats the output, its only check whats is the respond code
Why you might ask? even if some provider use OpenAI Compatible format, the API key validation is different, they just share the same endpoint, the content who knows
The point is, that dependency is to generate text, while what validation need is checking what the response code.
Its simple, consistent, as we dont care about the content
There was a problem hiding this comment.
unless the dependency have a function to validate API key, we can move the current code to that
|
Need to resolve conflict i think. |
|
@nekomeowww I havent add the local version, I will do the conflicts first, have bad eyesight from yesterday haha, i keep the CI a problem so you know its still not finished |
|
@nekomeowww ok this should be it |



Summary
This pull request introduces a major refactoring of the provider configuration in
stage-ui. It abstracts the creation of OpenAI-compatible providers into a reusable builder function, significantly reducing code duplication. It also adds a user-facing feature for real-time credential validation, which has been abstracted into auseProviderValidationcomposable for maintainability. Additionally, it includes a fix for a CORS issue with the Anthropic provider.Problem
providers.tsfile difficult to maintain and prone to errors.Solution
buildOpenAICompatibleProviderfunction was created to abstract the common logic for defining these providers. This makes adding new providers a one-line change and centralizes the logic for listing models and validating configurations.anthropic-dangerous-direct-browser-access: trueheader, resolving the CORS issue.useProviderValidationVue composable. This hook encapsulates all the state management, API calls, and debouncing, dramatically simplifying the provider setting components.My Comment
Just a small PR, but the code is much better than before. While the provider system is still a bit monolithic, this refactoring is a good step forward. It also fixes the annoying Anthropic CORS issue.