<aside> ⭐ 학습목표
<aside> 💬 TIL
24년의 첫번째 원티드 프리온보딩 챌린지 강의. 이제는 습관처럼 신청해서 보게 되는 것 같다. 첫번째 시간에는 전역 변수와 전역 상태 관리를 위한 라이브러리를 훑어보았다. 강의 중 언급되었던 많은 전역 상태 라이브러리에 대해서 알게 되었을 뿐만 아니라 그러한 라이브러리를 직접 사용해본 사람들의 의견도 함께 들을 수 있어서 의미있었다.
나는 전역변수 툴을 많이 사용해 보지도 않았을 뿐더러 사용해봤던 ContextAPI와 Redux도 사실 아직까지는 문서를 보고 사용해야 할 정도로 익숙치 않지만 여러 가지를 사용해보는 것 보다 한가지를 잘 사용하는 것이 중요하다는 이야기에 고민을 좀 하게 되었다. 내가 유일하게 학습해 본 상태관리 라이브러리는 Redux인데, Redux의 많은 복잡성과 보일러 플레이트 코드, 높은 러닝커브로 최근에는 선호되지 않은 경향이 있기 때문이다. 채용공고를 살펴보면 아직도 Redux를 기술스택에 넣는 공고가 많지만 그들이 원하는 만큼 자유롭게 사용할 정도는 아니기 때문에 좀 더 사용성이 편리한 기술을 공부해볼까 생각하면서 React Query를 눈여겨 보고 있었기 때문이다. 그런데 React Query는 전역 상태관리 라이브러리라기 보다는 서버의 상태를 관리하는 라이브러리라고 해서 또 한번 고개를 갸우뚱하는 중이다. 음…🤨
전역 상태와 상태관리 라이브러리에 대한 강의 뿐만 아니라 지역변수와 전역변수에 대해서도 다시 한번 되짚어보는 계기가 되었다. 너무 기본적이어서 소홀했던 var, let, const 등의 변수의 유효범위와 호이스팅에 대해서도 다시 되짚어보았다.
작은 개인 프로젝트를 하며 상태관리 툴의 필요성을 다시 한번 생각해보고 싶다는 생각도 들었다. 이전 팀 프로젝트를 진행하며 “우리 상태관리 라이브러리는 뭘 쓸까?” 라며 너무나 당연시하게 전역 상태관리를 위한 라이브러리가 필요하다고 생각을 했었다. 그게 단지 로그인 여부나 다크모드 등의 테마 기능을 위해서 였다면 나는 깊게 고민해보지 않고 그저 “사용을 해봐야한다”라는 학습 의식에만 몰두했었던 것 같다는 생각이 이제서야 들었다. 그래서인지 당시 프로젝트를 진행하면서도 어떤 부분을 전역 상태관리를 해야할지 고민을 했었고, 같은 팀원 중 한명도 나와 같은 생각을 한듯 고개를 갸우뚱했다. 결국 나의 프로젝트는 사실 Redux에 API 호출 코드만 가득했었던 것 같은데 지금 다시 보니 내가 뭘 하려고 했었는지 잘 모르겠다. 면접에서 누군가 물어보면 아무것도 대답을 못하고 탈탈 털릴것 같다. 휴, 이걸 어쩌지? 여튼 “어떤 상태를 전역 상태로 관리할까?” 라는 답은 프로젝트 시작 전에 기획을 보며 떠올릴 수 있을 정도가 되어야 하는걸까? 익숙한 프론트엔드 개발자라면 그렇게 개발을 시작하지 않을까? 라는 생각이 든다. 나는 언제 개발이 익숙한 프론트엔드 개발자가 될 수 있을까.
</aside>
📖 table of contents
React에서 state란 상태, 컴포넌트 내에서 변할 수 있는 값을 의미한다. state가 변경되면 React 컴포넌트는 새롭게 호출되고, 리렌더링 된다.
상태는 지역 상태와 전역 상태로 구분할 수 있는데, 지역 상태는 특정 컴포넌트 내에서만 관리되는 상태를 뜻한다. 다른 컴포넌트들과 데이터를 공유하지 않으며, 하위 컴포넌트로 데이터를 전달하기 위해서는 props를 사용하는데 어플리케이션의 크기가 커질수록 props drilling이 증가하여 반복작업이 많아지고 유지 보수가 어려워지는 단점이 있다. 따라서 하나의 상태를 여러 곳에서 사용하기 위해서는 전역 상태 관리를 할 필요가 있다.
React에 한정짓지 않고 프로그래밍 관점에서 비교한다면, (상태의 값을 저장하는 장소인 변수라는 용어를 사용하겠다)
| let | const | var | |
|---|---|---|---|
| 유효 범위 | 블록 스코프 | 블록 스코프 | 함수 스코프 |
| 값 재할당 | 가능 | 불가능 | 가능 |
| 재선언 | 불가능 | 불가능 | 가능 |
var로 선언된 변수는 호이스팅되어 코드의 맨 위로 끌어올려지며, 선언 전에 사용해도 에러가 나지 않는다.