Conversation
donggyu412
commented
Dec 14, 2025
donggyu412
commented
- 추천 식단 금지 식재료 관리 , 선호 식재료 관리 api 연결
- 선호 식재료 모달 추가
- 비선호 식재료 모달 추가
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
| }, | ||
| }); | ||
| export default ChatbotSettingsModal; |
There was a problem hiding this comment.
코드 패치에는 다음과 같은 이슈가 있습니다:
-
상태 유지:
selectedMode와selectedStyle의 초기값으로currentMode와currentStyle을 사용하고 있습니다. 이로 인해 컴포넌트가 렌더링될 때 한 번만 설정되며, 이후 컴포넌트가 갱신되더라도 이 값들은 변경되지 않습니다. 이를 해결하려면useEffect를 사용하여 props가 변경될 때마다 상태를 업데이트해야 합니다.useEffect(() => { setSelectedMode(currentMode); setSelectedStyle(currentStyle); }, [currentMode, currentStyle]);
-
TypeScript
as any사용:mode.value as any와 같은 코드에서any타입을 사용하는 것은 타입 안전성을 해치며, 이후 디버깅을 어려운 상황에 처할 수 있습니다. 여기서는 적절한 타입을 지정하는 것이 중요합니다. -
키 값 검증:
key속성으로mode.value와style.value를 사용하고 있는데, 만약 값이 중복된다면 React에서 성능 저하나 예기치 않은 버그가 발생할 수 있습니다. 이 값들이 유일하다는 보장이 필요합니다. -
기능 테스트: 이 부분은 UI 테스트와 연결되며, 사용자가 설정을 변경한 후에
onSave가 적절히 실행되는지, 나중에 불러올 때 초기값으로 옳게 작동하는지 확인해야 합니다. -
UI/UX 개선: 세부적인 UX 측면에서 설정이 적용된 후, 사용자에게 피드백을 제공하는 것이 좋습니다. 예를 들어, 저장 후 알림 메시지를 보여주거나 화면을 피드백하여 사용자가 설정이 저장되었음을 확인할 수 있도록 하면 좋습니다.
이 외에도 코드 정리 및 주석을 추가해 가독성을 높이는 것이 좋습니다.
| saveBtnText: { fontSize: 16, fontWeight: "700", color: "#111" }, | ||
| }); | ||
|
|
||
| export default DislikedFoodsModal; |
There was a problem hiding this comment.
코드 검토 의견
-
에러 핸들링 개선
catch (error)대신catch (error: any)를 사용하는 것이 타입 일관성을 유지하는 데 도움이 됩니다. TypeScript를 사용할 경우error의 타입을 정의하는 것을 고려해 보세요.
-
중복 코드 제거
loadDislikedFoods()및setDislikedFoods(...)의 호출이 중복된 것 같으므로, 중복을 피하고 싶은 경우 함수화를 고려해 보세요.
-
API 응답 처리
userPreferencesAPI.getExclusions(userId)및userPreferencesAPI.addExclusions(userId, foodsToAdd)의 응답 구조에 대한 명확한 검토가 필요합니다. 응답 형식이 예상과 다를 수 있으므로, 이를 처리할 수 있는 로직이 필요합니다.
-
Async/Await 사용 주의
handleAdd()내부에서await loadDislikedFoods();가 호출되는데, 해당 함수가 종료될 때까지 기다릴 수 있는지 주의가 필요합니다. 데이터 일관성에 문제가 생길 수 있습니다.
-
KeyboardAvoidingView 사용
- KeyboardAvoidingView를 사용하는 부분은 잘 처리되었지만, 키보드의 크기나 화면 크기에 따라 배치가 변할 수 있다는 점을 고려해야 합니다. 적절한 테스팅이 필요합니다.
-
StyleSheet 최적화
StyleSheet.create내에서 스타일 객체를 정의하는 것이 좋습니다. 스타일 지속성을 고려해서 가독성을 높이기 위해 자주 사용하는 스타일은 별도로 정의해 활용할 수 있습니다.
-
React-Native 버전 호환성
- 사용한 React Native 컴포넌트들과 개념들이 현재의 React Native 버전에서 제대로 동작하는지 확인해야 합니다. 예를 들어,
KeyboardAvoidingView의 behavior prop이 버전별로 다를 수 있습니다.
- 사용한 React Native 컴포넌트들과 개념들이 현재의 React Native 버전에서 제대로 동작하는지 확인해야 합니다. 예를 들어,
이 모든 점을 고려하여, 이 코드는 검토가 필요합니다. 여전히 merge할 생각이 있다면 위의 사항을 수정하는 것을 권장합니다.
| }, | ||
| }); | ||
|
|
||
| export default PreferredFoodsModal; |
There was a problem hiding this comment.
코드 패치 전반적으로 잘 작성되었으나, 아래의 몇 가지 점을 고려할 필요가 있습니다:
-
로딩 상태 관리:
initialLoading상태를 관리하는 로직이 적절하게 작성되었지만,Preferences데이터를 로드할 때 에러를 처리하는 부분에서processing상태 또한false로 꼭 변경해야 합니다. 이로 인해 사용자가 중복된 요청을 보낼 수 있는 리스크가 있습니다. -
중복 검사 주의:
handleAdd함수의 중복 검사에서preferences상태를 사용하고 있습니다. 이는 컴포넌트 처음 로드 시 초기화된 상태일 수 있으므로, 음식 추가 후 서버에서 중복을 검사하는 API가 필요할 수 있습니다. 사용자가 임의로 리스트를 수정했을 경우 예상치 못한 동작이 발생할 수 있습니다. -
에러 메시지 구체화: 에러를 처리할 때, 사용자에게 더욱 구체적인 정보를 전달하는 방식이 좋습니다. 단순히 "오류, 음식 추가하지 못했습니다"보다는 어떤 종류의 오류인지 더 구체적인 메시지를 제공하는 것이 사용자 경험에 도움이 될 것입니다.
-
onUpdate 콜백 검증:
onUpdate가 옵션으로 설정되어 있지만 필수일 경우는 해당 부분에서 propTypes 또는 TypeScript의 타입 검사를 통해 명시하는 것이 좋습니다. 이는 작업 중에 더 명확한 사용자 피드백을 줄 수 있습니다. -
asynchronous 운영 주의:
handleRemove함수의 삭제 요청 후 로컬 상태를 즉시 업데이트하고 있는데, 이는 사용자 경험을 향상시키긴 하나, 서버 요청이 실패할 경우 문제가 발생할 수 있으므로, 로컬 상태 업데이트 전에 반드시 서버 응답을 확인하는 로직이 필요합니다. -
모달 밖 클릭 시 핸들링: 현재
Modal의 외부 클릭 시 닫히도록 하는 기능이 누락되어 있는 것 같습니다. 이는 일반적으로 모달을 사용할 때 필요할 수 있는 기능입니다.
위의 내용을 개선하면 안정성과 사용자 경험 향상의 측면에서 긍정적 영향을 줄 수 있습니다.
| throw new Error(error.message || "선호 음식 삭제에 실패했습니다."); | ||
| } | ||
| }, | ||
| }; |
There was a problem hiding this comment.
코드 리뷰 코멘트
-
에러 처리 변경:
getExclusions및getPreferences에서 404 에러가 발생했을 때, 빈 배열을 반환하는 로직이 추가되었습니다. 이는 유용할 수 있지만, API 호출이 실제로 실패했을 때, 사용자가 이를 인지하지 못할 위험이 있습니다. 추가적인 로깅이나 통지를 고려해야 합니다.
-
리턴 타입 미지정:
getExclusions와getPreferences함수의 리턴 타입이 지정되어 있지 않습니다. TypeScript의 이점을 활용하기 위해, 정확한 반환 타입을 명시하는 것이 좋습니다. 예를 들어,Promise<ExclusionResponse[]>와Promise<PreferenceResponse[]>와 같이 지정하면 더 명확합니다.
-
중복된 코드:
- 비슷한 로직이
addExclusions와addPreferences두 곳에 존재합니다. 각각의 음식 이름을 추가하는 반복문을 공통 함수로 분리하면 코드의 중복을 줄이고 유지보수를 쉽게 할 수 있습니다.
- 비슷한 로직이
-
에러 타입 불확실성:
- 에러 처리 시
error의 타입이any로 설정되어 있습니다. 보다 구체적인 에러 타입을 사용하면 에러 핸들링을 더욱 정확히 처리할 수 있습니다.
- 에러 처리 시
-
대기 시간 고려:
addExclusions에서 각 음식에 대한 API 호출을 순차적으로 진행하는 경우, 많은 음식이 있을 경우 비효율적일 수 있습니다.Promise.all을 사용하여 병렬로 API 호출할 수 있는 방법을 고려해볼 수 있습니다.
-
요청 내용의 유효성 검사 부족:
userId와foodName이 유효한지, 혹은 NULL 체크가 필요합니다. 이 검사를 통해 API 호출 전에 불필요한 요청을 방지할 수 있습니다.
이 외에도, 주석에서 한국어와 영어가 혼합되어 있는 점, 일관성을 유지하기 위해 한국어로 통일하는 것이 좋습니다.
|
|
||
| export interface PreferenceDeleteResponse { | ||
| status: "deleted"; | ||
| } |
There was a problem hiding this comment.
코드 리뷰 코멘트
-
중복 코드: 현재 코드는 단순히 타입 정의를 복사해서 붙여넣은 것처럼 보입니다. 만약에 여러 곳에서 사용되고 있는 공통적인 타입들이라면, 이를 별도의 모듈로 분리하거나 공통 타입으로 정의하여 재사용성을 높일 수 있습니다.
-
타입 안정성:
any타입의 사용이 여러 군데 보입니다 (any[][]). 이러한 경우는 타입 안정성을 해치지 않도록 구체적인 타입을 정의하는 것이 좋습니다. 예를 들어,routine의 구조가 정해져 있다면, 구체적인 타입으로 명시하는 것이 바람직합니다. -
주석 문서화 부족: 각 인터페이스에 대한 간단한 설명은 있지만, 각 프로퍼티의 의미나 예상되는 값의 범위에 대한 설명이 부족합니다. 타입스크립트의 명확성을 높이기 위해서 주석에서 더 많은 세부 정보를 제공하는 것이 좋습니다.
-
확장성 고려: 어떤 프로퍼티는
optional입니다만, 기본값 또는 유효성에 대한 검증 로직이 명시되지 않아, 이로 인해 잠재적인 런타임 오류가 발생할 수 있습니다. 이 경우에는 타입 체킹 후에 제공되는 기본값을 설정하거나, 필수로 변경하는 것이 좋습니다. -
일관성: 인터페이스의 일부 이름(예:
foodName,food_id)이 서로 다른 네이밍 컨벤션을 따르고 있습니다. 이러한 일관성을 유지해야 팀원 간의 이해도를 높일 수 있습니다. -
테스트와 검증: 이 타입들을 사용하는 부분에서 잘못된 타입이 전달될 경우를 대비해 단위 테스트를 추가하는 것을 고려해야 합니다. 타입스크립트에서 제공하는 타입 안정성을 더욱 잘 활용하려면, 구현부와 타입 체크를 결합한 추가 검증 로직이 필요합니다.
| } | ||
| return []; | ||
| } | ||
| }; |
There was a problem hiding this comment.
이 코드 패치에서 몇 가지 우려사항과 개선점이 있습니다:
-
에러 처리: Axios 오류를 처리하는 방식이 일부 일관되지 않으며, 에러 발생 시 다루기 힘들 수 있습니다.
throw error구문이 catch 블록에 출현하지만, 모든 에러가 위에서 던져질 수 있는 것은 아닙니다. 예를 들어,getInBodyByDate함수에서 모든 날짜 형식 총 실패 상황에서 에러를 throw하고 있지만, 이 패치의 다른 부분에서는 동일한 호출에서 처리되지 않은 에러가 발생할 수 있습니다. 이렇게 되면 오류 발생이 더 불명확해질 수 있습니다. -
응답 검증: 각 API 호출에 대한 응답이 성공적인 형태인지를 검사하는 로직이 부족합니다. 예를 들어,
response.data의 구조가 기대하는 것과 다를 경우에 대한 처리 로직이 없습니다. 클라이언트가 잘못된 데이터 형식을 받는 경우, 특히 TypeScript를 사용하는 경우에 문제가 발생할 수 있습니다. -
타입 검증:
any타입을 사용하는 대신, 특정한 형태의 인터페이스나 타입을 정의하여 활용하면 정적 타입 검증의 이점을 살릴 수 있습니다. 이는 코드의 안정성을 높여주고, 개발 도중 실수를 감소시킬 수 있습니다. -
로깅일관성: API 요청 및 응답에 대한 로그가 있지만, 모든 함수에서 동일한 정보 수준으로 기록되지 않고 있습니다. 로그의 통일성을 유지하면 디버깅에 초점을 맞출 수 있습니다, 예를 들어 각 함수에서
console.log를 사용하는 방식이 상이합니다. -
Null 반환 처리: 특정 데이터 없음에 대해 null을 반환하는 경우와 빈 배열을 반환하는 경우가 섞여 있습니다. 환자 이름, 예를 들어 getInBodyList와 getLatestInBody에서 null을 반환하고 getInBodyHistory에서는 빈 배열을 반환합니다. 이러한 일관성 문제는 코드의 가독성을 떨어뜨릴 수 있습니다.
이상의 이유로 해당 코드 패치는 개선이 필요하며, 특히 오류 처리 및 데이터 검증 부분에서 더 나은 접근이 요구됩니다.
1 participant
