[WIP] feat: UI to allow users to manage different AI models #73
Conversation
Redesigned the chat UI to simplify user interactions by removing individual button components like LogoutButton and NewConversationButton, integrating a NewConversationMenuBar for a consolidated interface. Disabled clearing message array upon new conversation action for better state handling. Adjusted the ConversationHistory styling and skeleton placeholders to increase visible conversation count. Also, encapsulated theme and logout functionality within new SettingsDialog component for more organized settings management. The restructuring aims to offer a more intuitive layout, reducing clutter and focusing more on user engagement with conversations. The addition of the SettingsDialog provides a designated area for personalization without overwhelming the main interface.
- Redesigned ConversationHistory component for readability and scalability by introducing a dedicated ConversationHistoryItem component, optimizing the display for empty states with a cleaner fallback design. - Removed dependency on framer-motion for reduced complexity and potential performance gains. - Incorporated new Button component to standardize interactive elements and improve accessibility. - Updated NewConversationMenuBar to include visual cues by pairing selections with icons, clarifying user choice and enhancing the user interface. - Adjusted SideMenu for a more consistent and polished layout by fine-tuning widths and gradient effects. These changes collectively enhance the user experience through cleaner interfaces, more intuitive interactions, and standardize component use across the application.
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
|
Lots of work for the actual handling of these ui parts as these are all mostly hardcoded until we plan out the feature of how exactly we will set up models in the settings menu then populate the model menu with the active models in your settings |
|
seems like there is a conflict in Chat.tsx |
I'll update you as I work more on this. My thinking is to set up some React context for active/setup models, then use Capacitor storage like we did with Supabase auth. I've been worrying purely about the frontend because I don't have a full understanding of what's needed yet. Maybe we can align more on how the models work and such, so I can get a better picture of how this needs to work. |
|
@adamcohenhillel #69 this issue is where I think it would be good to plan out this feature, whenever we want to prioritize it. |
Jacksonmills
changed the title
|
I think having a drop down to select your model would be nice, sounds like you are implementing that? Right now the backend code checks if certain env variables are truthy and if so it uses that particular chatClient. Ideally a user could have multiple models they are trying out. It would be more robust to send the chatClient as a prop then on the backend we can just deconstruct the chatClient and use it. That would clean the code up and make it more flexible. |
Totally, I was also picturing a settings modal to set your keys for each model, but currently we do that within the setup process right? So just need a way to either just detect them and populate the dropdown or add the settings to the frontend to add models to supabase/capacitor storage. Maybe a good first step is just the dropdown? |
|
I see in the supabase function we are just checking if the key exists and it will just override which model like you were saying, but you were saying if the key is provided from the frontend we just pass it in? |
|
So I added react context that can control the current selected model, however I may need some input on the best way we can handle model api keys in the frontend and pass which one to use/the key itself into the supabase function(?), LMK what you think frontend wise asw! |
- Created a new `ModelProvider` for managing model state within the app, enabling a more centralized approach to handling the current AI model in use. - Integrated the `ModelProvider` by replacing local state management with context usage in `NewConversationMenuBar`, ensuring consistency across the component hierarchy. - Refactored `SettingsDialog` to incorporate inputs for different API keys and base URL settings, laying the groundwork for enhanced user configurability and multiple model support. - Minor code ordering and syntax standardization in UI components to align with the application's coding conventions. - Wrapped the application in `ModelProvider` in `_app.tsx` to ensure context availability throughout the app. These changes promote extensibility and maintainability as the application evolves to support more models and custom user settings.
This comment was marked as outdated.
This comment was marked as outdated.
The restructuring aims to offer a more intuitive layout, reducing clutter and focusing more on user engagement with conversations. The addition of the SettingsDialog provides a designated area for personalization without overwhelming the main interface.
#69