ant-design-pro's request config carries the highest activity risk — 4 hotspots to address

Ant-design-pro’s highest structural risk is concentrated in three layers: request error handling, mock data rules, and the main table-list page component. Together, these 4 critical functions account for activity-risk scores of 10–12, driven by a combination of high fan-out (9–19 distinct function calls) and multiple control-flow exit paths. Ant-design-pro is a TypeScript-based admin dashboard scaffold with 162 total functions; 4 are flagged as critical priority.

The table below ranks functions by activity-weighted risk — a score that multiplies structural complexity by recent commit frequency. A function that is both hard to understand (high cyclomatic complexity) and actively changing is a higher priority than one that is complex but untouched. CC = cyclomatic complexity (independent execution paths); ND = max nesting depth; FO = fan-out (distinct callees).

Top 5 Hotspots

Function	File	Risk	CC	ND	FO
<anonymous>	src/requestErrorConfig.ts	12.1	19	3	3
postRule	mock/listTableList.ts	11.8	13	2	11
<anonymous>	src/pages/table-list/index.tsx	10.7	6	1	19
getRule	mock/listTableList.ts	10.1	11	3	9
<anonymous>	src/pages/user/login/index.tsx	8.5	12	2	17

Hotspot Analysis

<anonymous> — src/requestErrorConfig.ts

This function configures centralized request error handling with an activity_risk of 12.12 and cyclomatic complexity of 19—the highest CC in the hotspot set. The moderate nesting depth (3) is offset by 19 independent execution paths, each representing a distinct error-handling branch that requires test coverage. The ‘exit_heavy’ pattern indicates multiple return or throw paths scattered throughout, creating a test-matrix problem: validating all 19 paths in a request config handler is tedious and error-prone. High recent commit activity (risk score 12.12) suggests the team is actively tuning error handling, making this a debt quadrant function that accumulates risk faster than it’s paid down.

Recommendation: Before refactoring, extract a characterization test that exercises all 19 code paths to establish a baseline. Then identify the 3–5 most common error categories and consolidate branching logic into decision tables or a strategy pattern; this will drop CC and make testing linear rather than exponential.

postRule — mock/listTableList.ts

The postRule mock handler has activity_risk 11.76 with CC 13 and fan-out 11—it calls 11 distinct functions, indicating broad coupling to the mock data system. The ‘god_function’ and ‘exit_heavy’ patterns flag that this single handler orchestrates multiple concerns (validation, transformation, response building) across the mock layer. Changes here can ripple across test suites and any code that depends on mock table-list behavior. Despite low nesting depth (2), the combination of moderate CC and high fan-out makes this a blast-radius hazard.

Recommendation: Map the 11 callees to identify cohesive clusters (e.g., validation logic, response formatting, business rules). Extract 2–3 focused sub-functions, each with a single responsibility; this reduces fan-out per function and makes the call graph easier to reason about.

<anonymous> — src/pages/table-list/index.tsx

The table-list page component is in the ‘fire’ quadrant (high activity + structural risk, not yet resolved). Despite modest CC (6), its fan-out of 19 makes it a coordination hub—it calls 19 distinct functions, suggesting it orchestrates data fetching, form handling, table rendering, and modal logic in one component. The god_function, exit_heavy, and long_function patterns and high recent commit activity (activity-weighted risk score 10.73) signal that this is the primary location where feature requests are implemented. Long function length compounds the problem: reading and testing this component requires holding 19 dependencies in mind simultaneously.

Recommendation: Extract domain-specific sub-components or custom hooks for distinct concerns: one for table-list logic, one for form/modal orchestration, one for filters. Each should own a subset of the 19 callees. This both reduces cognitive load and creates natural test boundaries.

getRule — mock/listTableList.ts

The getRule handler sits at rank 4 with an activity-weighted risk of 10.08. With cyclomatic complexity of 11 and fan-out of 9, it mirrors the structural profile of its sibling postRule—both orchestrate multiple concerns in the mock data layer for the same table-list endpoint. The moderate CC and 9-callee breadth create a meaningful test-surface problem: any change to how mock data is filtered, paginated, or shaped flows through this function, affecting tests downstream.

Recommendation: Treat getRule and postRule as a pair. When extracting sub-functions from postRule, apply the same clustering approach here—separate pagination/filtering logic from response shaping—so both handlers share a consistent structure and can reuse extracted helpers.

<anonymous> — src/pages/user/login/index.tsx

The login page component ranks fifth with an activity-weighted risk of 8.5. Its fan-out of 17 and CC of 12 are notable even below the critical threshold. The god_function and long_function patterns indicate that authentication flow, form state, redirect logic, and error display are all handled in a single component body. This is a common pattern in login pages that becomes brittle as auth requirements change—adding OAuth, MFA, or SSO typically means editing this already-crowded function.

Recommendation: Extract a useLoginFlow hook that encapsulates the submit handler, loading state, and error handling. The component itself should then only compose the form UI and delegate auth logic to the hook—reducing both fan-out and length while creating a clear boundary for testing auth flows independently.

Patterns Found

Antipatterns detected across the top functions in this snapshot:

Pattern	Occurrences
god_function	4
exit_heavy	3
long_function	3

These labels belong to two tiers — Tier 1 (structural): complex_branching, deeply_nested, exit_heavy, long_function, god_function. Tier 2 (relational/temporal): hub_function, cyclic_hub, middle_man, neighbor_risk, stale_complex, churn_magnet, shotgun_target, volatile_god.

Key Takeaways

• Request error handling (src/requestErrorConfig.ts) combines the highest cyclomatic complexity (CC 19) with exit-heavy branching; consolidating error categories into a strategy pattern will drop both CC and test burden from exponential to linear.
• Mock data handlers (postRule and getRule in mock/listTableList.ts) have combined fan-out of 20 and exhibit god_function antipatterns; clustering their 11–9 callees by responsibility (validation, formatting, rules) creates clearer module boundaries and reduces blast radius on test changes.
• The table-list page (src/pages/table-list/index.tsx) is in active debt: fire quadrant with activity-weighted risk 10.73 and fan-out 19, indicating it is the primary implementation target for new features; extracting sub-components or hooks per domain concern (table, form, filters) will stabilize it before complexity compounds further.

Reproduce This Analysis

git clone https://github.com/ant-design/ant-design-pro
cd ant-design-pro
git checkout 607e63f4fdb49d78306a618f2b2c29291ce85500
hotspots analyze . --mode snapshot

Hotspots highlights structural and activity risk — not “bad code.” Findings are a prioritization aid, not a bug predictor. Editorial policy →