fix: render SOVD resources for nested entity types#73
Merged
Conversation
There was a problem hiding this comment.
Pull request overview
Fixes the entity detail view so subcomponent entities render and fetch SOVD resources the same way as component entities, aligning UI behavior with how the gateway serves subcomponent resources (via the components API namespace).
Changes:
- Map
subcomponent→componentsfor refresh and API entity-type routing. - Treat
subcomponentas a component inEntityDetailPanelso the resource tab bar renders and resource counts/data are fetched. - Add a regression test ensuring subcomponents prefetch counts as
componentsand render the full resource tab set.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
src/lib/store.ts |
Ensures Refresh re-fetches subcomponents using the components API type mapping. |
src/components/EntityDetailPanel.tsx |
Enables resource fetching + tab rendering + header styling for subcomponent entities. |
src/components/EntityDetailPanel.test.tsx |
Adds a regression test covering the subcomponent tab bar and counts prefetch behavior. |
mfaferek93
reviewed
May 16, 2026
Subcomponent and subarea entities are served via /api/v1/components/{id}
and /api/v1/areas/{id} and expose the full SOVD resource set, but the UI
only branched on type === 'component' / 'area'. Nested entities fell
through to a bare header and the "No detailed information available"
fallback, were filtered out of search, and got the wrong breadcrumb icon.
- EntityDetailPanel: treat 'subcomponent' like 'component' and 'subarea'
like 'area' for resource fetching, tab/panel rendering, the API type
mapping, and the header type-icon / background.
- Breadcrumb segments resolve their entity type from the loaded tree
(findNode) instead of position-based inference, so nested types get the
correct icon; getBreadcrumbIcon gains subcomponent / subarea cases.
- SearchCommand: index subcomponent / subarea with their own icon, color,
and result group so they are findable.
- Regression tests cover the subcomponent tab bar and the subarea panel,
asserting counts prefetch with the correct resource type.
bburda
force-pushed
the
fix/subcomponent-resource-tabs
branch
from
9e5f28a to
8a40380
Compare
bburda
changed the title
mfaferek93
approved these changes
May 17, 2026
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
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.
Summary
Subcomponent and subarea entities (served through the
componentsandareasAPI namespaces) expose the full SOVD resource set, but the UI only branched ontype === 'component'/type === 'area'. Nested entities fell through to a bare header and the "No detailed information available for this entity." fallback, were filtered out of search, and rendered the wrong breadcrumb icon.This change treats
'subcomponent'like'component'and'subarea'like'area':EntityDetailPanel: the resource-count prefetch andfetchEntityData, the tab bar / panel render branch, the header icon/background helpers, and thegetEntityTypeForApimapping.findNode) instead of position-based inference, so nested types and deeper hierarchies get the correct icon.getBreadcrumbIcongainssubcomponent/subareacases.SearchCommand:getEntityIcon/getEntityColorClassand the result grouping now includesubcomponent/subarea, so they are findable.Store-side refresh routing already maps both types through the shared
NODE_TYPE_TO_RESOURCEmap onmain.Issue
Type
Testing
EntityDetailPanel.test.tsxmounts the panel withselectedEntity.type === 'subcomponent'and'subarea': the subcomponent renders the resource tab set and prefetches counts ascomponents; the subarea renders the area panel and prefetches counts asareas. Both assert the "No detailed information available" fallback is absent.npm test(414 passed).npm run lintandnpm run typecheckare clean.npm run buildsucceeds.Checklist
npm run lint)npm run build)