eomsangdonandClaude Opus 5
1ee6516dd5
페이지 간 캐시 공유 - B06_wf3_ProfileCross_Section_Store.ts 신설: 종횡단 상세를 projectId:routeId 키로 들고 있는 모듈 싱글턴 캐시. B05와 B06이 같은 객체 참조를 보므로 B06이 측점 설계를 제자리 갱신하면 B05가 다음 그리기에서 그대로 본다 — 횡단을 고친 뒤 B05 유토곡선이 옛 값으로 그려지던 문제의 원인이 페이지별 개별 fetch였다. - 두 페이지 진입을 loadSectionDetail()로 통일(동시 호출은 Promise 공유). - 정본이 다시 쓰이는 조작에 캐시 갱신: 횡단 재생성 → replaceSectionDetail, 계획선 편집 저장 → invalidateSectionDetail. 계획선 호 기하 - 배관 지점(지면선 × 배관 세로선 교점)이 호 위에 오도록 변화점 표고를 반복 보정. 대칭 종단곡선은 꼭짓점을 지나지 않아 중앙종거만큼 어긋나 있었다. 시작점·종점과 각 호, 호와 호 사이는 직선이 접선으로 잇는다. - 호 반경 기본값을 설계 기준의 종단곡선 최소 반경으로 지정하고 curve_radii 편집 델타에 실어 B05 테이블에서 사용자가 그대로 고칠 수 있게 했다. 유토곡선 Y축 - B05에만 있던 종단용 sticky 표고축 탓에 가로로 훑으면 유토곡선 눈금은 흘러가고 표고축만 남아 Y축이 높이로 읽혔다. createMassHaulChart에 onAxis 콜백을 더해 유토곡선용 sticky 누가토량 축을 따로 고정. 검증: solve 재실행 후 배관 4개 자리에서 계획고=지반고(오차 ≤0.0001m), 호 비겹침 확인. typecheck·vite build·ruff·B03 테스트 통과. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
79 lines
3.5 KiB
TypeScript
79 lines
3.5 KiB
TypeScript
/* =============================================================================
|
|
* B06_wf3_ProfileCross_Section_Store.ts
|
|
* 종횡단 상세(SectionDetailResponse)의 **프론트 공유 캐시** — B05·B06이 같은 객체를 본다.
|
|
*
|
|
* ── 왜 필요한가 (2026-08-03 사용자 확정) ─────────────────────────────
|
|
* B05(노선·계획선)와 B06(종횡단 설계)은 같은 영구저장소 데이터의 두 창이다. 페이지마다
|
|
* 따로 fetch해 제각각 들고 있으면, B06에서 지반유형·암 경계를 고친 뒤 B05로 넘어갔을 때
|
|
* 횡단 기준 유토곡선이 옛 값으로 그려진다(사용자가 실제로 겪은 문제). 여기서 한 번 받아
|
|
* **같은 객체 참조**를 두 페이지에 주면, B06이 측점 설계를 제자리 갱신하는 순간 B05가
|
|
* 다음 그리기에서 그대로 본다 — 별도 동기화 코드가 필요 없다.
|
|
*
|
|
* ── 수명 규칙 ─────────────────────────────────────────────────────
|
|
* 키는 `projectId:routeId`. SPA 모듈 싱글턴이라 페이지를 오가도 살아 있고, 새로고침이면
|
|
* 사라져 영구저장소에서 다시 받는다(영구저장소가 항상 정본). 서버가 파일을 통째로 다시
|
|
* 쓰는 조작(재생성·계획선 편집 저장·확정)은 그 응답/재조회로 `replace`·`invalidate`한다.
|
|
* ========================================================================== */
|
|
|
|
import type { SectionDetailResponse } from "./B06_wf3_ProfileCross_Api_Fetch";
|
|
import { fetchSectionDetail } from "./B06_wf3_ProfileCross_Api_Fetch";
|
|
|
|
const cache = new Map<string, SectionDetailResponse>();
|
|
const pending = new Map<string, Promise<SectionDetailResponse>>();
|
|
|
|
function keyOf(projectId: string, routeId: number): string {
|
|
return `${projectId}:${routeId}`;
|
|
}
|
|
|
|
/**
|
|
* 상세를 가져온다 — 캐시가 있으면 **같은 객체**를 즉시 돌려주고, 없으면 한 번만 fetch한다
|
|
* (동시 호출은 같은 Promise를 공유). `force`면 캐시를 버리고 다시 받는다.
|
|
*/
|
|
export async function loadSectionDetail(
|
|
projectId: string,
|
|
routeId: number,
|
|
options?: { force?: boolean },
|
|
): Promise<SectionDetailResponse> {
|
|
const key = keyOf(projectId, routeId);
|
|
if (!options?.force) {
|
|
const cached = cache.get(key);
|
|
if (cached) return cached;
|
|
const inFlight = pending.get(key);
|
|
if (inFlight) return inFlight;
|
|
}
|
|
const request = fetchSectionDetail(projectId, routeId)
|
|
.then((detail) => {
|
|
cache.set(key, detail);
|
|
return detail;
|
|
})
|
|
.finally(() => {
|
|
pending.delete(key);
|
|
});
|
|
pending.set(key, request);
|
|
return request;
|
|
}
|
|
|
|
/** 서버가 새 상세를 통째로 돌려준 조작(재생성 등) 뒤 캐시를 그 값으로 바꾼다. */
|
|
export function replaceSectionDetail(
|
|
projectId: string,
|
|
routeId: number,
|
|
detail: SectionDetailResponse,
|
|
): void {
|
|
cache.set(keyOf(projectId, routeId), detail);
|
|
}
|
|
|
|
/**
|
|
* 캐시를 비운다. routeId를 생략하면 그 프로젝트 전부 —
|
|
* 서버 쪽 정본이 바뀌었는데 새 상세를 손에 못 쥔 조작(계획선 편집 저장 등) 뒤에 쓴다.
|
|
*/
|
|
export function invalidateSectionDetail(projectId: string, routeId?: number): void {
|
|
if (routeId !== undefined) {
|
|
cache.delete(keyOf(projectId, routeId));
|
|
return;
|
|
}
|
|
const prefix = `${projectId}:`;
|
|
for (const key of [...cache.keys()]) {
|
|
if (key.startsWith(prefix)) cache.delete(key);
|
|
}
|
|
}
|