You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
**What it does**: The main map orchestrator. Manages all map layers, tool modes, user interactions, and coordinates between Leaflet, WASM workers, and React state.
61
-
62
-
**Why it's a problem**: At 1173 lines it violates single-responsibility badly. It contains map config, event handlers, layer rendering logic, tool state machines, and full JSX output — all in one file. Changes to any one tool risk breaking others.
63
-
64
-
**Logical sections**:
65
-
1. Imports and SVG icon definitions (lines 1–50)
66
-
2. Map initialization and state setup (lines 60–150)
67
-
3. Tool event handlers and callbacks (lines 160–350)
68
-
4. Layer rendering conditions (lines 360–600)
69
-
5. Main JSX render (lines 610–1173)
70
-
71
-
**Suggested split**:
72
-
73
-
```
74
-
src/components/Map/
75
-
├── MapContainer.jsx (~200 lines) — core orchestration only
**What it does**: Configuration panel for RF hardware, environment, LoRa band settings, batch processing, and map options.
94
-
95
-
**Why it's a problem**: A single component rendering 6 logically distinct panels. Each panel has its own state, event handlers, and JSX. Changes to hardware settings risk breaking environment settings and vice versa.
-**Result**: `Sidebar.jsx` is now a clean layout container composing these sections.
116
83
117
84
---
118
85
@@ -307,18 +274,14 @@ rf-engine/
307
274
308
275
#### 12. `src/context/RFContext.jsx` — 307 lines
309
276
310
-
**What it does**: Central React Context holding all RF configuration state — hardware, radio, environment, and UI state — shared across all components.
311
-
312
-
**Suggested split**:
313
-
314
-
```
315
-
src/context/
316
-
├── RFContext.jsx (~80 lines) — root provider composing all contexts
-`RFContext.jsx`: Wrapper that composes these contexts and exports a unified hook.
284
+
-**Result**: Clean separation of concerns while maintaining backward compatibility.
322
285
323
286
---
324
287
@@ -350,21 +313,17 @@ src/hooks/
350
313
351
314
---
352
315
353
-
## Recommended Refactoring Phases
354
-
355
-
### Phase 1 — Frontend Core (Highest ROI)
356
-
357
-
Target the two largest files to eliminate the "big ball of mud" problem:
316
+
## Refactoring Progress
358
317
359
-
1.**MapContainer.jsx** (1173 → ~200 lines): Extract 4 layer manager components and a `useMapEventHandlers` hook. This is the highest-risk file for accidental regressions.
360
-
2.**Sidebar.jsx** (829 → ~150 lines): Extract 3 section components and the `CollapsibleSection` helper.
318
+
### Phase 1 — Frontend Core (COMPLETED)
361
319
362
-
**Expected effort**: 3–5 days
363
-
**Risk**: Medium — both files have complex state wiring; test thoroughly after each split.
320
+
1.**MapContainer.jsx** (1173 → ~250 lines): Refactored into Layer Managers (`LinkLayerManager`, `ViewshedLayerManager`, `CoverageLayerManager`, `OptimizationLayerManager`) and Hooks (`useLinkTool`, `useMapEventHandlers`).
3.**RFContext.jsx**: Refactored using Facade pattern (`UIContext`, `HardwareContext`, `EnvironmentContext`, `RadioContext`).
364
323
365
324
---
366
325
367
-
### Phase 2 — Backend API Structure
326
+
### Phase 2 — Backend API Structure (NEXT)
368
327
369
328
Reorganize `server.py` into FastAPI routers — this is low-risk since Python imports are explicit and easy to verify:
370
329
@@ -383,13 +342,13 @@ Reorganize `server.py` into FastAPI routers — this is low-risk since Python im
383
342
7.**viewshed.py** (398 → ~120 lines): Separate Celery task definition from processing logic and image utilities.
384
343
385
344
**Expected effort**: 2–3 days
386
-
**Risk**: Medium — analysis panels have complex prop drilling; consider whether this is a good time to introduce a data-fetching pattern (e.g., React Query).
345
+
**Risk**: Medium — analysis panels have complex prop drilling.
387
346
388
347
---
389
348
390
349
### Phase 4 — State Management
391
350
392
-
8.**RFContext.jsx** (307 → ~80 lines each): Split into 4 focused contexts. This change affects nearly every component, so coordinate with Phase 1 changes.
351
+
8.**RFContext.jsx** (307 → ~80 lines each): Split into 4 focused contexts. This change affects nearly every component, so coordinate with Phase 1 changes. (ALREADY COMPLETED IN PHASE 1 VIA FACADE)
393
352
394
353
**Expected effort**: 1–2 days
395
354
**Risk**: High — touches every component. Do this last and test end-to-end.
@@ -402,17 +361,3 @@ Reorganize `server.py` into FastAPI routers — this is low-risk since Python im
402
361
403
362
**Expected effort**: 2–3 days
404
363
**Risk**: Low.
405
-
406
-
---
407
-
408
-
## General Recommendations
409
-
410
-
1.**Extract algorithms from UI**: Several components contain inline algorithms (BFS in `SiteAnalysisResultsPanel`, diffraction in `LinkAnalysisPanel`). Move all pure logic to `src/utils/` or `rf-engine/utils/` — this makes testing significantly easier.
411
-
412
-
2.**Introduce a service layer**: API calls are scattered across hooks and components. Centralizing them in `src/services/rfService.js` and `src/services/elevationService.js` would decouple components from fetch logic.
413
-
414
-
3.**Colocate tests**: As files are split, add unit tests for extracted utility functions. Pure math functions like those in `rfMath.js` and `rf_physics.py` are ideal first targets.
415
-
416
-
4.**Avoid premature abstraction**: Not every file needs splitting. The LOW-priority files (≤225 lines) are generally well-scoped — leave them unless they grow.
417
-
418
-
5.**Incremental approach**: Refactor one file at a time. Avoid large "big bang" refactors that make code review difficult and increase regression risk.
0 commit comments