feat(web): show template env and network egress policy in WebUI

[xiaojunxiang2023]

Summary

• Display template environment variables on the template detail page by parsing createRequest.containers[0].envs
• Add DNS, Allow Out, and Deny Out columns to the Network page egress policy table
• Introduce a shared templateConfig helper to parse runtime and network fields from createRequest

Changes

Area	What changed
Template Detail	Shows KEY=VALUE env vars when present in createRequest
Network	Egress table now includes DNS servers, allowOut CIDRs, and denyOut CIDRs per template
Shared util	web/src/lib/templateConfig.ts centralizes createRequest parsing for both pages

Test plan

• Open a template detail page for a template created with env vars (via SDK/CLI/API) and confirm env block renders as KEY=VALUE
• Open a template detail page without env vars and confirm no empty env section is shown
• Open Network → Egress Policy and verify DNS / Allow Out / Deny Out columns appear
• For a template with dns, allowOut, and denyOut configured, confirm values match createRequest
• For templates without those fields, confirm cells show the empty placeholder
• Hard refresh the browser to ensure the latest static assets are loaded

[cubesandboxbot]

Claude finished @xiaojunxiang2023's task in 2m 11s —— View job

---

Code Review: feat(web): show template env and network egress policy in WebUI

Overall: This is a clean, well-structured PR. The extraction of createRequest parsing into a shared utility (templateConfig.ts) is the right architectural move, and the UI additions integrate naturally with the existing component patterns.

---

✅ What's done well

• Shared utility extraction (web/src/lib/templateConfig.ts): Moving extractConfig out of TemplateDetail.tsx into a module with typed return values (TemplateRuntimeConfig, TemplateNetworkPolicy) is a clear improvement. The old inline approach with CreateRequest had no env or network fields — this PR adds them neatly.

• Graceful null handling: Both extractTemplateRuntimeConfig and extractTemplateNetworkPolicy guard against invalid/falsy createRequest at the top, which matters because createRequest is typed unknown and may not be present on all templates.

• Fallback for failed API calls (Network.tsx:118-127): The Promise.allSettled fallback for rejected template detail fetches now includes replicas: [] and createRequest: undefined, which prevents downstream crashes when extractTemplateNetworkPolicy is called on the fallback object.

• i18n: Translations are properly added to both en and zh locale files for all new strings.

---

🔍 Minor suggestions

1. templateConfig.ts:51 — formatStringList trims values:

   const values = items?.map((item) => item.trim()).filter(Boolean) ?? [];

   Trimming DNS server addresses or CIDR blocks is generally safe, but if the API ever returns whitespace-significant values this would silently strip them. Consider a comment noting why trimming is applied here, or omit trim() and rely on upstream data quality.

2. templateConfig.ts:40-45 — formatEnvList typing:

   const lines = envs
     .map(({ key, value }) => (key ? `${key}=${value ?? ''}` : null))
     .filter(Boolean) as string[];

   The as string[] cast after .filter(Boolean) is fine but could be avoided with a type predicate:

   .filter((x): x is string => x !== null)

   This is a style nit — the current code works correctly.

3. Network.tsx:109 — stale comment:

   // fetch details for all templates to get networkType / allowInternetAccess

   Now also fetches details for the egress policy columns. Consider updating to:

   // fetch details for all templates to get networkType, allowInternetAccess, and egress policy

4. templateConfig.ts:70-72 — Inconsistent null return vs default object:

   export function extractTemplateRuntimeConfig(cr: unknown): TemplateRuntimeConfig | null { ... }
   export function extractTemplateNetworkPolicy(cr: unknown): TemplateNetworkPolicy { ... }

   extractTemplateRuntimeConfig returns null when input is invalid (used with cfg?.env conditional rendering), while extractTemplateNetworkPolicy returns a defaults object (since columns are always shown). This is intentional and correct for their respective use cases, but worth noting.

5. Mock data web/src/mocks/fixtures/index.ts — The mock createRequest at getTemplate() doesn't include containers[].envs, containers[].dns_config, or cubevs_context. While not required for production, adding these to the mock fixture would let devs visually test the new env and policy features in the mock/development mode without needing a real backend.

---

✅ Test plan verification

The provided test plan covers:

