About

이번주 내용과는 관련이 적은 내용이지만..

1. props 구조 분해 할당

최근에 다른 분 코드리뷰를 할 기회가 생겨서 봤는데 props를 구조분해할당을 안하시길래 (props.name, props.value, props.changeHandler)와 같이 쓰시더라구요?? 물론 맞다, 틀리다 문제는 아니지만 저는 이것만큼은 강력하게 구조분해할당해서 쓰라고 어필하고 싶었습니다.

• 그분 입장은 회사 컨벤션이 이래서 이 방식에 익숙해졌다. 그리고 쓰다 보면 이게 편하다
• 제 생각에는 다른 사람의 코드를 이해해야하는 사람이 되어보니까 props.뭐, props.뭐뭐 이렇게 되어있다보니 계속 헷갈리고 코드의 의도가 명확하게 보이지 않아서 이해하는데 어려웠던거 같습니다. props를 추적하기도 어려웠고? 또 모든 컴포넌트마다 props.뭐, props.뭐뭐 로 되어있으니까 이 컴포넌트였는지 저 컴포넌트였는지 내가 보고 있는 컴포넌트가 맞는지 등등 헷갈리는 상황 등등
• 다른 분들 생각은 어떠신지?? 어떻게 쓰시는 편인가요?

2. context api는 컴포넌트간에 값을 공유하는 솔류션에 가깝다. 전역상태를 위한 솔류션이 아니다. 저도 동의하는 바입니다.

6주차 어바웃

1. zustand

스터디 첫 주에 효석님이랑 보경님이 zustand 추천하셨던거 생각이 나네요.. 그 때 당시에 저는 사이드 프로젝트에 recoil을 적용하고 있었는데 보경님이랑 효석님이 왜 zustand안쓰시냐고 물어보셨었는데 집에 가서 곰곰히 생각해보니 zustand를 쓰는게 더 좋은 선택인것 같아서 전역상태관리 라이브러리르 zustand로 바꿨습니다.

2. 상태 관리 라이브러리들

저의 경우에는 redux, recoil, zustand를 프로젝트에서, rtk를 회사에서 사용해 본 경험이 있습니다. 이렇게 적고 보니 많이 사용해봤네요 -> 노스택이 된 거 같습니다. 제일 최근에는 zustand를 사용하면서 신기했던건 리덕스나 리코일처럼 앱 최상단에 프로바이더가 없다는 것이 신기했습니다. 프로바이더가 없는데 어떻게 전역으로 상태관리가 가능하지?? 또 리덕스나 코드 형태가 비슷하면서 훨씬 간결하고 쓰기 편해서 개발자 경험이 좋았던 거 같습니다.

음.. 상태 관리 라이브러리 전쟁? 춘추전국시대라고 해도 될만큼 정말 많은 라이브러리가 있는거 같습니다. 리코일, 리덕스, 조타이, zustand, mobx, 발티오? 등등 여기에 적지 않은 것들까지 합하면 정말 많은 라이브러리가 있을 거 같아요. 요즘 들어 느끼는거지만 어떤 회사나 조직에 들어가게 된다면 거기서 사용하는 기술 스택을 사용하게 되겠지만 기술 스택을 선정하게 된다면 잘 선정하는 것도 중요하다고 생각합니다. 상태 관리 라이브러리에는 정답이 없습니다.

• 리덕스는 복잡하고 어렵지만 많은 개발자들이 사용하고 있고 레거시로 남아있습니다. -> 구글링이 편하고 여러 참고할 코드들이 많다는 장점
• 리코일은 리액트를 쓴다면 문법이 비슷해서 배우기에 편하고 개념자체가 꽤 쉽다는 장점이 있습니다.또 공식문서도 한국어 버전이 있습니다. 다만 아직도 정식버전이 나오지 않았고 최근에는 페이스북도 조타이로 바꿨다고 합니다?
• zustand는 최근 사용률이 많이 올라가고 있고 또 리덕스를 써봤다면 배우기에 꽤 쉽고 공식문서가 잘 되어있습니다. 또한 취준생 입장이라면 배워서 적용하는게 많은 메리트가 있다고 생각됩니다.

저는 이러한 관점이나 이유로 어떤 라이브러리를 쓸지 고민하고 선정했었습니다. 근데 결국에는 넥스트vs 리액트, css 프레임워크, 상태 관리, 서버 상태 관리, 이외에도 여러 라이브러리 등등 어떤 기술을 쓸지 고민하고 선택할 때 저에 경우에는 주로 트렌드(?), 사용자의 수?를 보고 따라가게 되었던거 같아요.

다른 분들은 어떻게 선택하시는지??

3. 325쪽 왜 상태 관리 라이브러리가 필요하다고 생각하나요??

비슷한 고민을 했던 적이 있습니다. 어떠 글을 보고 프론트엔드에서 클라이언트 상태 관리가 왜 필요한가?에 대한 주제였는데 저도 그 글을 읽고 그러네? 왜 필요하지? 와 같은 생각을 했었는데 최근에는 생각이 바꼈습니다. 시간이 지날수록 책 첫부분에서도 이러한 언급이 나오는데 웹이 웹페이지에서 웹애플리케이션으로 진화해가고 있습니다. 점점 복잡해지다 보면 필연적으로 전역 상태 관리가 필요한 경우가 너무 많고 또 컴포넌트 설계를 고민하다 보면 오히려 전역 상태 관리가 필요해지는 경우가 생기는거 같습니다.

그래서 저는 상태 관리 라이브러리가 필요하다고 생각하는데 다른 분들 생각은 어떠신지요??

왜냐면 최근에는 어떤 분은 회사에서 CTO가 전역 상태 관리 라이브러리 쓰지 말라고 했답니다, 이유는 context api만 써라, 전역 상태 관리 배우는것도 일이다. 그렇게 말해서 상태 관리 라이브러리는 도입을 안했다고 하네요

4. FSM(유한 상태 머신)

상태 관리 하니까 최근에 FSM(유한 상태 머신)이라는 개념을 봤던 생각이 나서 적어 봤습니다. 설명은 불가능하니 관심있으신 분들은 찾아보시면 좋을거 같습니다.