190819 Mon TIL

오랜만에 쓰는 TIL

7월 25일부터 본격적으로 리액트, 리덕스를 공부하겠다고 마음 먹은 후 약 약 20일 경과 후 느낀 점을 적어보자

물론 새로운 걸 배우는 거니까 당연히 어렵다. 그래도 토이프로젝트긴 하지만 리액트 웹앱을 만들어 보긴 했고, redux 튜토리얼을 뗐으니까 할 만할 거라고는 생각했는데, 생각보다 더 어렵다.

일단 토이프로젝트한 뒤로 시간이 많이 지나서 많이 까먹은데다, 그 뒤로 Hook이 새로 나와서 기존 라이프사이클 메서드랑 훅을 익히고 적용하는 것도 쉽지 않았다.

새로운 개념도 개념이지만, 이번에 배우면서 가장 크게 느낀 건 설계에 관한 부분이다. 상태를 어떤 구조로 가져갈 것인지, 컴포넌트 트리 구조를 어떻게 가져갈 것인지. 어떤 컴포넌트를 추출해야 할지, 어떤 커스텀 훅이나 HOC가 있으면 코드가 간결하고 보기 좋을지. 어떤 컴포넌트 레벨까지 상태를 갖고 있는게 바람직한지. 스마트 컴포넌트랑 덤 컴포넌트를 나눠서 가져갈지 아니면 그냥 컴포넌트 폴더 내에 넣고 data 폴더를 따로 빼야 하는지. api 콜은 어디서 어떤 함수를 사용해야 렌더링을 효율적으로 하면서 비동기 프로그래밍이 잘 이루어질 지 함수명은 정말 이게 최선인지(...) 등등.

구글링을 한다고 해도 딱 내가 원하는 것을 찾기가 쉽지 않다. 나는 정답을 알 수 있는 경우라도 문제를 혼자 해결하는 것을 좋아해서 웬만하면 구글링으로 해결해보려고 하는데, 그래도 도무지 도무지 내가 원하는 답을 찾을 수 없는 때가 있다.

예를 들어서 이번에 가장 오랫동안 고민했던 것 중 하나가 api를 호출해서 포스트 목록을 가져온 뒤 각 포스트의 코멘트 목록을 불러와서 렌더링하고 싶었는데 도대체 그 getComments 액션을 어디에서 호출해야 하는지 모르겠는 거다. 당시 나의 고정관념은, 액션생성자를 리액트 컴포넌트 쪽에서만 콜해야된다고 생각했던 것이다. 리덕스 쪽에서는 액션 생성자, 리듀서와 같이 함수만 만들면 되고 이것을 콜하는 건 리액트 쪽에서 하는 거라고 편견(?)을 갖고 있었다. 그리고 왜인지 모르겠지만 post 액션끼리는 서로 호출해도, comment 액션을 post에서 호출하는 건 생각을 못했다. 리액트 쪽에서 아무리 시도를 해도 원하는 결과가 안나왔고 구글링으로도 못찾았는데 결국 다른 분이 하신 코드를 참고해서 답을 알았다. 그냥 리덕스 액션생성자 내부에서 다른 컴포넌트의 액션 생성자를 콜할 수도 있는 거였다... 그래서 애초에 getPosts를 콜하면 그 내부에서 getComments도 호출되도록 짜면 되는 거였다.. thunk가 익숙지 않아서 생각하지 못한 것도 있겠지만.

물론 스택오버플로우라든지, 코딩 관련 질문을 남기는 곳에다 물어봐서 해결할 수도 있지만 아무래도 빨리 해결 방법을 알려줄 수 있는 사람이 근처에 있는 게 좋은 것 같다는 생각이 들었다. 혼자 삽질하는 시간이 너무 길어지면 비효율적이니까. 그리고 그게 해결이 안 되서 정말 답답해 죽는 줄 알았기 때문에...

이번에 모르는 개념을 많이 익혀야 했다. 그런데 처음부터 구현하려는 기능 위주로 접근하다 보니까 결국 구현을 못하는 문제가 생겼다. 그러니까 비동기 액션을 작성해야 하는데 애초에 리덕스에서 비동기 프로그래밍이 어떻게 이루어지는지 잘 모르는 상태에서 코드를 먼저 짜려고 했다든가... 결국 리덕스 비동기 도큐멘테이션부터 다시 봐야 했다. 그리고 리덕스는 확실히 도큐멘테이션이 잘 돼있다. 튜토리얼도 단계별로 코드가 잘 정리돼 있어서 좋았고 따라하는게 많이 도움이 됐다.

다만 처음에는 모르는 개념을 영어로 보려고 하면 이해하기 어렵기 때문에 한글화된 도큐멘테이션을 봤는데 코드라든가 설명이 일부분 업데이트가 되어 있지 않아서 종종 원문이랑 비교하면서 봤다. 개념을 좀 이해하고 나면 그때부터는 배경지식이 조금 생겨서 영어로 봐도 괜찮지만 아무것도 모르는 상태에서 익히기엔 한글이 아무래도 편하다. 한글화의 중요성을 느꼈고, 잘 정리해서 포스팅하는 개발자들은 정말 대단한 것 같다고 생각했다.

그리고 도큐멘테이션이 또 중요하다고 생각한 이유는, 뭔가 알 수 없는 에러가 나서 디버깅하는데 시간을 많이 허비했는데 알고 보니 리듀서에서 상태를 mutate해서 그런거 였다. 도큐멘테이션에선 강조 또 강조하고 있는 기본적인 부분이고 애초에 상태 immutation과 관련해서 섹션이 따로 정리돼 있을 정도니까... 그걸 제대로 봤으면 그 정도로 삽질은 하지 않았을 것이다.

그러다 리덕스랑 HOC랑 훅을 활용하니 중복되는 부분이 많이 줄었다. 리덕스 덕에 상태를 번거롭게 주고 받는 일도 줄고, 중복되는 부분은 HOC로 따로 빼서 구현할 수도 있고, 훅을 사용하면 라이프사이클 메서드를 중복해서 사용하지 않아도 된다.

맨 위에서 말한 것처럼 설계 관련된 것일 수도 있는데, 리액트 리덕스는 자유도가 높아서(?) 어떤 서드파티 라이브러리를 가져와서 조합할지, 컴포넌트랑 상태를 어떻게 구성하고 조합할지는 개발자 하기 나름이다. 그래서 이걸 이렇게 하는게 더 좋은건가, 저렇게 하면 더 나을까 고민도 많이 되고 선택지가 많으니 혼란스럽기도 했다. 이건 프론트엔드 개발의 특징이기도 한 것 같다.

이런 고민을 계속 하려면 분명 다른 선택지도 공부를 해야 어떤게 더 나은지 알 수 있을테니까 배울 것이 엄청 많다고 생각했다. 예를 들어 date-fns가 나은지 moment.js가 나은지. fetch가 나은지 axios가 나은지. immutable.js를 사용해야 할지 말지. 웹팩이 나을지 파셀이나 다른 번들러가 나을지. 미들웨어 관련해서도 이제 thunk를 배웠으니 saga를 배워보려고 한다. 그리고 앞으로도 계속, 계속, 계속 배우고 고민해야 하겠지.