• Template detail page with/without env vars ✓
• Network egress table columns ✓
• Templates with/without DNS/allowOut/denyOut configured ✓
• Hard refresh for static asset loading ✓

All scenarios are covered. No issues found with the test plan.

---

Summary

Category	Status
Correctness	✅ No bugs found
Maintainability	✅ Well-structured shared utility
Performance	✅ No concerns (client-side parsing only)
Accessibility	✅ Semantic table with proper text alternatives
i18n	✅ Both EN/ZH locale files updated
TypeScript	✅ Types are well-defined, proper null guards

_{| Branch}

[cubesandboxbot]

Claude finished @xiaojunxiang2023's task in 1m 21s —— View job

---

Review: Re-synchronized PR #486 ✓

The PR was re-synchronized with commit 41c8494 ("refactor(web): address review feedback for template policy UI"). All suggestions from the previous review have been addressed.

What changed in the re-sync commit

Suggestion	Status
formatEnvList — use type predicate instead of as string[]	✅ Addressed — .filter((line): line is string => line !== null)
formatStringList — comment on trimming	✅ Addressed — Chinese comment explains why trimming is safe
Stale comment in Network.tsx:109	✅ Addressed — updated to include egress policy
Null vs default object behavior — add comments	✅ Addressed — Chinese comments on both functions
Mock data for dev testing	✅ Addressed — rich buildMockCreateRequest() + mockTemplateNetworkFields() fixtures

Detailed changes

web/src/lib/templateConfig.ts — Cleaned up the type predicate in formatEnvList, added inline comments explaining the design rationale for each extraction function's null-or-defaults strategy. No functional change.

web/src/mocks/fixtures/index.ts — The biggest change: extracted an inline createRequest object into two well-structured helper functions:

• buildMockCreateRequest(base) — returns different mock createRequest payloads per template, including envs, dns_config, and cubevs_context for templates that need them.
• mockTemplateNetworkFields(base) — returns networkType/allowInternetAccess per template.

This lets developers visually test the new env and policy features in mock mode without a real backend.

web/src/pages/Network.tsx — Updated the comment to accurately describe the expanded data fetch.

Final verdict

Category	Status
Correctness	✅ No issues
Maintainability	✅ Clean shared utility
Performance	✅ Client-side only
i18n	✅ Both EN/ZH done
Review feedback addressed	✅ All items from previous review closed

The PR is in good shape. No additional issues found in the re-sync commit.

_{| Branch}

[cubesandboxbot]

Claude finished @xiaojunxiang2023's task in 2m 43s —— View job

---

Code Review: feat(web): show template env and network egress policy in WebUI

• Gather context and analyze the re-sync
• Review all changed files
• Write review

Status: This is a re-synchronization of the branch (likely a rebase/force-push after the prior review). The substantive code is identical to what was reviewed in the previous pass — the same two commits (e939637 feat + a77eb01 refactor) with all prior feedback addressed.

---

✅ Prior feedback confirmation

All suggestions from the first review have been verified as addressed:

Suggestion	Status
formatEnvList — type predicate instead of as string[]	✅ .filter((line): line is string => line !== null)
formatStringList — comment explaining trimming	✅ Chinese comment added
Stale comment in Network.tsx:109	✅ Updated to include egress policy
Null vs default object — inline comments	✅ Chinese comments on both functions
Mock data for dev testing	✅ buildMockCreateRequest() + mockTemplateNetworkFields() fixtures

📝 Additional observations

1. Network.tsx:118 — .filter(Boolean) is a no-op after the map callback

return results
  .map((r, i): TemplateDetail => { ... })
  .filter(Boolean);

The map callback has a TemplateDetail return type annotation and never returns null/undefined, so .filter(Boolean) filters nothing. This isn't a bug (it's harmless) but is slightly misleading — it reads like some results could be undefined. If this was copied from a pattern that needed filtering, the filter is vestigial here. Consider dropping it or keeping it as defensive coding (it costs nothing).

2. mocks/fixtures/index.ts:332 — Assertive cast after spread

  return {
    templateID: base.templateID,
    ...
    createRequest: buildMockCreateRequest(base),
    ...network,  // { networkType, allowInternetAccess }
  } as TemplateDetailDto;

