[데브로드] 7주차 주간회고

이번 주 배운 것들

- HTML DOM API(Location, pathname)
- Router, Routes, Route
- React Router(Browser Router, Route, Memory Router, RouterProvider, NavLink, Link, Navigate, useNavigate)
- Web APIs - History

개인 공부
- 알고리즘 풀이(프로그래머스 알고리즘 5문제)
- React Router 전체 문서보고 tutorial 실제 따라해보기
- React 내부 까보기 개인 프로젝트 - React Element, Package 종류

이번 주는 너무 힘든 주였던 것 같다. 감기 몸살을 시작으로 예비군에 여러 가지 복잡한 일들이 겹친 주였다. 최대한 집중하며, 이번 주 미션들을 하나씩 해결해 나갔다. 이번 주는 React Router 라이브러리에 대해 배우게 되었다. 강의의 내용들을 이해하며 하나씩 실습해보고 개념들에 대해 알아나갔다. 근데도 React Router에 대해 지식적으로 부족하다고 생각하여, 추가적인 학습이 필요했다. 예비군을 갔다 오는 길의 시간을 활용하여 React Router에 있는 모든 문서를 다 읽었다. 이에 그치지 않고 다음으로는 집에 도착하자마자 React Router에 있는 tutorial를 하나씩 따라해 보면서 다시 문서들을 되짚어 보는 시간을 가졌다.

React Router를 배운 이번 주의 과제도 마찬가지로 라우팅을 이용해서 페이지를 분리하는 과제였다. 이번 과제에서 tutorial에서 배운 것들을 활용해보며 진행을 하고 싶어 상황에 맞게 최대한 사용을 해보았다. 렌더링하기 전에 route 요소에 데이터를 제공(useEffect에서 fetch를 받아오는 것과 같은 효과)하는 loader 함수도 활용해보고 Router 테스트 방법과 여러가지 hooks들도 사용해 볼 수 있어 매우 좋은 경험이 되었다. 그리고 이번에는 과제가 생각보다 일찍 끝날 것 같다는 느낌에 MSW을 과제에 직접 사용해보았다. 이론적인 내용들이나 어떻게 사용해야하는지에 대해 알고 있었고 Docs에도 매우 쉽게 나와있어서 금방 세팅을 하겠다라고 생각했던 나에게 엄청난 큰 시련이 다가왔다.

<수많은 도전을 하다가 열이 받아서 캡쳐한 사진>

Browser(브라우저 환경) 및 Node(테스트 환경)에 대해 세팅을 다한 상태였지만, 위와 같은 에러가 발생을 했던 것이었다. 난 진짜 억울했다. 공식문서에서 하라는 방법대로 그대로 했을 뿐이었는데 저 에러가 나를 괴롭혔었다. 모든 사람들이 해결책으로 제시한 것들이 모두 적용이 안 되었었다. 공식문서 마저 나를 배신했었다고 생각했다.

