Class Component: 옛날 방식이지만 중요한 것
React 공식문서에서는 더 이상 'Class Component'를 사용하지 말고 'Function Component'를 사용할 것을 권고하고 있지만, 그럼에도 'Class Component'를 학습해야 할 몇 가지 이유가 있다.
우선, 이미 많은 개발 문서들이 'Class Component'로 작성되어 있다. 이에 더하여, React에서 제공하는 유용한 기능 중 하나가 바로 'Life Cycle Function'인데, 해당 개념이 'Class Component'에서만 작동한다. 요컨대, 이미 개발되어 있는 많은 문서들을 다루고 lifecycle에 관한 개념을 이해하기 위해 Class Component를 학습해야 한다.
이전에 실습했던 '클릭버튼'을 class component 형식으로 만들어 봤다.
Class Component LifeCycle
이전에도 살펴봤던, lifecycle에 관한 구조화 이미지이다.
'Mounting'은 component의 시작을 의미한다. 인간의 생애주기에 비유하면 '탄생' 정도가 되겠다. 'Updating'은 말 그대로 updating이다. 사람도 삶을 살아가며 많은 변화가 있듯이, component에 어떠한 변화가 발생할 때의 과정을 'Updating'이라고 한다. 마지막으로 'Unmounting'은 component의 종료이다.
'Mounting', 'Updating', 'Unmounting'이라는 세 줄기의 lifecycle을 거쳐갈 때 사용되는 '함수'들이 바로 밑에 있는 '박스'들이다.
1) 먼저 'Mounting' 과정에서 사용되는 함수를 살펴봤다. 'Constructor'는 첫 번째로 실행되는 lifecycle 함수이기에, constructor에서 원하는 'state'를 말 그대로 '생성'해준다.
'getDerivedStateFromProps'는 이해가 잘 안돼서 일단 패스했다.
다음으로는 'Render'이다. 'Render'는 UI를 그려주는 함수이다. UI를 그려주고 DOM에 업데이트가 될 것이다. 일련의 과정을 거치면 'Mounting' 단계에서 마지막으로 호출되는 함수가 바로 'componentDidMount'이다. UI에 관한 셋팅이 완료되면 호출된다.
적절한 위치에 console을 찍어서 함수들이 잘 작동하는지 확인했다.
요약: 그래서 각각의 함수에서 무엇을 할 수 있고, 해야 하는가??
1. constructor: state를 만든다. 상태가 있어야 보여주든 말든 할 거니까 ㅇㅇ
2. render: UI를 그린다.
3. componentDidMount: API 호출
2) 다음으로 'Updating' 과정에서 사용되는 함수를 살펴봤다. 하이라이트 처리가 되어있지 않은 부분들은 이해하기 조금 어려웠다. 우선 updating 과정에서 render를 거쳤다고 치고 'componentDidUpdate' 함수에 집중했다.
이전에 'setState'는 비동기적 작동방식을 취한다고 학습한 바 있다. 비동기적이라 즉각적으로 UI에 반영되지 않는다는 것은 알겠는데, 그렇다면 'state'가 잘 업데이트가 되었는지 확인할 방법도 없는 것일까? 이러한 상황에 'componentDidUpdate'가 필요하다.
버튼을 눌렀을 때(=state가 update 되었을 때), increase function 직후에 찍은 콘솔에는 counter와 value에 대한 state 변화가 반영이 되지 않았다. 이게 바로 비동기적 작동방식의 단적인 예이다. 이후 render 과정을 거친 뒤에 'componentDidUpdate' 함수가 작동되는 것을 확인했다.
3) 마지막으로 'Unmounting'이다. 'componentWillUnmount'는 component가 종료될 때 실행되는 함수이다. 특정 숫자를 넘어가면 box에 해당하는 내용이 나오지 않게 설정했다.
state가 3보다 커지면 box가 등장하지 않게 된다.
box 컴포넌트에는 state가 종료되면 작동할 'componentWillUnmount' 함수를 입력했다.
숫자 3이 되자, box가 render 되지 않고 console에는 "종료되었다"라는 문구가 입력되는 것을 확인할 수 있었다.
Function Component LifeCycle
실제로 사용해야 할 것은 class가 아닌 'function' component이기 때문에, function 버전의 lifecycle 함수를 학습했다.
function component에서는 'useEffect'가 사용된다. 'useEffect'는 '콜백함수'와 '배열'을 매개변수로 받는다.
형식에 맞게 'useEffect'를 작성하고 console을 확인했는데, 클릭을 하기도 전에 등장했다. componentDidMount의 function 버전임을 알 수 있다.
빈 배열에 'counter2'를 넣어준 두 번째 'useEffect'를 만들어 줬다. 이후 '클릭'을 통해 state를 변경하니, render 다음으로 'useEffect2'만 등장하는 것을 확인했다. 배열에 state 값을 넣어주면 React가 해당 값을 주시하게 된다. 'componentDidUpdate'의 역할도 useEffect가 하는 것이다.
그런데 왜 하필 배열이지?? 배열은 '유한 집합'이다. '여러 개'의 데이터를 다루는 것이 배열의 본질이다. '업데이트'는 상태의 변화이고, 변화하는 상태가 한 가지라는 법은 없다. 배열에 다른 state를 넣어서 사용할 수 있게 하려고 굳이 배열을 사용하는 것이다.
두 번째 프로젝트: 날씨앱 만들기
프론트엔드의 꽃이라 할 수 있는 API를, 날씨앱 만들기를 통해 학습해 봤다.
밑에 있는 사이트에서 무료로 제공되는 API를 사용했다.
https://openweathermap.org/api
날씨앱에 대한 기본적인 셋팅이다.
현재 위치 가져오기
분명히 정상적으로 compile 되었다고 나오는데 console에서는 에러가 발생했다.
내 컴퓨터 환경에서 위치 기반 설정이 잘못되어있었다. 구글링에만 2시간 이상 사용한 것 같다. 문제를 해결하기까지 꽤나 힘들었지만 결국 해내서 뿌듯하다.
현재위치 기반 날씨 가져오기
들을까 말까 고민했는데 역시... 뇌에 과부하가 와서 다시 올림픽 공부법을 꺼냈다. 머리를 식힐 겸 개구리를 잡았다.
Flex 연습하기 with 개구리 옮기기
머리를 식힐 겸 시작한 개구리잡기...머리가 용광로가 됐다. 그런데 개구리 옮기기인데 왜 자꾸 '잡기'라고 하뉘?
아니 진짜 어떻게 했지?? 더 많이 해봐야 적응되겠다...
회고
공감(共感)이라는 것이 참 어렵다.
최근에 공감을 구할 일도 많았고, 또 공감을 해주어야 할 일도 많았다. 어떤 개념이 어렵게 다가오면 자기만의 '정의'가 없어서 그런 경우가 태반이다. 요즘에서야 "공감은 정성이 깃든 아는 척이구나"라는 정의 비슷한 것을 내렸다.
누군가가 다른 누군가를 완전히 이해하는 것은 불가능하다. 공감의 '공(共)'이 '한가지 공'이라는 점은 그 자체로 역설이다. '한가지'가 되는 것은 불가능하지만 '한가지'를 추구해야만 작동하는 글자이기 때문이다.
사전에 '공감은 남의 의견 따위에 대하여 자기도 똑같이 느끼는 것'이라고 정의되어 있는데 그렇다면 나는 왜 감사함을 느낄까, 그저 상대방이 내 이야기에 동조하는 것뿐인데. 동조에 깃든 정성이 감사하지 않았을까. 요즘 감사함을 많이 느낀다.
단순한 고개의 끄덕임은 껍데기에 불과하다는 것을 깨달았으니까, 나를 둘러싼 모든 것들에 정성을 다해야겠다. 공부도, 생각도 참 많이 한 하루였다. 내일도 화이팅!