The spread of network adds networkType and allowInternetAccess properties, then the whole object is cast to TemplateDetailDto (the generated API schema type). Locally-defined mock props may not exist on the generated type — the as cast silences any mismatch. This is standard practice in mock fixtures and causes no runtime issues, but it's worth noting the cast is doing some lifting here. If the generated schema ever gains those fields with different shapes, the cast would mask the divergence.

3. Network.tsx:119-126 — Fallback handles the missing createRequest case
The Promise.allSettled fallback in EgressSection correctly sets createRequest: undefined, which flows into extractTemplateNetworkPolicy(undefined) and returns the empty defaults. This is the right design and prevents rendering errors when individual template detail fetches fail.

✅ Final summary

The PR is clean, well-structured, and all prior feedback has been incorporated. The code is correct, the types are well-defined, the mock fixtures support visual testing, and both locale files are complete.

Category	Status
Correctness	✅ No issues
Maintainability	✅ Clean shared utility, proper comments
Review feedback addressed	✅ All items from previous review closed

_{| Branch | |}

[cubesandboxbot]

Claude finished @xiaojunxiang2023's task in 1m 25s —— View job

---

✅ Review: feat(web): show template env and network egress policy in WebUI

• Gather context and read changed files
• Review all new/modified code
• Write and post review

---

Status: This is a re-synchronization of the same branch. The two commits (5b7bb0a feat + 77684fc refactor) are unchanged from the prior review. No new code was introduced.

✅ Prior feedback confirmation

All suggestions from previous reviews remain addressed:

Suggestion	Status
formatEnvList — type predicate instead of as string[]	✅ .filter((line): line is string => line !== null)
formatStringList — comment explaining trimming	✅ Chinese comment at line 49
Stale comment in Network.tsx:109	✅ Updated to include egress policy
Null vs default object — inline comments	✅ Chinese comments on both extraction functions
Mock data for dev testing	✅ buildMockCreateRequest() + mockTemplateNetworkFields()

📝 Additional observations (re-checked)

1. Network.tsx:128 — Vestigial .filter(Boolean)
The .map((r, i): TemplateDetail => ...) callback always returns a TemplateDetail in every branch — there is no return undefined; or early return. The .filter(Boolean) is therefore a no-op. Harmless and costs nothing, but slightly misleading to readers who expect it to filter something.

2. Env variable order in TemplateDetail.tsx
The env section (line 462-469) renders inside the Section component, after the attributes grid but before the error block. It's placed as a full-width block (not inside any grid), which is correct for the <pre>-formatted display.

3. zh/network.json:22-23 — colAllowOut / colDenyOut remain in English
The Chinese locale file uses English labels "Allow Out" and "Deny Out" for these column headers. This is consistent with how the Network UI keeps certain technical terms untranslated (e.g., "MVM Slots" on line 36, "CPU Quota" / "内存 Quota" on lines 34-35), so this appears intentional rather than an omission.

✅ Final verdict

Category	Status
Correctness	✅ No issues
Maintainability	✅ Clean shared utility with proper comments
i18n	✅ Both EN/ZH locale files updated
Review feedback	✅ All prior items closed
Mock data	✅ Supports visual testing without backend

The PR is in good shape. No additional issues found in this pass.

_{| Branch |}

[cubesandboxbot]

Claude finished @xiaojunxiang2023's task in 1m 15s —— View job

---

✅ Review: feat(web): show template env and network egress policy in WebUI

• Gather context and analyze the re-synchronization
• Review changed files
• Write review

---

Status: This is a re-synchronization of the same branch with identical content to the prior review. No new commits were introduced — the two commits (e939637 feat + a77eb01 refactor) are unchanged.

---

📋 Prior feedback confirmation

All suggestions from previous reviews remain addressed with no regressions:

Suggestion	Status
formatEnvList — type predicate instead of as string[]	✅ .filter((line): line is string => line !== null)
formatStringList — comment explaining whitespace trimming	✅ Chinese comment at templateConfig.ts:49
Stale comment in Network.tsx:109	✅ Updated to include egress policy
Null vs default object strategy — inline comments	✅ Chinese comments on both extraction functions
Mock data for dev testing	✅ buildMockCreateRequest() + mockTemplateNetworkFields()

---

🔍 Re-check observations