여러가지 해결 방법도 찾아서 적용을 해보았지만 집중에 문제가 있었던 건지 방향성을 잘못 잡은건지 멘붕이 왔을 때, 리프레쉬가 필요하다고 느껴서 잠시 놓고 운동을 다녀왔다. 다녀온 후 에러를 다시 되짚어보니 해당 주소창을 쳤을 때 public 절대 경로의 문제로 판결났다. 내가 연결해놓은 주소(http://localhost:8080/mockServiceWorker.js)를 주소창에 쳐보니 아무것도 나오지 않았었다. 이를 해결하기 위해 이전에 봤던 데브로드에서 운영하는 디스코드에서 데브오브플로우에 관련 내용을 본 적이 있었던 것 같아 찾아보았더니 dist 폴더에 넣어야 한다는 내용을 얻을 수 있었다. 그럼 왜 dist에 넣어야할까를 고민을 해보았는데 현재 사용하고 있는 bundler가 parcel인데 parcel의 default dist-dir이 dist로 설정되어 있기에 절대 경로로 설정하려면 dist 폴더에 넣어야 한다는 결과를 얻을 수 있었다. 물론 다른 번들러를 쓴다면 거기에 맞춰서 설정해 주면 될 것 같다. 데브로드 코스를 진행하는 중 제일 억울했던 부분이 풀려 너무 행복했다.

<MSW 성공했을 때 캡쳐한 사진>

MSW를 직접 사용해보니 기존에 fixture로 만들었던 mocks들을 사용하여 작성했던 test 코드에 선언을 각 테스트 파일마다 선언할 필요가 없어졌고, 내가 의도한대로 모든 테스트들이 편하게 흘러갔다. 특히 fetch를 테스트 하는 부분들이 우아하게? 처리되는 느낌을 가졌던 것 같다. 실제 Kent(Testing Library 개발자)도 fetch의 해결책으로 MSW를 다뤘던 글(https://kentcdodds.com/blog/stop-mocking-fetch#then-i-discovered-msw)도 적었었다. 또한 MSW를 통해 에러 따른 Component 테스트를 유연하게 처리할 수 있어 매우 유용하게 쓰일 수 있을 것 같다.

또한 이번 과제 테스트 진행하면서 fireEvent와 userEvent에 대한 지식도 습득했다. kent는 fireEvent를 쓰지말고 상위버전인 userEvent를 사용하라고 권장한다. 그럼 왜 권장하냐 라는 이유에 대해서 알고 userEvent를 사용해야한다 생각하여 이유를 알아보니, userEvent는 fireEvent 기반으로 구축된 패키지이며 사용자 상호작용과 더 유사한 몇 가지 메서드를 더 제공(input text를 테스트 한다고 했을 때 타이핑을 컨트롤(enter, space, del 등) 가능, 버튼 클릭 테스트를 한다고 하였을 때 doubleClick 테스트 가능 등)한다고 한다. userEvent는 마치 사람이 직접 브라우저 상에서 행동하는 것처럼 유저 이벤트를 발생시킬 수 있다.

내용 흐름상 개인적으로 느끼기에 코드 흐름상 읽기 편해진? 책을 읽는 느낌을 줄 수 있다? 라는 생각이었다. 물론 코드를 더 간단하게 할 수 있지만 설명을 위해 조금 풀어쓴 느낌도 있다. 추가적으로 render와 fireEvent와 마찬가지로 userEvent도 act 함수를 감싸줄 필요가 없다는 점도 자연스럽게 알게 되었다. 정리해보면 act 함수는 가상 DOM에 적용하는 역할을 해주는데, render와 fireEvent, userEvent는 내부에서 이미 act 함수를 감싸고 있어서 중복되는 act는 설정 안 하는게 좋다.

과제를 마친 후 저번 주에 나와의 약속을 했던 리엑트 까보기를 진행해 보았다. 이번 주는 react element에 대해 공부를 해보았는데 데브로드에서 진행했던 react element를 직접 구현해보는 실습, 매주마다 데브노트 작성을 위해 제시해 주는 키워드들이 내용을 이해하는데 너무 도움이 되었다. 엄청 길지만 공부했던 내용을 정리해보면 아래와 같다.

React element(종류: React DOM node element(type: string), React Component element(type: Function or Class))는 기존 OOP UI model의 문제점을 개선하기 위해 나왔으며, element는 DOM Tree 생성에 필요한 정보를 담은 plan object이고 화면에 그려질 것들을 props와 type으로 DOM node를 설명(중요: 실제 DOM이 아님)한다. 또한 reconcliation을 통해 react는 모든 DOM tree를 완벽하게 알게되고, react는 렌더링과 제거되는 부분을 파악 후 따로 진행한다. 이러한 결과 도달 할 수 있는 부분은 React component는 props를 input으로 받아 DOM Node를 출력하는 React로 만들어진 앱을 이루는 최소한의 단위이다.

마무리

진짜 모두들 이야기하는 건강이 제일 중요한 것 같다. 최대한 컨디션을 잘 유지하면서 다음 주도 힘을 내야겠다.