1. 문제의식과 동기: 왜 리덕스 스터디/공부를 하게 되었나 (+기존 알고 있던 리액트 상태관리에 대한 생각/경험)

창선: 제일 큰 이유는 현업에서 리액트와 리덕스를 묶어서 하나의 능력으로 요구하는 경우가 많아서 리액트를 기반으로 취업하는데 필요할 것 같아서... 기존 리액트는 상태를 각 컴포넌트 또는 고차함수나 컨텍스트 API 를 이용해서 관리해서 상태가 여기저기 흩어져 있는 경우가 많았는데, 리덕스는 스토어라는 진실의 유일한 원천에 상태를 모두 저장하기 때문에 찾거나 관리하기가 쉽다는 장점이 있는 것 같다. 사실 아직 체감할 정도는 아니지만 프로젝트 규모가 커지면 상태가 한곳에 모여있다는 장점을 체감할듯..?

지원: 취업.

지수: 취업.

강산: 우대사항에 리덕스.

지수: 리덕스가 별로 필요 없다고 해서 사실 그렇게 관심이 없엇음.

강산: 느낀 게 좋은 거 같다. 정확히 뭐가 좋은지는 모르겠음. 이런 부분에서 활용할 수 있을 게 있을 거 같다는 데에서 미들웨어로서. 중간에서 뭔가 액션과 리듀서 사이에 뭔가 해줄 수 있다라는 것도 장점인 것 같음. 잘 써야 장점이긴 하지만…

창선: 그냥 리액트에는 안되는 거니까.

지원: 디버깅할 때 에러처리를 리덕스가 하니까 fail 이 뜨는데 어디서 뜨는지 보이니까 진짜 좋았음. 프로젝트가 커져서 볼 때 시간여행하는 것처럼 볼 때 좋은 것 같음. 그것 때문에 좋은 것 같음.

창선: 리덕스 데브 툴.

(? 기존 리액트 상태에서 불편한 게 있었는지?)

2. Fact: 지난 5 주간공부/실습해 본 내용

창선: 댄 형님 강의를 기초부터 심화까지 들으면서 리덕스 사용법과 흐름에 대해 전반적으로 배웠다. 실습은 강의에서 진행하는 투두를 그대로 따라서 만들었고, 그 이후에는 제이슨 서버를 이용해서 쇼핑몰 기능을 구현해보려고 했다(사실 잘 안됨.. 어렵 ㅠ)

1)펀더멘털, 어드밴스드 강의 듣고 번역. 2)todo 를 만듦.

• action, reducer, store(메소드) 개념 익히는 걸 했고 • 관용적으로 많이 쓰이는 걸 해서 (셀렉터, 데이터 노말라이즈, 리팩토링/단축표기법, 상태를 로컬스토리지에 저장, 리액트 라우터랑 붙이고 리액트 라우터의 상태 쓰는거, 로깅 미들웨어, 비동기통신/썽크, 커링함수, 컴포넌트 나누는 것, 에러처리)
3)쇼핑몰 만들기

3. Feeling: 스터디를 하면서 느낀 감정

창선: 댄 형 강의 처음 들을때 할만하다가 심화 들으면서 슬슬 못알아듣다가 후반부에 멘붕터짐... 투두도 이해 못했는데 쇼핑몰 만들려니 넘 고통쓰.. 근데 계속 생각해보니 뭔가 알거같기도 하고 그러면서 결국 나는 오래봐야 이해가 되는 허접이였음을 느낌.. ㅠ

지수: 개발공부 이후로 제일 힘들었음.

창선: 후반부로 갈수록 너무 어려움.

지원: 답답함. 이해하는 게 절반 정도. 적용은 절대 못할 거 같다고 생각. 계속 보다보니 더 이해가 됐음. 지금은 패턴을 다른 데 적용할 수도 있겠다는 생각이 들었음. 그래서 기뻤음

강산: 처음엔 막막.

지원: 애매한거랑 진짜 아는 건 다름.

강산: 완벽한 이해보다는 어떤 흐름이다 정도를 아는 것이었음.

리덕스 처음에 만들 때 좋았음. 디스패치가 어디서 오는지를 알 수 있어서 좋았음. 막막했지만.

지수: 댄이 너무 아는 척 하는 거 같아서 힘들었음.

4. Finding: Redux 에 대해 새롭게 알게된 점과 교훈

창선: 사실 리덕스에 대해 아는게 없었기 때문에 모든걸 새로 알게 됐다고 해도 과언이 아닌 수준.. 그냥 상태관리만 전문적으로 해주는 라이브러리 수준인 줄 알았지만 그 상태를 리액트에서 효율적으로 사용하고 관리하기 위해 많은 것을 알아야 한다는 것을 깨달았다! 리액트를 사용해서 자체적으로 상태를 관리하는 것과 리덕스를 이용해서 리액트 바깥에서 상태를 관리하는건 개념적으로 매우 다르다는 걸 알게 되었다. 규모가 작은 실습 수준의 프로젝트에서는 상태와 변화가 많지 않아서 리액트 자체 상태로 충분히 관리 가능하지만 확실히 규모 있는 프로젝트에서는 리덕스가 더 효율적일 듯 하다. 그리고 상태 관리를 전부 리덕스 스토어에 맡겨놓는다는 것 자체가 역할과 책임을 분리하는 패턴이 되기 때문에 상태관리에 있어서 매우 효율적인 것 같긴 하다. 물론 리덕스가 진리는 아니고 몹엑스나 다른 상태관리 기법이 존재하지만 상태를 아예 따로 떼서 관리하는 개념 자체는 앞으로 프론트 개발을 함에 있어서 자주 접하게 될 기법 임에는 틀림이 없는 것 같다. 무조건 익숙해져야 할 기술인듯!!

