- 확장성을 고려한 반환 값 설계 - 응답으로 특정 문자열만 반환하게 되면 확장성이 떨어지게 된다. api를 다루는 함수의 경우에는 성공, 실패, 데이터를 모두 가지게 되는 경우가 많은데 특정 문자열만 반환한다면 데이터를 받을 수도 없고, 사용하는 곳에서는 문자열이 있으면 실패로, 없으면 성공으로 처리해야 하는 암묵적인 룰을 가지게 되기 때문에 좋지 않은 방법인 것 같다. 따라서 특히 api를 다루는 함수에서는 반환 값을 객체 형식으로 유지하도록 하자.
interface HttpResponse<T> {
error?: Error;
data: T;
}
or
interface HttpResponse<T> {
success: boolean;
data: T;
errorMessage: string;
}-
좌변의 타입? nono - 좌변에 타입을 붙이게 되면 코드로 거짓말을 하고 있는 것일 수도 있다. api를 사용할 땐, 해당 api의 인터페이스를 확인해서 인터페이스에 맞춰서 사용을 하게 되면 좌변은 알아서 타입 추론이 될 것이다. 따라서 좌변에 타입을 붙이는 경우는 많지 않고, 특수한 경우에만 좌변에 타입을 붙이게 된다.(우변의 리턴타입이 자식 타입인데 추상에 의존하기 위해 부모 타입으로 선언한다든가 하는 경우?? 아직은 잘 모르겠다.)
api의 인터페이스를 잘 확인해서 사용하는 것에 집중하자. -
커스텀 훅 - 컴포넌트의 상태를 관리하기 위해 커스텀 훅을 만드는 것이 만들지 않는 것 보다 좋을까?
나는 커스텀 훅을 만들게 되면 에러 처리 로직, api 통신 로직과 같은 컴포넌트에서 굳이 알고 있지 않아도 되는 로직을 모두 분리할 수 있게 되어서 좋다고 생각한다. 리액트는 선언형 프로그래밍을 지향하기 때문에 최소한 컴포넌트 안에서는 선언형을 지켜야 한다고 생각한다. 그래서 커스텀 훅으로 상태를 모두 빼서 사용하게 되면 선언적인 컴포넌트가 만들어지고, 가독성도 좋아진다. 따라서 내 생각으로는 커스텀 훅으로 상태 관련 로직을 모두 분리하는 것이 좋다고 생각하고, 분리하지 않을 이유는 없다고 생각한다.
하지만 의존성에 관련해서는 조금 더 생각해봐야 할 것 같다. 피드백에 보이듯이 리액트에서 뷰로 변경한다고 했을 때, 모두 커스텀 훅으로 만들어서 리액트에 대한 의존성이 매우 높다면, 뷰로 변경하기 엄청 어려울 것이다. 하지만 이것이 커스텀 훅의 문제일까? 커스텀 훅의 문제가 아니라 굳이 커스텀 훅으로 만들지 않아도 되는 로직까지 커스텀 훅으로 만들었을 때 발생하는 문제라고 생각한다.
난 리뷰어님의 피드백처럼 커스텀 훅을 굳이 안 쓸 이유가 없다는 것에 동의한다. -
네이밍의 중요성 - 실생활에서 이름은 이름 자체만으로도 큰 의미를 가진다. 미용사는 머리를 만져주는 사람이고, 캐셔는 돈을 받는 사람인 것을 이름만 보고도 알 수 있다. 프로그래밍에서의 변수, 함수의 이름도 똑같다. 어떤 변수의 이름이 캐셔인데, 머리를 만져주는 행동을 하고 있다면 당황스러울 것이다. 이런 것들을 잘 생각해서 네이밍을 잘 할 수 있도록 노력하자.
-
로그아웃 서버통신? - 로그아웃을 할 땐 일반적으로 서버와의 통신을 한다고 한다. 지금까지 미션을 할 때, 로그아웃은 프론트에서 엑세스 토큰을 삭제하는 것으로 구현을 했었는데, 서버에서 토큰을 삭제하고 페이지를 새로고침하는 것으로 구현을 해야겠다는 생각이 들었다.
-
api 통신 - 컴포넌트 내에서 비동기 통신을 하는 것은 좋지 못하다. 왜냐하면 컴포넌트가 response의 status나 error까지 알고 있는 것은 책임이 너무 과하기 때문이다. 컴포넌트는 그저 데이터를 요청하고, 데이터를 받아오기만 할 뿐이다. 이 데이터가 api 통신에 의한 것인지, 로컬 스토리지에서 가져온 것인지는 알 바가 아니기 때문이다. 이러한 관점에서 볼 때, 커스텀 훅이나 서비스 로직으로 빼는 것이 현명한 선택인 것 같다. 재사용의 관점에서도 다른 로직으로 빼는 것이 훨씬 좋아 보인다.
