feat: Topology view#3395
Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughThis PR adds a Topology route and page, introduces topology endpoint and diagram generation, refactors Canvas to consume precomputed nodes and edges, and wires new DesignerVisualization and TopologyVisualization components into the UI. ChangesTopology View
Estimated code review effort: 4 (Complex) | ~60 minutes Sequence Diagram(s)sequenceDiagram
participant TopologyPage
participant TopologyVisualization
participant FlowService
participant topology-endpoints
participant Canvas
TopologyPage->>TopologyVisualization: render(entities)
TopologyVisualization->>FlowService: getTopologyFlowDiagram(vizNodes)
FlowService->>topology-endpoints: collectTopologyEndpoints(vizNodes)
topology-endpoints-->>FlowService: registry (consumers/producers)
FlowService-->>TopologyVisualization: topology nodes/edges
TopologyVisualization->>Canvas: render(nodes, edges, isModelResolving)
Possibly related PRs
Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (2 warnings)
✅ Passed checks (3 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@packages/ui/src/components/Visualization/Canvas/flow.service.ts`:
- Around line 11-12: The relationship tracking in FlowService is using
array-like overwrites instead of set semantics, which can drop shared consumers
and allow duplicate producer endpoints. Update the recording logic in the
FlowService methods that populate consumersByEndpoint and outgoingByEntity so
endpoint/entity IDs are accumulated uniquely rather than replaced or duplicated,
and make sure edge creation/lookup uses the deduplicated collections to avoid
repeated ${source} >>> ${target} entries.
- Around line 154-158: Reset the static topology relationship maps in
getTopologyFlowDiagram() before rebuilding the diagram: alongside nodes, edges,
and visitedNodes, also clear consumersByEndpoint and outgoingByEntity so stale
relationships from prior renders do not leak into the next topology view. Use
the getTopologyFlowDiagram method and the static maps
consumersByEndpoint/outgoingByEntity as the place to fix this initialization.
In `@packages/ui/src/pages/Topology/TopologyPage.tsx`:
- Line 12: The Topology page component is missing the `.topology-page` class
that `TopologyPage.scss` relies on for layout and topology-specific overrides.
Update `TopologyPage` so the `Visualization` render includes the topology page
class in addition to the existing `canvas-page` class, keeping both if needed,
so the styles scoped under `.topology-page` apply correctly.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: b1f05f6e-fcb8-4149-8473-d0561387da9e
⛔ Files ignored due to path filters (1)
packages/ui/src/layout/__snapshots__/Navigation.test.tsx.snapis excluded by!**/*.snap
📒 Files selected for processing (20)
.gitignorepackages/ui/src/components/Visualization/Canvas/Canvas.tsxpackages/ui/src/components/Visualization/Canvas/controller.service.test.tspackages/ui/src/components/Visualization/Canvas/controller.service.tspackages/ui/src/components/Visualization/Canvas/flow.service.tspackages/ui/src/components/Visualization/Custom/Edge/TopologyEdge.tsxpackages/ui/src/components/Visualization/Custom/Node/CustomNode.tsxpackages/ui/src/components/Visualization/Custom/Node/CustomNodeLabels.tsxpackages/ui/src/components/Visualization/Custom/Node/TopologyNode.tsxpackages/ui/src/components/Visualization/Custom/topology-anchor.test.tspackages/ui/src/components/Visualization/Custom/topology-anchor.tspackages/ui/src/components/Visualization/Visualization.tsxpackages/ui/src/layout/Navigation.tsxpackages/ui/src/models/visualization/flows/abstract-camel-visual-entity.tspackages/ui/src/pages/Topology/TopologyPage.scsspackages/ui/src/pages/Topology/TopologyPage.tsxpackages/ui/src/pages/Topology/index.tspackages/ui/src/pages/Topology/router-exports.tsxpackages/ui/src/router.tsxpackages/ui/src/router/links.models.ts
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
packages/ui/src/components/Visualization/Canvas/flow.service.ts (1)
194-204: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winInconsistent fallback for
labelvsid.
idfalls back tovizNodeParam.idwhengetId()is undefined, butlabeldoes not, so a route without an explicit id would render with an undefined label.🐛 Suggested fix
private static getTopologyNode(vizNodeParam: IVisualizationNode): CanvasNode { return { id: vizNodeParam.getId() ?? vizNodeParam.id, type: 'topology-node', - label: vizNodeParam.getId(), + label: vizNodeParam.getId() ?? vizNodeParam.id, data: { vizNode: vizNodeParam },🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@packages/ui/src/components/Visualization/Canvas/flow.service.ts` around lines 194 - 204, The getTopologyNode method in flow.service.ts uses a fallback for id but not for label, which can leave topology nodes unlabeled when getId() is missing. Update getTopologyNode so the label uses the same fallback as id, based on vizNodeParam.getId() ?? vizNodeParam.id, keeping the CanvasNode fields consistent.
🧹 Nitpick comments (1)
packages/ui/src/utils/camel-uri-helper.ts (1)
269-290: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueMinor duplication with
getUriString.
getEndpointre-implements the same string/uri-extraction checks already ingetUriStringbefore adding theparameters.namesuffix logic. Could be expressed by delegating togetUriStringfirst.♻️ Optional refactor to reduce duplication
static getEndpoint(value: unknown): string | undefined { - /** For string-based processor definitions, we can return the definition itself */ - if (typeof value === 'string' && value !== '') { - return value; - } - - const uriString = getValue(value, 'uri'); - - /** For object-based processor definitions, we can return the `uri` property if not empty */ - if (typeof uriString === 'string' && uriString !== '') { - if (!uriString.includes(':')) { + const uriString = this.getUriString(value); + if (typeof uriString === 'string' && uriString !== '') { + if (!uriString.includes(':')) { const name = getValue(value, 'parameters.name'); if (typeof name === 'string' && name.trim() !== '') { return `${uriString}:${name.trim()}`; } } return uriString; } - return undefined; }🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@packages/ui/src/utils/camel-uri-helper.ts` around lines 269 - 290, `getEndpoint` duplicates the same string and `uri` extraction logic already present in `getUriString`; refactor it to delegate to `getUriString` first, then apply only the `parameters.name` suffix handling when the returned URI does not already contain a colon. Keep the existing behavior for plain string inputs and empty/undefined values, but remove the repeated `getValue(value, 'uri')`/type-check branch from `getEndpoint` by reusing `getUriString`.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@packages/ui/src/components/Visualization/Topology/topology-endpoints.ts`:
- Around line 4-6: Restore the missing topology coverage in topology-endpoints
by updating TOPOLOGY_PRODUCER_KEYS to include enrich and pollEnrich again, and
expanding IN_VM_ENDPOINT_PREFIXES to include vm: and direct-vm: alongside the
existing prefixes. Make the change in the topology-endpoints constants so any
topology-building logic that consumes these symbols continues to detect those
routes and endpoints.
---
Outside diff comments:
In `@packages/ui/src/components/Visualization/Canvas/flow.service.ts`:
- Around line 194-204: The getTopologyNode method in flow.service.ts uses a
fallback for id but not for label, which can leave topology nodes unlabeled when
getId() is missing. Update getTopologyNode so the label uses the same fallback
as id, based on vizNodeParam.getId() ?? vizNodeParam.id, keeping the CanvasNode
fields consistent.
---
Nitpick comments:
In `@packages/ui/src/utils/camel-uri-helper.ts`:
- Around line 269-290: `getEndpoint` duplicates the same string and `uri`
extraction logic already present in `getUriString`; refactor it to delegate to
`getUriString` first, then apply only the `parameters.name` suffix handling when
the returned URI does not already contain a colon. Keep the existing behavior
for plain string inputs and empty/undefined values, but remove the repeated
`getValue(value, 'uri')`/type-check branch from `getEndpoint` by reusing
`getUriString`.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 4d39344e-f1d0-44bc-8ed1-fda982253c69
📒 Files selected for processing (5)
packages/ui/src/components/Visualization/Canvas/flow.service.test.tspackages/ui/src/components/Visualization/Canvas/flow.service.tspackages/ui/src/components/Visualization/Topology/topology-endpoints.test.tspackages/ui/src/components/Visualization/Topology/topology-endpoints.tspackages/ui/src/utils/camel-uri-helper.ts
| return result; | ||
| } | ||
|
|
||
| static getEndpoint(value: unknown): string | undefined { |
There was a problem hiding this comment.
Could it be possible that we have this logic somewhere already?
There was a problem hiding this comment.
We have several similar implementations already (including one in the same camel-uri-helper file), but none that solve this exact use case.
getUriString() simply returns the URI as it appears in the source. What we need here is the URI in a normalized format (e.g. direct:component-name), regardless of how the Direct component is defined in the source code.
This is necessary because we need to support all formats that users can provide on the Source Code page, for example:
uri: direct parameters: name: test-wiretap block: false
and
uri: direct:test-wiretap?block= false
Both should resolve to the same normalized URI format.
Please let me know if you think this can be handled differently.
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
packages/ui/src/components/Visualization/Canvas/flow.service.ts (1)
194-199: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winUse the same fallback for topology labels as topology IDs.
Line 198 can leave the node label undefined when
getId()is absent, even though Line 196 still creates a valid id. That can render unlabeled topology nodes.Proposed fix
private static getTopologyNode(vizNodeParam: IVisualizationNode): CanvasNode { + const id = vizNodeParam.getId() ?? vizNodeParam.id; + return { - id: vizNodeParam.getId() ?? vizNodeParam.id, + id, type: 'topology-node', - label: vizNodeParam.getId(), + label: id, data: { vizNode: vizNodeParam },🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@packages/ui/src/components/Visualization/Canvas/flow.service.ts` around lines 194 - 199, The getTopologyNode method in flow.service.ts is using getId() for label without the same fallback used for id, which can leave topology nodes unlabeled. Update the label assignment in getTopologyNode so it falls back to vizNodeParam.id whenever getId() is unavailable, matching the existing id logic and keeping topology nodes labeled consistently.
🧹 Nitpick comments (4)
packages/ui/src/components/Visualization/TopologyVisualization.tsx (3)
16-47: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winMissing dedicated test coverage for
TopologyVisualization.Unlike
DesignerVisualization, which hasDesignerVisualization.test.tsxcovering prop wiring toCanvas, there's no equivalent test file forTopologyVisualizationin this cohort. Given the identical structure, mirroring the existing test suite (mocking./topology-canvas-modeland./Canvas) should be straightforward.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@packages/ui/src/components/Visualization/TopologyVisualization.tsx` around lines 16 - 47, Add dedicated test coverage for TopologyVisualization by mirroring the existing DesignerVisualization test pattern: create a TopologyVisualization test that mocks useVisibleVizNodes, buildTopologyCanvasModel, and ./Canvas, then verifies TopologyVisualization wires className, fallback, contextToolbar, entitiesCount, visibleEntitiesCount, nodes, edges, and isModelResolving correctly. Use the TopologyVisualization component and its Canvas/model helpers as the main symbols to locate the code.
22-25: 🚀 Performance & Scalability | 🔵 Trivial | ⚡ Quick winQuadratic
allFlowsVisibleconstruction.Building the map via
reduce((acc, entity) => ({ ...acc, [entity.id]: true }), {})spreads the accumulator on every iteration, making this O(n²) for n entities. UseObject.fromEntries(or a plain loop) for O(n) construction.⚡ Proposed fix
- const allFlowsVisible = useMemo( - () => entities.reduce<Record<string, boolean>>((acc, entity) => ({ ...acc, [entity.id]: true }), {}), - [entities], - ); + const allFlowsVisible = useMemo( + () => Object.fromEntries(entities.map((entity) => [entity.id, true])), + [entities], + );🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@packages/ui/src/components/Visualization/TopologyVisualization.tsx` around lines 22 - 25, The allFlowsVisible map in TopologyVisualization uses a reduce spread pattern that recreates the accumulator on every entity, causing quadratic construction time. Update the useMemo block that builds allFlowsVisible to use an O(n) approach such as Object.fromEntries or a simple loop, while preserving the same entity.id to true mapping.
26-33: 🚀 Performance & Scalability | 🔵 TrivialSequential resolution may not scale for topology view.
useVisibleVizNodesresolvesvizNodes one at a time withawaitinside aforloop. SinceTopologyVisualizationnow forces every entity to be "visible" (line 22-25), it will resolve strictly more entities than the Designer view typically does for a given user session, making this sequential bottleneck more likely to matter for large route sets. Worth keeping an eye on once real-world topology sizes are exercised; parallelizing withPromise.allin the hook would help if this becomes a bottleneck.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@packages/ui/src/components/Visualization/TopologyVisualization.tsx` around lines 26 - 33, The topology view now drives more entity resolution through useVisibleVizNodes, and the current sequential await-in-loop approach can become a bottleneck for large route sets. Update the hook’s resolution logic to fetch the visible vizNodes in parallel instead of one-by-one, using Promise.all or an equivalent batched pattern, while keeping the TopologyVisualization consumer unchanged.packages/ui/src/components/Visualization/DesignerVisualization.tsx (1)
17-46: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winConsider extracting shared logic with
TopologyVisualization.
DesignerVisualizationandTopologyVisualizationshare nearly identical structure: resolve viz nodes viauseVisibleVizNodes, memoize a{nodes, edges}model whileisResolving, then wrapCanvasinVisualizationShell. The only real differences are the flows source and thebuild*CanvasModelfunction/applyCollapseOnUpdateflag. Extracting a shared hook (e.g.useCanvasModel(entities, visibleFlows, buildFn)) would remove this duplication and keep both variants in sync as the model-building logic evolves.♻️ Sketch of a shared hook
function useCanvasModel( entities: BaseVisualEntity[], visibleFlows: Record<string, boolean>, buildModel: (vizNodes: IVisualizationNode[]) => CanvasNodesAndEdges, ) { const { vizNodes, isResolving } = useVisibleVizNodes(entities, visibleFlows); const { nodes, edges } = useMemo(() => { if (isResolving) { return { nodes: [], edges: [] }; } return buildModel(vizNodes); }, [vizNodes, isResolving, buildModel]); return { nodes, edges, vizNodes, isResolving }; }🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@packages/ui/src/components/Visualization/DesignerVisualization.tsx` around lines 17 - 46, `DesignerVisualization` duplicates the same canvas-model flow as `TopologyVisualization`, so extract the shared `useVisibleVizNodes` + `useMemo` logic into a reusable hook such as `useCanvasModel` that accepts `entities`, `visibleFlows`, and a build function. Update `DesignerVisualization` to consume that hook and keep only the variant-specific pieces (`buildDesignerCanvasModel`, `applyCollapseOnUpdate`, and the `Canvas` props). Also align the corresponding `TopologyVisualization` implementation to use the same shared hook so both components stay in sync.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Outside diff comments:
In `@packages/ui/src/components/Visualization/Canvas/flow.service.ts`:
- Around line 194-199: The getTopologyNode method in flow.service.ts is using
getId() for label without the same fallback used for id, which can leave
topology nodes unlabeled. Update the label assignment in getTopologyNode so it
falls back to vizNodeParam.id whenever getId() is unavailable, matching the
existing id logic and keeping topology nodes labeled consistently.
---
Nitpick comments:
In `@packages/ui/src/components/Visualization/DesignerVisualization.tsx`:
- Around line 17-46: `DesignerVisualization` duplicates the same canvas-model
flow as `TopologyVisualization`, so extract the shared `useVisibleVizNodes` +
`useMemo` logic into a reusable hook such as `useCanvasModel` that accepts
`entities`, `visibleFlows`, and a build function. Update `DesignerVisualization`
to consume that hook and keep only the variant-specific pieces
(`buildDesignerCanvasModel`, `applyCollapseOnUpdate`, and the `Canvas` props).
Also align the corresponding `TopologyVisualization` implementation to use the
same shared hook so both components stay in sync.
In `@packages/ui/src/components/Visualization/TopologyVisualization.tsx`:
- Around line 16-47: Add dedicated test coverage for TopologyVisualization by
mirroring the existing DesignerVisualization test pattern: create a
TopologyVisualization test that mocks useVisibleVizNodes,
buildTopologyCanvasModel, and ./Canvas, then verifies TopologyVisualization
wires className, fallback, contextToolbar, entitiesCount, visibleEntitiesCount,
nodes, edges, and isModelResolving correctly. Use the TopologyVisualization
component and its Canvas/model helpers as the main symbols to locate the code.
- Around line 22-25: The allFlowsVisible map in TopologyVisualization uses a
reduce spread pattern that recreates the accumulator on every entity, causing
quadratic construction time. Update the useMemo block that builds
allFlowsVisible to use an O(n) approach such as Object.fromEntries or a simple
loop, while preserving the same entity.id to true mapping.
- Around line 26-33: The topology view now drives more entity resolution through
useVisibleVizNodes, and the current sequential await-in-loop approach can become
a bottleneck for large route sets. Update the hook’s resolution logic to fetch
the visible vizNodes in parallel instead of one-by-one, using Promise.all or an
equivalent batched pattern, while keeping the TopologyVisualization consumer
unchanged.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: fe3d62c2-ee5b-4535-a681-f2df8dbf75e4
📒 Files selected for processing (20)
packages/ui-tests/stories/canvas/Canvas.stories.tsxpackages/ui/src/components/Visualization/Canvas/Canvas.test.tsxpackages/ui/src/components/Visualization/Canvas/Canvas.tsxpackages/ui/src/components/Visualization/Canvas/flow.service.tspackages/ui/src/components/Visualization/Custom/Node/CustomNode.tsxpackages/ui/src/components/Visualization/Custom/Node/CustomNodeLabel.tsxpackages/ui/src/components/Visualization/Custom/Node/TopologyNode.tsxpackages/ui/src/components/Visualization/DesignerVisualization.test.tsxpackages/ui/src/components/Visualization/DesignerVisualization.tsxpackages/ui/src/components/Visualization/TopologyVisualization.tsxpackages/ui/src/components/Visualization/Visualization.tsxpackages/ui/src/components/Visualization/VisualizationShell.tsxpackages/ui/src/components/Visualization/designer-canvas-model.tspackages/ui/src/components/Visualization/index.tspackages/ui/src/components/Visualization/topology-canvas-model.tspackages/ui/src/external/RouteVisualization/RouteVisualization.tsxpackages/ui/src/pages/Design/DesignPage.tsxpackages/ui/src/pages/Topology/TopologyPage.scsspackages/ui/src/pages/Topology/TopologyPage.tsxpackages/ui/src/router/links.models.ts
💤 Files with no reviewable changes (2)
- packages/ui/src/components/Visualization/Custom/Node/CustomNodeLabel.tsx
- packages/ui/src/components/Visualization/Visualization.tsx
✅ Files skipped from review due to trivial changes (2)
- packages/ui/src/pages/Design/DesignPage.tsx
- packages/ui/src/router/links.models.ts
🚧 Files skipped from review as they are similar to previous changes (2)
- packages/ui/src/components/Visualization/Custom/Node/TopologyNode.tsx
- packages/ui/src/components/Visualization/Custom/Node/CustomNode.tsx
ec964c6 to
19dbbc5
Compare
19dbbc5 to
b2a7e29
Compare
There was a problem hiding this comment.
🧹 Nitpick comments (1)
packages/ui/src/utils/camel-uri-helper.test.ts (1)
26-50: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueTest coverage looks correct; title format for object inputs is non-descriptive.
Verified all 21 cases against
CamelUriHelper.getEndpoint's implementation — expectations match, includingparameters.namewhitespace trimming and invalid-input handling. Minor nit: the%splaceholders will stringify object inputs (e.g.{ uri: {} },{ uri: 'direct', parameters: { name: 'foo' } }) to something like[object Object], producing indistinguishable/uninformative test names in the runner output for several cases. Consider using%jor a custom title function for clearer output.♻️ Optional: improve test title readability
- ])('should return `%s` for `%s`', (value, expected) => { + ])('should return `%j` for `%j`', (value, expected) => {🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@packages/ui/src/utils/camel-uri-helper.test.ts` around lines 26 - 50, The test cases for CamelUriHelper.getEndpoint are correct, but the it.each title in camel-uri-helper.test.ts uses %s, which makes object inputs render as unhelpful [object Object] strings. Update the parameterized test title to use a JSON-friendly or custom title format so the different object-shaped inputs are distinguishable in runner output, while keeping the existing expectations unchanged.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@packages/ui/src/utils/camel-uri-helper.test.ts`:
- Around line 26-50: The test cases for CamelUriHelper.getEndpoint are correct,
but the it.each title in camel-uri-helper.test.ts uses %s, which makes object
inputs render as unhelpful [object Object] strings. Update the parameterized
test title to use a JSON-friendly or custom title format so the different
object-shaped inputs are distinguishable in runner output, while keeping the
existing expectations unchanged.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: dd61b8e2-8d17-46bf-b153-ea610fb5552f
⛔ Files ignored due to path filters (1)
packages/ui/src/layout/__snapshots__/Navigation.test.tsx.snapis excluded by!**/*.snap
📒 Files selected for processing (36)
.gitignorepackages/ui-tests/stories/canvas/Canvas.stories.tsxpackages/ui/src/components/Visualization/Canvas/Canvas.test.tsxpackages/ui/src/components/Visualization/Canvas/Canvas.tsxpackages/ui/src/components/Visualization/Canvas/controller.service.test.tspackages/ui/src/components/Visualization/Canvas/controller.service.tspackages/ui/src/components/Visualization/Canvas/flow.service.test.tspackages/ui/src/components/Visualization/Canvas/flow.service.tspackages/ui/src/components/Visualization/Custom/Edge/TopologyEdge.tsxpackages/ui/src/components/Visualization/Custom/Node/CustomNode.tsxpackages/ui/src/components/Visualization/Custom/Node/CustomNodeLabel.tsxpackages/ui/src/components/Visualization/Custom/Node/TopologyNode.tsxpackages/ui/src/components/Visualization/Custom/topology-anchor.test.tspackages/ui/src/components/Visualization/Custom/topology-anchor.tspackages/ui/src/components/Visualization/DesignerVisualization.test.tsxpackages/ui/src/components/Visualization/DesignerVisualization.tsxpackages/ui/src/components/Visualization/Topology/topology-endpoints.test.tspackages/ui/src/components/Visualization/Topology/topology-endpoints.tspackages/ui/src/components/Visualization/TopologyVisualization.tsxpackages/ui/src/components/Visualization/Visualization.tsxpackages/ui/src/components/Visualization/VisualizationShell.tsxpackages/ui/src/components/Visualization/designer-canvas-model.tspackages/ui/src/components/Visualization/index.tspackages/ui/src/components/Visualization/topology-canvas-model.tspackages/ui/src/external/RouteVisualization/RouteVisualization.tsxpackages/ui/src/layout/Navigation.tsxpackages/ui/src/models/visualization/flows/abstract-camel-visual-entity.tspackages/ui/src/pages/Design/DesignPage.tsxpackages/ui/src/pages/Topology/TopologyPage.scsspackages/ui/src/pages/Topology/TopologyPage.tsxpackages/ui/src/pages/Topology/index.tspackages/ui/src/pages/Topology/router-exports.tsxpackages/ui/src/router.tsxpackages/ui/src/router/links.models.tspackages/ui/src/utils/camel-uri-helper.test.tspackages/ui/src/utils/camel-uri-helper.ts
💤 Files with no reviewable changes (1)
- packages/ui/src/components/Visualization/Visualization.tsx
✅ Files skipped from review due to trivial changes (8)
- packages/ui/src/pages/Topology/router-exports.tsx
- packages/ui/src/router/links.models.ts
- packages/ui/src/pages/Topology/TopologyPage.scss
- packages/ui/src/pages/Topology/index.ts
- packages/ui/src/components/Visualization/topology-canvas-model.ts
- packages/ui/src/components/Visualization/Canvas/controller.service.test.ts
- .gitignore
- packages/ui/src/layout/Navigation.tsx
🚧 Files skipped from review as they are similar to previous changes (26)
- packages/ui/src/components/Visualization/Custom/topology-anchor.ts
- packages/ui/src/router.tsx
- packages/ui/src/components/Visualization/index.ts
- packages/ui/src/components/Visualization/Topology/topology-endpoints.test.ts
- packages/ui/src/components/Visualization/VisualizationShell.tsx
- packages/ui/src/components/Visualization/DesignerVisualization.tsx
- packages/ui/src/external/RouteVisualization/RouteVisualization.tsx
- packages/ui/src/pages/Design/DesignPage.tsx
- packages/ui/src/components/Visualization/Custom/Node/CustomNode.tsx
- packages/ui/src/utils/camel-uri-helper.ts
- packages/ui/src/components/Visualization/Custom/Node/CustomNodeLabel.tsx
- packages/ui/src/components/Visualization/Custom/Edge/TopologyEdge.tsx
- packages/ui/src/components/Visualization/Custom/topology-anchor.test.ts
- packages/ui/src/components/Visualization/designer-canvas-model.ts
- packages/ui/src/pages/Topology/TopologyPage.tsx
- packages/ui/src/components/Visualization/Canvas/controller.service.ts
- packages/ui/src/components/Visualization/Canvas/flow.service.test.ts
- packages/ui/src/components/Visualization/DesignerVisualization.test.tsx
- packages/ui/src/models/visualization/flows/abstract-camel-visual-entity.ts
- packages/ui/src/components/Visualization/Canvas/flow.service.ts
- packages/ui/src/components/Visualization/Custom/Node/TopologyNode.tsx
- packages/ui/src/components/Visualization/TopologyVisualization.tsx
- packages/ui/src/components/Visualization/Topology/topology-endpoints.ts
- packages/ui-tests/stories/canvas/Canvas.stories.tsx
- packages/ui/src/components/Visualization/Canvas/Canvas.test.tsx
- packages/ui/src/components/Visualization/Canvas/Canvas.tsx
5092f0c to
527dea3
Compare
29599de to
ef349fa
Compare
ef349fa to
4ed6a3f
Compare
|



Resolves #769
Try out and test this new feature here: https://shivamg640.github.io/kaoto/#/
Summary by CodeRabbit