⌨️ 학습

useEffect

https://ko.reactjs.org/docs/hooks-reference.html#lazy-initial-state

Mutations, subscriptions, timers, logging, and other side effects are not allowed inside the main body of a function component (referred to as React’s render phase). Doing so will lead to confusing bugs and inconsistencies in the UI.

1차 React 프로젝트에서 나는 useEffect를 제대로 이해하지 못하고 사용했던 것 같다. 그래서 공식문서를 살펴보다가 useEffect에 대한 위와 같은 제한사항이 있는 것을 발견하였다.

다음과 같은 키워드를 얻을 수 있었다.
Mutations, Subscriptions, timers, logging, side effects

공식문서에 따르면, useEffect에 넘겨진 함수는 렌더 이후 실행된다고 한다. 기본적으로 effects는 매 렌더마다 실행되지만, 특정 값이 변경되었을 시점으로 실행 시점을 한정지을 수도 있다고 한다.

💻 회고

'구현'보다 '이유'에 중점을 두자

React를 활용한 1차 프로젝트를 통해 HTML과 CSS에 대한 자신감을 키울 수 있었다.

React라는 라이브러리를 잘 활용하기 위해 공식 문서를 탐독하고, Context API 같은 전역 상태 관리 툴도 사용해 보면서 원하고자 하는 기능을 능숙하게 구현하는 것도 중요하지만, 내 코드에 '이유'를 담는 코드를 작성하는 것이 훨씬 더 중요한 것 같다.

사실 내가 작성하는 코드들을 뒤돌아보면 대부분 뚜렷한 이유가 없다. '그냥 그렇게 사용하는 거라고 하니까'가 주된 이유다. 하지만, 프로젝트를 진행하면서 팀원들끼리 각자의 PR에 리뷰를 해주면서 느낀 점은 단 하나의 변수를 선언할 때에도 이유가 있어야 하고, 로직에도 이유가 있어야 한다는 점이다.

'이 부분은 왜 이렇게 코드를 작성하신 건가요?' 라는 질문을 팀원으로부터 처음 들었을 때의 당혹감이 아직도 선명하다.

나는 그 질문에 명쾌히 대답하지 못하고 '그냥...'이라는 말로 얼버무렸다. 그 날 매너리즘에 빠진 것처럼 코드를 작성하다가는 좋은 개발자가 되지 못하겠다는 생각이 들었다.

한 줄을 작성하더라도 좋은 코드를 작성해야 한다.그리고 좋은 코드를 작성하기 위해서는 내가 쓰는 코드가 나름의 '이유'가 있어야 한다. 그런데 지금 나는 '프론트엔드 개발을 배우는 과정에 있으니까'라는 핑계로 너무나도 안일하게 코드를 작성한 것 같다는 생각이 들었다.