- Notifications
You must be signed in to change notification settings - Fork173
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
-
배열의 값을 받아오는 data fetching을 위한 함수를 구현하다 고민이 하나 생겼습니다. 예를 들면, // service, frontend API 호출 시exportconstgetGames=()=>{ ...};// UI, state, hook으로 작성 시 -> UI의 의미를 포함exportconstuseGameList=()=>{ ...};// DB, resource 직접 접근 시exportconstfindAllGames=()=>{ ...}; 제 나름대로 구분을 지어보긴 했는데 일관성이 없다는 생각도 조금 들고 고민이 되네요. |
여러 함수명 중 어떤걸 사용하시나요? "단위" + s 형식으로 작성한다. 76% "단위" + List 형식으로 작성한다. 23% "findAll"과 같은 형식으로 작성한다. 0% 13 votes· |
BetaWas this translation helpful?Give feedback.
All reactions
👍 2❤️ 1
Replies: 2 comments 1 reply
-
과거에는 ~~list보다는 ~~s를 선호했어요. 다수가 사용하는 컨벤션을 사용한다면 장점이 많기 때문에 코드리뷰에서 변경을 요청받은 경우도 있었습니다. findAll같은건 주로 ORM에서 많이 사용했던 것 같아요. 결국 팀 컨벤션에 맞춰 일관성 있게 사용하는 게 가장 중요한 것 같아요. 어떤 방식이든 팀 전체가 동일하게 사용한다면 문제없을 듯 합니다~ |
BetaWas this translation helpful?Give feedback.
All reactions
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
-
팀원들과 자주하는 고민 같습니다. 저는 이런 경우의 함수 이름은 되도록 데이터 및 타입와 연관 지으려고 노력하는 편인데요. interfaceGame{// ...}// case 1. Game의 배열을 그냥 Game[] 자체로 사용하는 경우constgetGames=(options?:unknown)=>{// ..constfetchedGames:Game[]=response.data;returnfetchedGames}// case 2. Game의 배열을 별도의 타입(~List)로 관리하는 경우interfaceList<D>{data:D;pagination:{currentPage:number;totalPages:number;nextPage:number;previousPage:number;}}typeGameList=List<Game>;constgetGameList=(options?:unknown)=>{// ...returnresponse.data;} 위 처럼, 모델로 관리하는 |
BetaWas this translation helpful?Give feedback.
All reactions
-
굳이 pagination이 포함된 List 같은게 아니고, |
BetaWas this translation helpful?Give feedback.