TIL-221126- 어떤 문제인지 헛다리를 짚었구나..

어제 로그인 시 ApiService에 setAccessToken을 여러곳에 해야 하는 상황이 발생해서 상속을 통해서 accessToken을 set해주는 과정을 하나의 모듈만 하게 바꿨다.

 

내가 문제점으로 꼽은 것 은 로그인 시 에 setAccessToken이라는 똑같은 코드를 5번이나 해주는 것을 문제로 보아서 이를 해결하기 위해서 상속을 통해 해결을 할려고 했었다.

 

하지만 문제점의 타겟을 잘못잡았었던 것 같다. setAccessToken 코드를 5번 적어야 하는 것이 문제가 아니라 setAccessToken을 5번이나 호출을 해야 하는 이 구조자체에 빨간불이 들어왔다는 것이다.  REST API의 설계자체가 이상한 구조일 가능성이 크다. 

 

 

일단은 URI 설계가 잘못됬다. inquiries(상품 문의) 상품 문의는 이름에서 볼 수 있듯이 상품이 없으면 상품 문의라는 게 있을 수 없는 형태인데 

 

products/productId/inquiries => 처럼 되야 하는 게 올바른 형태인 것 같다. 이렇게 REST API를 설계했던 이유는 ProductController의 크기가 너무 커지지 않을까? 하는 걱정으로 나누 것인데 이 생각 자체가 틀려먹은 생각이다.

 

Contoller는 리소스 단위로 묶어서 관리하기 위함인데 굉장히 이상한 형태로 코드를 만들고 있었다...  상세페이지를 만드는데는 ProductController말고는 필요가 없었구나... 

 

 

그리고 오늘 알게 된 것 페이지네이션도 또 이상하게 하고 있었는데 

 

 

아래 쪽에 이상한 이름의 함수가 하나 있는데 기존에 하던 페이지네이션 방식인데 처음에 페이지가 마운트 될 때 문의를 불러올 함수와 

페이지를 클릭했을 떄의 함수를 서로 분리해서 사용을 하고 있었는데 이렇게 할 필요 없이 위의 코드처럼

page = 1 이라고 해주면 page가 없을 경우는 default를 1로 잡아줄 수 있다.. 쓸데 없는 함수들이 많이 있었다.

 

 

REST API를 다시 설계를 해야해서 리팩토링을 엄청나게 많이 해야 하는데.. 이번 주 스프린트가 내일밖에 안남은 상황이라 일단은 목표 달성을 위해서 결제페이지까지는 만들고 다음 스프린트 목표로 잡고 리팩토링을 시작해야 할 것 같다.  그리고 레이아웃도 디자이너님 한테 넘겨야 하는 상황인데...  아.... 

 

 

 

 

 

 

 

 

열심히 하자...