강산: 로그인/인증을 처음에 했는데 프로젝트 세팅도 힘듦. 뭐 부터 작성해야 하는지?

창선: 액션을 먼저.

강산: 작명. 액션타입, 액션이름...

창선: 리듀서 만드는 게 가장 어려웠던 거 같음. 액션을 했을 때 아무 리턴이 없는데 왜 넣어야하지?

지수: 액션 타입 정하는 게 어려웠음.

강산: 'create'인가 'add'인가... 로그인하는데도 어디까지 로그인해줘야 하는지. 로딩인디케이터를 넣어줘야 하는지 등등.

창선: 리액트 자체에서 짤 때는 각 컴포넌트 안에서 이뤄지니까 흐름이 잡히는데 외부의 동떨어진 세계여서 더 생각이 안남. 필요한 상태가 뭔지가 생각이 안남. 머릿속에 큰 그림을 그려야 잘 되는 거 같음.

지원: 상태가 어떻게 생겨야 편한지 미리 고민하는 게 좋을 거 같음.

강산: 왜 list 가 redux 안에 있어야 하지? 하는 생각.

강산: 역시 자바스크립트를 잘해야 한다. 리팩토링, 캡슐화 등. 어떻게 하는 게 함수를 잘 쓰는 것인지에 대한 고민을 시작하게 됨. 원래는 이런 역할을 하는 함수라고 하고 API 호출부터 다 작성했는데, 그렇게 하는 게 아니구나 생각함. 다른 데서 쓸 수 있어야 하고 등등... 고민을 시작하게 된 계기가 되었음. 셀렉터 개념도 그렇고.

지원: 상태관리라는 걸 이렇게 깊이 공부해본 적이 없었음. 뜯어보면서 알려줘서 이렇게 할 수 있다는 걸 좋음. 셀렉터로 성능을 생각하면서 코딩하는 것 등등도 고려할 수 있겠다는 생각이 들었음. 이 기술이 굳이 필요 없더라도 유명하다는 건 쓰는 이유가 있는 것들. 한번 뜯어보면 배우는 게 많은 것 같음. 유명한 것들은 안쓰더라도 공부를 한번 해보는 게 좋겠다.

창선: 상태관리는 프론트로서 무조건 할 수밖에 없음. 리덕스는 상태를 하나 따로 떼서 얘가 역할과 책임이 다 있으니 이런 디자인 패턴이 어디에서라도 쓰일 수밖에없을거같음. 구분해서 나눠놓고 맞게 해놓는 류의 개발 패턴을 머릿속에 익혀놓으면 쓸 수 있을 것 같다는 생각이 들었음. 그래서 리덕스가 중요하다는 생각이 들었음.

지수: 캐시 개념이 흥미로웠음.

창선: 정규화가 찾는 걸 더 빠르게 찾아준다고 함.

5. Feedback/Future action: 아직 못해본 것은 무엇이고, 앞으로 리덕스로 무엇을 더 해보고 싶으며, 어떻게 상태관리를 해나가고 싶은지

지원: 강의에서 나온 정규화나 셀렉터 쓰는 것 등등을 프로젝트 큰 것에 적용해보고 싶음. saga 에 관심이 있었음. thunk 해보니까 액션에서 비동기도 하고 함수도 반환하는데 action 은 무조건 순수객체여야만 하는데 그 컨셉을 해치는 것이라는 문제. 디버깅에서 사가 쓰는 게 더 쉽다고 함. saga 에서만 따로 비동기를 한다고 되어 있다고 함. saga 를 해보고 싶음.

창선: 정규화 패턴과 셀렉터 패턴을 좀 더 해보고 싶음. 아직 상태를 쌓아나가면서 유지시키는 byId, byFilter 등의 패턴이 이해가 잘 안된다. 그리고 스토어에 저장된 상태를 원하는 형태로 바꿔서 가져오기 위한 셀렉터 API 패턴도 딱히 이해가 잘 되는건 아님.. 전반적으로 액션이 디스패치 되고 리듀서가 실행되는 흐름이 아직 명확히 그려지지 않아서 코드가 어떻게 실행되는지도 사실 정확히 모르겠다.. 그리고 리덕스 스토어에 저장된 상태를 이용하고 변화를 주는 행위 자체는 리액트에서 일어나는데 리액트와 리덕스의 연결고리에 대한 이해가 부족한 것 같다 ㅠ 이외에도 노멀라이저 같이 데이터 구조를 정규화 시켜주는 라이브러리들도 사용하면 더 깔끔하게 데이터 구조나 흐름을 만들 수 있을 것 같아서 이런 것들도 시간이 되면 공부하면 좋을 것 같다.

강산: 쇼핑몰 완성이 목표. 상세 페이지까지.

지수: 쇼핑몰 완성. normalizr 라이브러리 써보고 싶음. 아키텍처를 보고 싶음.

강산: API 중독이 있음. 빨리 성공해보아야 겠다는 생각이 들음. 일단 response 를 받아오면 될 거 같다는 생각이 듦.