처음에 이 프로젝트를 시작하게 된 계기는 타입스크립트와 Tanstack Query가 너무 부족하다고 생각해서였음.
이전에 만들었던 TypeScript 프로젝트나 Tanstack Query는 어떻게 보면
내가 원하는 값, 구조로 만들었기 때문에 실제 현업에 가서 이 스택들을 빠르게 적응하기 어려울 것 같았음.
그래서 실제로 사용되는 OPEN API를 가져와서 이 스택들을 적용해봤는데 내가 너무 간단한 구조들만 지금까지 만들었었구나라고 생각하게 됨.
TypeScript
일단 TypeScript는 to.do.focus에서만 사용해봤고,
그 프로젝트는 api 연동이 필요가 없었고, TypeScript의 고급 기능 등을 사용해보지 않았었음.
또한, 프로젝트 자체가 내가 원하는 데이터 형식을 만드는 것이었기 때문에 실상 모델이 복잡하지도 않았었음.
그리고나서 이번 프로젝트를 진행하며
-
타입을 만드는게 정말 쉽지 않구나
-
모델을 정말 많이 만들어야하는구나
-
모델 만들다가 지칠 수가 있구나
-
제네릭은 미쳤구나
진정 왜 개발자들이 TypeScript를 한 번 쓰면 다시 JavaScript로 못돌아간다고 하는지 알게되었음.
그리고 와 진짜 타입 모델 만드는게 쉽지 않고, 너무 너무 많이 만들어야한다.
그래서 공통적인 타입 구조는 반드시 재사용 가능하도록 제네릭으로 만들어야하겠구나라고 생각함.
// 제네릭은 미쳤어요!!
export interface ApiResponse<T> {
href: string;
limit: number;
next: string | null;
offset: number;
previous: string | null;
total: number;
items: T[];
}그리고 실제로 사용되는 API를 활용하다 보니까 뭔가 좀 더 재밌었던 것 같다.
모르는게 막 나오니까 찾아보는 맛도 좀 있었고, 에러난 걸 해결하면 또 오 이것때문이었음? 이러면서 나름 재밌게 작업을 해나간 프로젝트였음.
Tanstack Query
그리고 Tanstack Query는 day6_Fanground에서 사용해봤는데 분명 이 때는 재밌게 했던 것으로 기억함.
근데 이번에는 로그인에, 데이터 패칭에... 전반적인 부분에 사용하다 보니까 이래저래 에러가 참 많이 발생했었다.
아마 그 전에는 데이터 호출만 했기 때문에 재밌게 했었던 듯...ㅎ
아직 프로젝트 마무리가 된 건 아니지만, 지금까지 진행했던 호출 중에서 제일 골치가 아팠던 부분은 플레이리스트 이름 변경이었음.
아니 분명, 데이터 호출도, query key도, refetch도 되었는데 왜 UI에는 렌더링이 안되는가...?
이 문제는 블로그로 따로 작성도 했음.[ QueryClient - setQueryData ]
아무튼 이런 경험을 겪으면서 Tanstack Query에 대해 좀 더 깊이 알게 된 계기가 되긴 했음.
그리고 역시 데이터 패칭은 Tanstack Query가 확실히 좋구나, 관리하기가 참 편하구나, 라고 다시 한 번 더 느낌.
그리고 여기서도 타입을 맞추는게 쉽지 않구나를 느낌.
api를 따로 만들고, Tanstack Query로 hook을 만들어서 사용했는데 api와 hook의 request/response 타입을 맞추는게 쉽지 않음을 느꼈음.
그리고 웬만하면 다 undefined에 대한 검증을 했는데, 이 부분은 공통 모듈로 하나 만들어야 할 지 아직도 고민하는 부분임.
직접적으로 if()로 체크하는게 안정적이긴 하지만, 뭐 할때마다 undefine 검증을 하라고해서 이럴거면 공통으로 빼는게 낫지 않을까 생각하게 된 부분임. 하지만, 아직 확정은 못하고 고민만 진행 중임.
앞으로 작업을 더 이어나가면서 어떻게 해야할지 봐야겠음.
어쨌든, 이 프로젝트를 시작하게 된 이유는 기술 사용에 대한 부족감을 느꼈기 때문임.
남은 작업 진행하면서 앞으로 기술들을 더 갈고 닦으면서 프로젝트에 대한 DR/TR과 문제 해결 블로깅을 이어나갈 계획임.
남은 작업들이 많아서 에러를 많이 만나게 되겠지만, 힘내자!
