[Refactor/#114] 사장님 인증 관련 api 수정#115
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Warning Rate limit exceeded
You’ve run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthrough이 PR은 주소 검색 기능을 Kakao 기반 검색에서 Daum Postcode 팝업 기반 단일 흐름으로 전환하고, 회원가입 성공 시 accessToken을 로컬 스토리지에 저장하며, 정산 데이터 및 UI 표시 값에 기본값 처리를 추가합니다. Changes주소 검색 및 회원가입 통합
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@apps/customer/next-env.d.ts`:
- Line 3: The import line `import "./.next/dev/types/routes.d.ts";` hardcodes a
dev-only path and should be removed; add the next-env.d.ts file to .gitignore,
delete the committed next-env.d.ts from the repo so Next.js can auto-generate it
per its docs, and update tsconfig.json to include a wildcard like
`.next/types/**/*.d.ts` (or `.next/types/**/*.ts`) so both dev and production/CI
generated types are picked up; ensure no manual edits remain to next-env.d.ts.
In `@apps/owner/src/app/signup/page.tsx`:
- Around line 62-66: onSuccess handler currently writes res.data.accessToken to
localStorage without validation; add a guard in the onSuccess function to verify
accessToken is a non-empty string (e.g., check typeof accessToken === "string"
&& accessToken.trim() !== ""), only call
localStorage.setItem("ownerAccessToken", accessToken) when valid, and otherwise
handle the failure branch (e.g., do not store, call the error/fallback flow or
show a notification). Ensure you modify the onSuccess callback where accessToken
is read and stored so invalid/undefined/empty tokens are not persisted.
In `@apps/owner/src/app/signup/register/_apis/loadDaumPostcode.ts`:
- Around line 17-33: When an existingScript is found the code only attaches
load/error listeners which can leave the Promise pending if the script has
already finished loading but window.daum?.Postcode is not present; update the
existingScript branch in loadDaumPostcode to first check synchronously whether
window.daum?.Postcode exists and resolve immediately if so, otherwise detect a
completed script state (e.g., existingScript.readyState === "complete" or a
custom data attribute) and reject with a clear error instead of waiting, and
only attach addEventListener("load"/"error") as a fallback for truly pending
scripts so resolve/reject always occurs.
In `@apps/owner/src/app/signup/register/_apis/openDaumPostcode.ts`:
- Around line 16-29: The Postcode popup currently only handles oncomplete and
never rejects if the user closes the popup, so add an onclose handler on the new
window.daum.Postcode instance that inspects the close state and rejects the
Promise when state === "FORCE_CLOSE"; to avoid racing with
oncomplete/COMPLETE_CLOSE use a local settled boolean (e.g., settled = false)
that you set to true inside the oncomplete handler before calling resolve and
check in onclose to only call reject when settled is false, and ensure both
resolve and reject clear/set the settled flag so the Promise is settled exactly
once.
In `@apps/owner/src/app/signup/register/_types/address-search.ts`:
- Around line 21-24: Postcode 타입의 onclose 시그니처가 Daum Postcode 공식 API와 다르므로
수정하세요: 현재 Postcode constructor options includes oncomplete and onclose but
onclose is declared as onclose?: () => void; — change it to accept the close
state parameter (e.g., onclose?: (state: "COMPLETE_CLOSE" | "FORCE_CLOSE") =>
void) so it matches DaumPostcodeData usage and lets callers distinguish user
cancel vs complete; also update any callers of Postcode/new Postcode(...) (and
related dialog close handling) to pass/handle the state and ensure the dialog
close path is implemented where Postcode is used.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 87c424a6-394f-4b62-9a6e-4847a8cb07ba
📒 Files selected for processing (10)
apps/customer/next-env.d.tsapps/owner/src/app/(tabs)/main/_components/CafeIntro.tsxapps/owner/src/app/(tabs)/main/page.tsxapps/owner/src/app/signup/page.tsxapps/owner/src/app/signup/register/_apis/loadDaumPostcode.tsapps/owner/src/app/signup/register/_apis/openDaumPostcode.tsapps/owner/src/app/signup/register/_apis/searchAddressBykakao.tsapps/owner/src/app/signup/register/_components/AddressSearchBottomSheet.tsxapps/owner/src/app/signup/register/_types/address-search.tspackages/api/src/models/auth.ts
💤 Files with no reviewable changes (1)
- apps/owner/src/app/signup/register/_apis/searchAddressBykakao.ts
| /// <reference types="next" /> | ||
| /// <reference types="next/image-types/global" /> | ||
| import "./.next/types/routes.d.ts"; | ||
| import "./.next/dev/types/routes.d.ts"; |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
Next.js 16 기준으로 next-env.d.ts에서 typed routes 참조 경로는 "./.next/types/routes.d.ts"와 "./.next/dev/types/routes.d.ts" 중 무엇이 공식적으로 권장되나요? dev/prod(typecheck, CI)별 생성 경로 차이도 함께 확인해주세요.
💡 Result:
Next.js 16에서 next-env.d.ts 파일 내의 typed routes 참조 경로는 사용자가 직접 수정하거나 선택하는 것이 아니며, Next.js가 실행 환경(dev 또는 build)에 따라 자동으로 관리하는 영역입니다 [1]. 공식적으로 권장되는 특정 경로가 하나로 고정되어 있는 것이 아니라, Next.js의 내부 동작 방식에 따라 다음과 같이 생성됩니다 [1]. 1. 생성 경로 차이: - 개발 환경(next dev):.next/dev/types/routes.d.ts 경로를 참조하도록 생성됩니다 [1]. - 빌드 환경(next build):.next/types/routes.d.ts 경로를 참조하도록 생성됩니다 [1]. 이는 Next.js의 isolatedDevBuild 옵션 도입으로 인해 개발 시의 타입 생성 경로와 빌드 시의 경로가 분리되었기 때문입니다 [1]. 이로 인해 next-env.d.ts 파일 내의 참조 경로가 실행 환경에 따라 토글(toggle)되는 현상이 발생할 수 있으며, 이는 의도된 동작입니다 [1]. 2. 권장 사항: - next-env.d.ts 파일은 Next.js가 자동으로 생성하고 관리하는 파일이므로, 개발자가 직접 이 파일의 참조 경로를 수정해서는 안 됩니다 [2][3]. - 해당 파일은.gitignore에 추가하여 버전 관리에서 제외하는 것이 공식적인 권장 사항입니다 [2][3]. - 프로젝트의 tsconfig.json 파일 내 include 배열에는.next/types//*.ts와 같이 와일드카드를 사용하여 포함시키는 것이 권장됩니다 [2][3]. 이렇게 설정하면 개발 환경과 빌드 환경 모두에서 타입 정의를 올바르게 인식할 수 있습니다 [2][3]. 결론적으로, 특정 경로를 선택하는 것이 아니라 Next.js가 자동으로 생성하는 경로를 그대로 두되, tsconfig.json 설정을 통해 모든 환경에서 타입이 정상적으로 참조되도록 구성하는 것이 올바른 방법입니다 [1][2][3].
Citations:
- 1: next-env.d.ts toggles between .next/dev/types/routes.d.ts and .next/types/routes.d.ts even with typedRoutes: false vercel/next.js#86001
- 2: https://beta.nextjs.org/docs/configuring/typescript
- 3: https://nextjs.org/docs/pages/api-reference/config/typescript
🏁 Script executed:
#!/bin/bash
# 리포 내 next-env.d.ts들의 routes 참조 경로를 비교해 일관성 확인
fd -a "next-env.d.ts" | while read -r f; do
echo "== $f =="
rg -n 'routes\.d\.ts|next-env|reference types="next"' "$f"
echo
doneRepository: CUK-Compasser/FE
Length of output: 42
🏁 Script executed:
#!/bin/bash
# Check if next-env.d.ts exists in the repository
find . -name "next-env.d.ts" -type f
# Check .gitignore for next-env.d.ts rules
echo "=== .gitignore content ==="
cat .gitignore 2>/dev/null | grep -E "next-env|\.next" || echo "No .next-related rules found"
# Check if apps/customer/next-env.d.ts exists with line count
if [ -f "apps/customer/next-env.d.ts" ]; then
echo "=== apps/customer/next-env.d.ts exists ==="
cat -n "apps/customer/next-env.d.ts"
fiRepository: CUK-Compasser/FE
Length of output: 509
next-env.d.ts의 dev 전용 경로 고정은 빌드/CI 환경에서 타입을 찾지 못해 빌드 실패를 초래합니다.
Line 3에서 ./.next/dev/types/routes.d.ts를 하드코딩하면 개발 환경에서는 작동하지만, 프로덕션 빌드 및 CI 환경에서는 ./.next/types/routes.d.ts를 참조하므로 타입 파일을 찾지 못합니다. 더 근본적으로, Next.js 공식 문서(파일의 5-6줄 주석 참조)에 따르면 next-env.d.ts는 Next.js가 자동으로 생성·관리하는 파일이며 수동 편집 금지입니다. 또한 이 파일은 .gitignore에 추가되어야 하며, tsconfig.json에 .next/types/**/*.ts 와일드카드를 사용하여 양쪽 환경을 모두 처리해야 합니다.
- apps/customer/next-env.d.ts를 .gitignore에 추가
- 이 파일을 저장소에서 제거하고 각 개발자/CI 환경에서 자동 생성되도록 구성
- 필요시 tsconfig.json 설정 검토
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@apps/customer/next-env.d.ts` at line 3, The import line `import
"./.next/dev/types/routes.d.ts";` hardcodes a dev-only path and should be
removed; add the next-env.d.ts file to .gitignore, delete the committed
next-env.d.ts from the repo so Next.js can auto-generate it per its docs, and
update tsconfig.json to include a wildcard like `.next/types/**/*.d.ts` (or
`.next/types/**/*.ts`) so both dev and production/CI generated types are picked
up; ensure no manual edits remain to next-env.d.ts.
| onSuccess: (res) => { | ||
| const accessToken = res.data.accessToken; | ||
|
|
||
| localStorage.setItem("ownerAccessToken", accessToken); | ||
|
|
There was a problem hiding this comment.
accessToken 유효성 검증 후 저장하도록 가드가 필요합니다.
응답이 비정상일 때 undefined/빈 문자열이 저장되면 이후 인증 흐름이 깨질 수 있습니다. 저장 전에 검증하고 실패 처리를 분기해 주세요.
🔧 제안 수정안
onSuccess: (res) => {
- const accessToken = res.data.accessToken;
-
- localStorage.setItem("ownerAccessToken", accessToken);
+ const accessToken = res.data?.accessToken?.trim();
+ if (!accessToken) {
+ console.error("회원가입 응답에 accessToken이 없습니다.");
+ return;
+ }
+ localStorage.setItem("ownerAccessToken", accessToken);
setSignupCompleted(email);
router.push("/signup/business");
},📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| onSuccess: (res) => { | |
| const accessToken = res.data.accessToken; | |
| localStorage.setItem("ownerAccessToken", accessToken); | |
| onSuccess: (res) => { | |
| const accessToken = res.data?.accessToken?.trim(); | |
| if (!accessToken) { | |
| console.error("회원가입 응답에 accessToken이 없습니다."); | |
| return; | |
| } | |
| localStorage.setItem("ownerAccessToken", accessToken); | |
| setSignupCompleted(email); | |
| router.push("/signup/business"); | |
| }, |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@apps/owner/src/app/signup/page.tsx` around lines 62 - 66, onSuccess handler
currently writes res.data.accessToken to localStorage without validation; add a
guard in the onSuccess function to verify accessToken is a non-empty string
(e.g., check typeof accessToken === "string" && accessToken.trim() !== ""), only
call localStorage.setItem("ownerAccessToken", accessToken) when valid, and
otherwise handle the failure branch (e.g., do not store, call the error/fallback
flow or show a notification). Ensure you modify the onSuccess callback where
accessToken is read and stored so invalid/undefined/empty tokens are not
persisted.
| if (existingScript) { | ||
| existingScript.addEventListener( | ||
| "load", | ||
| () => { | ||
| if (window.daum?.Postcode) resolve(); | ||
| else reject(new Error("Daum Postcode is not loaded.")); | ||
| }, | ||
| { once: true }, | ||
| ); | ||
|
|
||
| existingScript.addEventListener( | ||
| "error", | ||
| () => reject(new Error("Failed to load Daum Postcode script.")), | ||
| { once: true }, | ||
| ); | ||
|
|
||
| return; |
There was a problem hiding this comment.
기존 스크립트 분기에서 Promise가 영구 대기 상태가 될 수 있습니다.
이미 로드가 끝난 스크립트인데 window.daum?.Postcode가 없는 경우, load/error가 다시 오지 않아 resolve/reject가 되지 않을 수 있습니다.
🔧 제안 수정안
if (existingScript) {
+ const timeoutId = window.setTimeout(() => {
+ reject(new Error("Timed out while waiting for Daum Postcode script."));
+ }, 10000);
+
+ const cleanup = () => window.clearTimeout(timeoutId);
+
existingScript.addEventListener(
"load",
() => {
+ cleanup();
if (window.daum?.Postcode) resolve();
else reject(new Error("Daum Postcode is not loaded."));
},
{ once: true },
);
existingScript.addEventListener(
"error",
- () => reject(new Error("Failed to load Daum Postcode script.")),
+ () => {
+ cleanup();
+ reject(new Error("Failed to load Daum Postcode script."));
+ },
{ once: true },
);
return;
}🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@apps/owner/src/app/signup/register/_apis/loadDaumPostcode.ts` around lines 17
- 33, When an existingScript is found the code only attaches load/error
listeners which can leave the Promise pending if the script has already finished
loading but window.daum?.Postcode is not present; update the existingScript
branch in loadDaumPostcode to first check synchronously whether
window.daum?.Postcode exists and resolve immediately if so, otherwise detect a
completed script state (e.g., existingScript.readyState === "complete" or a
custom data attribute) and reject with a clear error instead of waiting, and
only attach addEventListener("load"/"error") as a fallback for truly pending
scripts so resolve/reject always occurs.
| new window.daum.Postcode({ | ||
| oncomplete: (data: DaumPostcodeData) => { | ||
| const roadAddress = data.roadAddress || data.address || ""; | ||
| const lotNumberAddress = data.jibunAddress || ""; | ||
|
|
||
| resolve({ | ||
| id: `${data.zonecode}-${roadAddress || lotNumberAddress}`, | ||
| label: roadAddress || lotNumberAddress, | ||
| roadAddress, | ||
| lotNumberAddress, | ||
| zonecode: data.zonecode, | ||
| }); | ||
| }, | ||
| }).open(); |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
Daum Postcode onclose 콜백이 oncomplete 이후에도 호출되는지, 그리고 FORCE_CLOSE/COMPLETE_CLOSE 의미 확인
💡 Result:
Daum 우편번호 서비스의 onclose 콜백은 oncomplete 콜백이 실행된 후에도 호출될 수 있습니다 [1][2]. onclose 콜백은 우편번호 검색창이 닫힐 때 호출되며, 이때 전달되는 state 인자를 통해 닫힌 이유를 구분할 수 있습니다 [2]. FORCE_CLOSE와 COMPLETE_CLOSE의 의미는 다음과 같습니다: 1. COMPLETE_CLOSE: 사용자가 검색 결과 항목을 선택하여 주소 정보가 전달된 후, 우편번호 서비스가 자동으로 닫히는 상태를 의미합니다 [2]. 즉, oncomplete 콜백이 정상적으로 실행 완료된 후에 이 상태로 onclose가 호출됩니다 [1][2]. 2. FORCE_CLOSE: 사용자가 검색 결과 항목을 선택하지 않고, 검색창의 닫기 버튼을 누르거나 외부 영역을 클릭하는 등 강제로 검색창을 닫았을 때 발생하는 상태입니다 [2]. 따라서 oncomplete는 주소 선택 시점에 실행되고, 이후 검색창이 닫히면서 onclose가 호출되는 흐름을 가집니다 [1][2]. 만약 oncomplete 내부에서 페이지 이동(location.href 변경 등)을 수행하면, 페이지가 초기화되어 onclose 콜백이 정상적으로 실행되지 않을 수 있으므로 주의가 필요합니다 [1].
Citations:
- 1: 팝업창 사용일때, OnClose 콜백함수 관련 질문드립니다. daumPostcode/QnA#185
- 2: https://velog.io/@eunjios/react-daum-postcode-practice
주소 선택 없이 팝업을 닫으면 Promise가 resolve/reject 되지 않습니다.
사용자가 주소를 선택하지 않고 닫기 버튼이나 외부 영역을 클릭하면 onclose가 FORCE_CLOSE 상태로 호출되지만, 현재 코드는 이를 처리하지 않아 호출 측의 로딩 상태가 풀리지 않습니다. onclose에서 FORCE_CLOSE 상태를 감지하여 Promise를 reject해 주세요. (주소 선택 후 자동으로 닫히는 COMPLETE_CLOSE 상태는 oncomplete 이후에 호출되므로 settled 플래그로 구분하여 처리하면 됩니다.)
🔧 제안 수정안
return new Promise((resolve, reject) => {
if (!window.daum?.Postcode) {
reject(new Error("Daum Postcode is not loaded."));
return;
}
+ let settled = false;
+
new window.daum.Postcode({
oncomplete: (data: DaumPostcodeData) => {
+ settled = true;
const roadAddress = data.roadAddress || data.address || "";
const lotNumberAddress = data.jibunAddress || "";
resolve({
id: `${data.zonecode}-${roadAddress || lotNumberAddress}`,
label: roadAddress || lotNumberAddress,
roadAddress,
lotNumberAddress,
zonecode: data.zonecode,
});
},
+ onclose: (state) => {
+ if (!settled && state === "FORCE_CLOSE") {
+ reject(new Error("사용자가 주소 검색을 취소했습니다."));
+ }
+ },
}).open();
});🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@apps/owner/src/app/signup/register/_apis/openDaumPostcode.ts` around lines 16
- 29, The Postcode popup currently only handles oncomplete and never rejects if
the user closes the popup, so add an onclose handler on the new
window.daum.Postcode instance that inspects the close state and rejects the
Promise when state === "FORCE_CLOSE"; to avoid racing with
oncomplete/COMPLETE_CLOSE use a local settled boolean (e.g., settled = false)
that you set to true inside the oncomplete handler before calling resolve and
check in onclose to only call reject when settled is false, and ensure both
resolve and reject clear/set the settled flag so the Promise is settled exactly
once.
| Postcode: new (options: { | ||
| oncomplete: (data: DaumPostcodeData) => void; | ||
| onclose?: () => void; | ||
| }) => { |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
Daum 우편번호 서비스(Postcode v2) onclose 콜백 시그니처와 state 값(COMPLETE_CLOSE/FORCE_CLOSE) 공식 문서 확인
💡 Result:
Daum 우편번호 서비스(Postcode v2)의 onclose 콜백 함수는 우편번호 찾기 화면이 닫힐 때 호출되며, 화면이 닫힌 방식에 대한 상태 정보를 인자로 전달받습니다 [1][2]. 콜백 시그니처: onclose: function(state) {... } state 인자 값 및 설명: 1. FORCE_CLOSE: 사용자가 브라우저의 닫기 버튼 등을 통해 팝업창을 직접 닫았을 경우 발생합니다 [1][3]. (레이어 모드에서는 발생하지 않습니다 [1].) 2. COMPLETE_CLOSE: 사용자가 검색 결과를 선택하여 화면이 닫혔을 경우 발생합니다 [1][3]. 이는 팝업 및 레이어 모드의 기본 동작이며, oncomplete 콜백 함수가 실행 완료된 후에 호출됩니다 [1][4][2]. 참고 사항: - 레이어 모드(embed 함수 사용)에서는 검색 결과를 선택하여 닫히는 경우에만 onclose 콜백이 실행됩니다 [1]. - oncomplete 콜백 함수가 실행되는 도중 오류가 발생하거나, autoClose 옵션을 false로 설정한 경우에는 자동으로 닫히지 않을 수 있습니다 [5].
Citations:
- 1: https://postcode.map.daum.net/guide
- 2: https://velog.io/@nangman/%EC%A3%BC%EC%86%8C-API%ED%99%9C%EC%9A%A9-KAKAO
- 3: https://velog.io/@hayeooooon/%EC%8B%A4%EC%A0%84-%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8-%ED%9A%8C%EA%B3%A0-Daum-Postcode-API-Kakao-Local-API%EB%A5%BC-%ED%99%9C%EC%9A%A9%ED%95%9C-%EC%9C%84%EC%B9%98-%EA%B8%B0%EB%B0%98-%EA%B2%80%EC%83%89-%EA%B8%B0%EB%8A%A5-%EA%B5%AC%ED%98%84-Kakao-Maps-API-%ED%99%9C%EC%9A%A9%ED%95%98%EC%97%AC-%EC%A7%80%EB%8F%84%EC%83%81%EC%97%90-%EB%8D%B0%EC%9D%B4%ED%84%B0-%EB%B3%B4%EC%97%AC%EC%A3%BC%EA%B8%B0
- 4: https://velog.io/@eunjios/react-daum-postcode-practice
- 5: 간헐적으로 팝업 종료시 나타나는 문제 daumPostcode/QnA#106
🏁 Script executed:
cd apps/owner/src/app/signup/register/_types && cat -n address-search.ts | head -30Repository: CUK-Compasser/FE
Length of output: 808
🏁 Script executed:
rg "onclose" --type ts --type tsx -B 2 -A 2Repository: CUK-Compasser/FE
Length of output: 88
🏁 Script executed:
rg "onclose" -B 2 -A 2Repository: CUK-Compasser/FE
Length of output: 516
🏁 Script executed:
rg "daum\.Postcode|window\.daum" -B 3 -A 3Repository: CUK-Compasser/FE
Length of output: 2951
🏁 Script executed:
cat -n apps/owner/src/app/signup/register/_apis/openDaumPostcode.tsRepository: CUK-Compasser/FE
Length of output: 1151
onclose 콜백 시그니처를 Daum Postcode 공식 API와 일치시켜 주세요.
현재 타입 선언에서 onclose?: () => void;로 정의되어 있으나, 공식 Daum Postcode API에서는 onclose(state)가 "COMPLETE_CLOSE" 또는 "FORCE_CLOSE" 상태를 인자로 전달받습니다. 이 타입 선언으로는 사용자 취소 시나리오를 구분하여 처리할 수 없으며, 현재 구현에서도 다이얼로그 닫힘 처리가 누락되어 있습니다.
🔧 제안 수정안
Postcode: new (options: {
oncomplete: (data: DaumPostcodeData) => void;
- onclose?: () => void;
+ onclose?: (state: "COMPLETE_CLOSE" | "FORCE_CLOSE") => void;
}) => {
open: () => void;
};📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| Postcode: new (options: { | |
| oncomplete: (data: DaumPostcodeData) => void; | |
| onclose?: () => void; | |
| }) => { | |
| Postcode: new (options: { | |
| oncomplete: (data: DaumPostcodeData) => void; | |
| onclose?: (state: "COMPLETE_CLOSE" | "FORCE_CLOSE") => void; | |
| }) => { |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@apps/owner/src/app/signup/register/_types/address-search.ts` around lines 21
- 24, Postcode 타입의 onclose 시그니처가 Daum Postcode 공식 API와 다르므로 수정하세요: 현재 Postcode
constructor options includes oncomplete and onclose but onclose is declared as
onclose?: () => void; — change it to accept the close state parameter (e.g.,
onclose?: (state: "COMPLETE_CLOSE" | "FORCE_CLOSE") => void) so it matches
DaumPostcodeData usage and lets callers distinguish user cancel vs complete;
also update any callers of Postcode/new Postcode(...) (and related dialog close
handling) to pass/handle the state and ensure the dialog close path is
implemented where Postcode is used.
1 participant
✅ 작업 내용
📝 Description
🚀 설계 의도 및 개선점
📸 스크린샷 (선택)
📎 기타 참고사항
Summary by CodeRabbit
릴리스 노트
새로운 기능
버그 수정