HeuJung
6c63536f81
번들 확장 20개 전부에 AGENTS.md · README.md · docs/ 를 채우고, 코어가 들고 있던 확장 소유 문서 두 갈래를 그 확장으로 옮긴다. 번들 템플릿의 컴포넌트· 핸들러·레이아웃 상세와 확장이 구독하는 활동 로그 훅 목록이 그 대상이며, 코어에는 총계와 링크만 남아 확장이 기능을 늘릴 때 코어 문서를 고쳐야 하던 역방향 의존이 사라진다. 전수 완비를 확인하고 강제를 조인다 — 문서 동반 룰을 대상 목록 없는 error 로 승격하고, 검사 스크립트가 문서 미보유를 실패로 올리며, 미채움 마커 baseline 을 0 으로 기록한다. 한쪽만 조이면 "새 확장이 문서 없이 들어와도 초록" 인 상태가 남는데 그 결과는 이상 0건과 구분되지 않는다. 집필 과정에서 드러난 생성기 결함 셋을 함께 고친다. 스케줄 주기 열이 계약 키를 읽지 않아 모든 확장에서 '-' 였고, 네임스페이스를 붙인 핸들러 등록 키가 수집에서 통째로 빠졌으며, README 골격이 폐기된 히어로 배지를 계속 찍어내고 있었다. 셋 다 산출물이 아니라 원천이 틀린 것이라, 가드의 모집단에 생성기 출력 자체를 넣어 다음 확장이 같은 상태로 태어나는 경로를 막는다.
2.6 KiB
Hello 사용자 템플릿 — 핸들러
템플릿 전용 핸들러와 부트스트랩 · 진입점: AGENTS.md
템플릿 전용 핸들러
등록하는 액션 핸들러가 없습니다.
없습니다. 이 샘플의 화면은 코어 엔진의 기본 핸들러(apiCall · navigate · setState 등)
만으로 그려집니다. 홈 화면의 목록도 data_sources 선언만으로 채워지므로 별도 핸들러가 필요
없습니다.
템플릿 전용 핸들러가 필요해지는 경우는 그 템플릿의 화면 구조에만 있는 동작을 다룰 때입니다 —
테마 전환, 장바구니 선택 상태, 브라우저 저장소 관리 같은 것들이며, sirsoft-basic 이 32개를
갖는 것이 그 예입니다.
핸들러를 도입할 때는 ActionDispatcher 에 등록하는 부트스트랩 함수가 함께 필요하고, 그 등록도
레지스트리·디스패처 가용을 기다리는 재시도 루프 안에 두어야 합니다.
부트스트랩
프론트 엔트리포인트가 없습니다.
전용 부트스트랩 함수가 없습니다. src/index.ts 가 모듈 로드 시점에 곧바로 코어
ComponentRegistry 를 찾아 Basic 8개를 등록하고, 레지스트리가 없으면 경고를 남기고
건너뜁니다.
이 형태는 따라 하지 않는 것이 좋습니다. 같은 샘플군의
gnuboard7-hello_admin_template은initTemplate()안에서 100ms 간격 최대 50회 재시도하며window.load이후에 시작합니다. 한 번만 시도하는 이 형태는 로드 순서에 따라 등록이 누락될 수 있고, 그러면 레이아웃이 컴포넌트 이름을 찾지 못해 화면이 조용히 빕니다 — 콘솔 경고 외에는 흔적이 없습니다.
템플릿은 전역 객체를 노출하지 않습니다. 모듈·플러그인은
window.__[Name].initModule/initPlugin 을 고정 이름으로 노출해야 하지만(로케일 전환 후 코어가
그것을 다시 부릅니다), 템플릿은 코어가 부트스트랩 경로를 직접 알고 있습니다.
액션 핸들러를 도입하면 그때 ActionDispatcher 등록이 추가되며, 그 등록도 같은 재시도 루프
안에 두어야 합니다.