front end wiring#105
Merged
Merged
Conversation
## Summary of Changes ★ Insight ───────────────────────────────────── **Visual Hierarchy Improvements:** - **Capability tags**: Added indigo-colored badges showing the capability type (e.g., "llm", "vector_db") on provider cards for quick identification - **Inline slot labels**: Moved capability requirements inside the drop zones as inline badges, eliminating protruding labels for a more compact layout - **Template distinction**: Changed "default" to "template" with blue coloring to better indicate template providers vs. instances ───────────────────────────────────────────────── ### 1. **Capability Tags on Provider Cards** (WiringBoard.tsx:467-469) Added a capability badge to each provider card showing the provider's capability type (e.g., "llm", "vector_db") in an indigo-colored tag. This helps users quickly identify what type of capability each provider offers without needing to check the section headers. ### 2. **Inline Capability Requirements in Drop Zones** (WiringBoard.tsx:837-899) Moved the capability type label from above the drop zone into the drop area itself. The capability is now shown as an inline badge within the drop zone text: - Empty slots: "Drag **capability** provider here" - Drop target: "Drop **capability** here" - Connected: Shows provider name with capability badge - Orphaned: Shows warning with capability badge This creates a tighter, more compact layout without labels jutting out. ### 3. **Template Indicator with Color Distinction** (WiringBoard.tsx:475-479) Changed the "default" badge to "template" with blue coloring (`bg-blue-100 dark:bg-blue-900/40 text-blue-700 dark:text-blue-300`) to better distinguish template providers from instances. This makes it clearer which providers are base templates versus specific instances. All changes maintain the existing data-testid attributes for E2E testing compatibility.
…on line 567. The try-catch-finally structure is now complete and proper. ★ Insight ───────────────────────────────────── **Error Handling Pattern**: This function demonstrates a common async/await pattern where: - The `try` block contains the main async logic flow - Early returns with error messages provide graceful degradation (line 558) - The `catch` block handles unexpected errors with user-friendly messages - The `finally` block ensures cleanup (setLoading) runs regardless of success/failure The stray brace was likely from a refactoring where conditional logic was removed but the brace remained. ───────────────────────────────────────────────── The wiring board UI improvements are complete, and I've also fixed the unrelated linting error in TailscaleWizard.tsx that was blocking the build.
…as done: ★ Insight ───────────────────────────────────── **Configuration Visibility Pattern**: The updated UI now provides a complete view of the wiring configuration at a glance: - **Provider cards** show actual config values (not generic "default" labels) - **Override detection** uses amber color coding when instance values differ from their template - **Slot details** display provider configuration inline, eliminating the need to navigate elsewhere to understand what's wired - This pattern follows the principle of "progressive disclosure" - showing essential info compactly, with tooltips for full details ───────────────────────────────────────────────── ## Summary of Changes to WiringBoard.tsx ### 1. **Removed "template" Badge** (lines 466-476) Removed the generic "template" badge entirely. Template providers are now distinguished by their position in the hierarchy and their config values. ### 2. **Config Override Color Coding** (lines 574-590) - Added `templateProvider` prop to `DraggableProviderProps` interface - Updated `DraggableProvider` to accept and use template info - Config values on **instance** providers now show in **amber** (`text-amber-600 dark:text-amber-400`) when they differ from the template's value - Config values that match the template remain in neutral gray - Tooltips indicate "(overridden)" for clarity ### 3. **Provider Details in Filled Slots** (lines 853-896) When a capability slot is filled with a provider: - Shows provider name with capability badge (as before) - **NEW**: Displays up to 2 config variables below the provider name - Shows "+N more" indicator if there are additional config vars - Config values are indented (pl-6) for visual hierarchy - Uses same styling as provider cards for consistency ### 4. **Template Provider Passing** (line 291) Instances now receive their parent template via the `templateProvider` prop, enabling override detection. These changes provide much better information density and make it immediately clear: - Which providers are templates vs instances - Which config values have been customized - What configuration is active on wired connections
- Actual config values (like "gpt-4" instead of "default model") - "(set)" for values that exist but can't be displayed - Config details in the filled capability slots The changes I made: 1. **Templates** (lines 566-568): Changed `'(configured)'` to `'(set)'` and prioritized showing actual `field.value` when available 2. **Instances** (lines 623-628): Changed to show actual `field.value` inherited from template instead of `'(default)'`, and changed fallback from `'(default)'` to `'(set)'` This means: - When a template has `model: "gpt-4"`, it will show "gpt-4" instead of "(configured)" - When an instance inherits that value, it will also show "gpt-4" (in neutral color since it's not overridden) - When an instance overrides it to "gpt-3.5-turbo", it will show "gpt-3.5-turbo" in amber (due to the WiringBoard override detection) - The filled capability slots will now display these config values below the provider name Try refreshing the page and you should see the actual model name and other config values displayed!
…for LLM providers. Let me summarize what was accomplished:
★ Insight ─────────────────────────────────────
**Smart Naming Convention**: The updated code now creates descriptive provider names like "OpenAI-gpt-4" by:
1. Checking if the capability is 'llm'
2. Finding the 'model' config variable
3. Appending it to the base name if present and not a placeholder
This approach:
- Works for both templates and instances
- Only modifies display name, not the actual ID
- Gracefully handles missing or placeholder values
- Makes it immediately clear which model each provider uses without hovering
─────────────────────────────────────────────────
## Summary of All Changes
### 1. **Data Layer** (InstancesPage.tsx:591-598, 665-672)
- Templates and instances now generate display names that include the model for LLM providers
- Format: `{providerName}-{modelValue}` (e.g., "OpenAI-gpt-4")
- Only applies when capability is 'llm' and model value exists
### 2. **Display Values** (InstancesPage.tsx:567-568, 623-628)
- Changed `'(configured)'` → `'(set)'` for brevity
- Changed `'(default)'` → `'(set)'` for consistency
- Prioritized showing actual field values over placeholders
Now when you refresh the page, you should see:
- **Provider cards**: "OpenAI-gpt-4" instead of just "OpenAI"
- **Filled slots**: Provider name with model, plus config details below
- **Config values**: Actual values like "gpt-4" instead of "(configured)" or "default model"
- **Override highlighting**: Amber color for instance config that differs from template
The wiring board now provides complete configuration visibility at a glance!
…rtical padding (`py-3`). The provider cards have the config vars section below with `pb-2` to create some spacing, which is appropriate. ★ Insight ───────────────────────────────────── **Visual Consistency Pattern**: Consistent padding creates visual rhythm and makes UI elements feel cohesive. The key measurements here are: - **Provider card header**: `px-3 py-3` - matches the capability slot - **Capability slot**: `p-3` (equivalent to `px-3 py-3`) - **Config vars**: `px-3 pb-2 pt-0` - maintains horizontal alignment while reducing vertical space since it's supplementary info This creates a unified appearance where draggable items and drop targets have the same visual weight. ───────────────────────────────────────────────── The green capability slot cards and provider cards should now appear the same size. The `py-3` padding ensures they have identical vertical spacing, creating a more balanced and professional appearance in the wiring interface.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
on the instances/wiring page, when we drag a capability into service slot, there is not much info there. we will make some ui changes.
1: add a capability tag to the provider cards.
2: on the service slot, add the required type in the drop area instead of the label above. This will save on space and we can have a tighter view as we don't need the labels jutting out.
3: instead of showing something as "default", show the actual value, but show in a different colour if it's been overridden.