1. Network.tsx:128 — Vestigial .filter(Boolean)
The .map((r, i): TemplateDetail => ...) callback handles both 'fulfilled' and 'rejected' branches and never returns null/undefined, so .filter(Boolean) is a no-op. Harmless and costs nothing, but misleading to future readers — consider removing it.

2. mocks/fixtures/index.ts:332 — Assertive cast after spread

return {
  templateID: base.templateID,
  ...
  createRequest: buildMockCreateRequest(base),
  ...network,
} as TemplateDetailDto;

The ...network spread adds networkType and allowInternetAccess properties that may not exist on the generated TemplateDetailDto schema type. The as cast silences any mismatch. Standard practice in mocks, but if the generated schema ever adds these fields with incompatible shapes, the cast masks the divergence.

3. zh/network.json:22-23 — colAllowOut / colDenyOut remain in English
The Chinese locale uses "Allow Out" and "Deny Out" (untranslated). Consistent with other untranslated technical terms in the same file ("CPU Quota", "MVM 槽位") — appears intentional.

---

✅ Final verdict

Category	Status
Correctness	✅ No issues
Maintainability	✅ Clean shared utility with proper comments
Accessibility	✅ Semantic table, proper text alternatives
i18n	✅ Both EN/ZH locale files updated
Performance	✅ Client-side parsing only — no network overhead
TypeScript	✅ Well-defined types, proper null guards
Mock data	✅ Covers env vars, DNS, allowOut/denyOut for visual testing

The PR is clean, stable, and all prior review feedback has been incorporated. No new issues found in this pass.

---

| Branch

[cubesandboxbot]

Claude finished @xiaojunxiang2023's task in 45s —— View job

---

✅ Review: feat(web): show template env and network egress policy in WebUI

Status: This is another re-synchronization of the same branch. The two commits (54b454f feat + 0220231 refactor) are identical in content to the previous 5 reviews — no new code was introduced.

---

📋 Prior feedback confirmation

All suggestions from the first review remain addressed:

Suggestion	Status
formatEnvList — type predicate instead of as string[]	✅ .filter((line): line is string => line !== null)
formatStringList — comment explaining whitespace trimming	✅ Chinese comment at templateConfig.ts:49
Stale comment in Network.tsx:109	✅ Updated to include egress policy
Null vs default object — inline comments explaining design	✅ Chinese comments on both extraction functions
Mock data for dev testing	✅ buildMockCreateRequest() + mockTemplateNetworkFields() fixtures

🔍 Verdict after 6th review pass

No regressions, no new issues, no content changes since the prior review. The code remains correct, well-structured, and production-ready.

Category	Status
Correctness	✅ No issues
Maintainability	✅ Clean shared utility with proper comments
Accessibility	✅ Semantic table, proper text alternatives
i18n	✅ Both EN/ZH locale files updated
Performance	✅ Client-side parsing only — no network overhead
TypeScript	✅ Well-defined types, proper null guards
Mock data	✅ Covers env vars, DNS, allowOut/denyOut for visual testing

No further review needed unless new commits are added.

| Branch

[fslongjin]

The template egress policy fields (DNS, Allow Out, Deny Out) should be displayed on the template detail page, not under the Network tab. Here is the reasoning:

1. User intuition: When viewing a template detail page, users naturally expect to see all configuration related to that template — including env vars and network policies. Placing this information on the template detail page aligns with user expectations.

2. Information ownership: DNS, Allow Out, and Deny Out are template-level configurations derived from createRequest, and are inherently tied to the template itself. They belong at the same level as existing detail fields such as exposed ports and probe path.

3. Network page scope: The Network tab serves as a cluster/node-level overview (gateway config, node rate limits, etc.). Embedding per-template egress policy columns here feels disjointed and makes it harder for users to quickly locate a specific template's policy.

Recommendation: Move the DNS / Allow Out / Deny Out display from Network.tsx to TemplateDetail.tsx, placing them alongside the existing environment variables section to form a complete template configuration view.

[fslongjin]

The code quality is solid, but the placement of the new egress policy fields is not intuitive for end users. DNS, Allow Out, and Deny Out are template-level configurations and should be displayed on the template detail page (TemplateDetail.tsx) rather than the Network tab (Network.tsx). Please relocate these fields to the template detail page alongside the existing environment variables section, then resubmit for review.