상태 관리를 어떤 방법으로 하기로 결정했나요?

[woowapark]

• 결정한 이유는?
  • 기존에 경험한 적 없는 방법이라면, 어느 정도로&어떻게 학습하고 시작했나요?
• 현재까지 경험에서 느끼는 바는? (장점, 단점, 다른 방법과의 비교, 그 외 의견들)
• 그 외 나누고 싶은 이야기, 경험

[yujo11]

그루밍 파노 - Redux, Redux Toolkit

선택배경

• Redux를 전 단계에서 사용했는데 아직 다른 상태관리 툴을 사용하기에는 Redux를 잘 알지 못 해서 선택하게 됐다. Toolkit을 사용하게 된 이유는 페어의 추천과 다양한 편의 기능 제공

---

서니 피터 - Context API

선택 배경

• 전역적으로 상태관리 할게 User Login과 Theme Style 밖에 없다고 판단. 몇 가지 되지 않는 상태를 Redux 등으로 관리할 필요가 없다고 생각.

---

유조 - Redux, Redux Tollkit

선택 배경

• 전역으로 관리해야할 상태가 많았다. (AccessToken, 역 목록, 노선 목록)
• 기존 Redux, Redux Thunk로 전역 상태관리를 하면서 불편한 점들이 있었다.(비동기 로직을 처리하기 위해 Action을 3개 작성하는 등)
• 도구 선택에 대한 고민을 최대한 덜어내고 빠르게 선택하고 싶었다. (Redux에서 공식적으로 Redux Toolkit 사용을 추천

장점

• 1.Redux, Redux Thunk를 사용할 때에 비해 코드량이 굉장히 줄어들었다.
• 2. Action, Reducer를 다른 파일에 작성할 필요가 없어 개발 속도도 훨씬 빨라졌다.
• 3. 공식문서에 정리가 잘 되어있다. + (TS 작성 예시까지 정리가 잘 되어 있다.)
• 4. 러닝커브가 낮다.

단점

• 1. 추상화가 많이 이루어져 있고 Thunk, Immer 등이 내장되어 있어 나중에 Toolkit없이 Redux를 사용할 때 문법에 대한 혼란이 올 수도 있을 거 같다.

[Puterism]

브콜

• 유저나 테마, 스낵바 제외하고는 전역 관리의 필요성을 느끼기 어려웠음.
  • 어차피 서버와 계속 동기화하려면 서버 요청을 보내야 하기 때문
  • 하루: 요청을 더 자주 보내야하는 단점이 있지 않은가?
    • 로그인 한 사람이 어드민이고, 두 세명이 같이 작업했을 때를 직접 실험
      • 동일한 역을 이미 추가했으면, 다른 사람에서는 에러가 잘 뜸
    • 자동으로 내꺼에도 떴으면 좋겠지만, 거기까지는 좀 어렵다고 판단
  • 하루: prop drilling의 우려가 있지 않은가?
    • 아직 depth가 깊지 않아서 괜찮았다.
    • 다만 페이지 컴포넌트에서 상태를 가지고 있기 때문에 비대해지게 된다.
      • 비즈니스 로직을 훅으로 빼서 해소할 수 있을 것으로 기대

하루

• 전역적으로 관리하지 않고도 충분히 가능하다.
• redux-toolkit 사용함
  • slice를 사용하니 코드 양도 줄고 간결하게 Ducks 패턴으로 작성할 수 있었음
  • 진입 장벽이 낮은 것도 장점
  • thunk, devtools, immer 등 이미 적용된 라이브러리가 있어서 별도의 추가 세팅이 필요하지 않아 편함
  • Ducks 패턴이라 어쩔 수 없이 파일의 부피가 커지는 감이 있음

브랜

• 로컬 상태와 서버 상태가 다를 수 있기 때문에 확실히 할 필요는 있다.
• 역이나 노선 등 조회를 할 때는 매번 요청을 보낼 필요는 없을 것 같다.
  • 어드민이 동시에 여러 명 접속되어 있을 경우는 커버하기 어려움
  • 요청을 한 번 보낼 때마다 얼마나 비용을 소모하는가?
    • SWR의 수요 : 캐싱의 필요성

체프

• UX를 해치지 않는 선에서는 요청을 보내도 된다고 생각한다. 데이터 변화가 있으면 새롭게 그냥 업데이트만 된다. 크게 스피너가 돌 필요없이 옆에서 작게 돌게만 한다. 최종적으로 데이터가 변하는 구간은 서버이기 때문에 최신 데이터가 아니더라도 서버에서 막아줄 것이다.
• redux-toolkit 사용함
  • 이전 미션에서 redux, redux-thunk를 사용하고, redux-toolkit으로 전환했을 때, 크게 효용성을 느끼지 못했다.
  • 이번에는 처음부터 toolkit을 사용하면서 장단점을 고민해보려고 함

주모

• 타입스크립트와 redux-toolkit 사용함
• 타입도 지정하고, Slice라는 새로운 개념을 공부해야해서 조금 부담은 있으나, 진입장벽은 높지 않아 적용할 수 있었다.
• 추상화 수준이 높기 때문에 Redux를 먼저 접하고 사용하는 것이 정말 중요할 듯 → 처음부터 툴킷 먼저 쓰지 않기

[Vallista]

처음부터 툴킷은 비추임미다

[2SOOY]

곤이

리덕스 툴킷 + 사가

• createAction + createReducer ⇒ createSlice ⇒ 한 번에 관리
• 불변성을 신경쓰지 않고 코딩해서 편하게 상태 변경이 가능함
• action type이 "소문자"
  • typescript를 사용하면서 타입을 명시해야할 상황이 생기는 데 이때 소문자로 넘겨주는 것이 조금 낯설다
• saga를 사용하면서 큰 이점을 느끼지 못하고 있음
  • 마지막 요청만 처리할 수 있음 - 굉장한 장점
  • generator에 대한 이해 + ts 와 궁합이 좋지 않다. ⇒ 타입 맞추기 어려움
  • 사용한 이유?
    • 학습의 차원
    • 인치의 의견 → success / fail / request 묶음을 편하게 처리할 수 있을 것이라고 생각
• 액세스 토큰 관리 - 로컬 스토리지
• redux로 현재 로그인된 사람의 이메일 관리

지그

리덕스 툴킷

• Context API ?를 사용하지 않은 이유
  • 리덕스 데브툴즈와 같은 부가적인 기능을 활용할 수 있음
• 모든 데이터를 전역으로 관리하고자 했다가, 우선은 유저 정보부터 전역으로 관리하기로 결정
• 지하철 역, 노선 정보와 같은 경우는 local로 관리해도 충분할 것이라고 생각

동동

리덕스 툴킷

• 우선 하나의 상태관리 툴의 이해도를 높이고자 조금이라도 익숙한 리덕스를 사용
• 리덕스를 통해 전역관리를 하면 앱 어디에서든 접근이 가능함
• 다른 측면에서는 xstate 와 같은 상태관리 툴을 사용하고 싶음 ⇒ "근본"의 느낌이 듦
  • 다만 문서 불친절함
  • 튜링 머신에 대한 이해

도비

리덕스 툴킷

• 로그인 정보 - 전역으로 관리해야 함
  • 역관리/노선관리 페이지 기능이 로그인 되지 않다면 허용시키지 말아야하기 때문
• 전역 관리가 필요없는 상태들은 local로 관리

콜린

리덕스 툴킷

• 로그인과 관련한 유저 정보 같은 경우는 전역으로 상태 관리 -> 추후 localstorage에 저장할 수 있도록
• 액션/액션 생성 함수/리듀서 등을 편리하게 작성할 수 있다는 것에 큰 이점을 느꼈음
• 전역으로 관리해야 할 상태 vs 로컬로 관리해야 할 상태에 대한 고민이 필요함

[woowapark]

혹-시나 리덕스가 '이해가 잘 되지 않아서' 툴킷을 써보는 걸 고려한다면 이미 여러 크루들이 적어준 것처럼 주의가 필요하겠네요..!
JS 헷갈리다가 React 썼을 때 React에서 제공해주는 건지 JS에서 원래 되는 건지 구분하기 어려운 것과 같은 상황이
대상만 바뀌고 반복될 수도...! 😖

[swon3210]

[ 카일 ]

크리스에게 질문. 성크 로직은 컴포넌트 안에 두는 것인가?

• 리덕스로 뺀다. 기존의 액션 생성함수의 위치에 비동기 로직들을 따로 분리 시킨다.

[ 인치 ]

모든 비동기 통신을 사가를 통해서 하지 않음. 리덕스에 따로 저장할 필요가 없는 데이터는 리덕스에 넣지 않고 해당 페이지에서 그냥 fetch 해서 사용함. 그것 외에는 크리스와 비슷한

• 리덕스에서 필요하지 않다고 생각되는 시점에서는 리덕스로 따로 빼지 않음.

[ 티케 ]

전역 상태들은 모두 리덕스에 넣는다. 그 중에서 특히 액세스 토큰과 같은 상태는 리덕스에 넣는다. 인치가 항상 accessToken 이 필요한게 아니라고 말한건 조금 의문이다.

[ 썬 ]

여러가지를 경험해보는 데 중점을 둠. 리덕스 툴킷 선택. 역, 노선 목록과 같은 여러 페이지에서 필요한 데이터는 전역 상태로 사용. 나머지는 그냥 전부 지역 상태. 서비스를 이용할 때 새로고침을 했을 때 날아가지 않아야 하는 데이터는 로컬 스토리지에 저장

• fetch 자체에 필요한 데이터를 로컬 스토리지에 저장하는 것

인치 질문 : accessToken 은? <- 그냥 버린다.

[ 크리스 ]

상태를 총 가지로 분류

• 1. 거의 모든 페이지에 걸쳐서 필요한 레이아웃에 필요한 상태(ex: 스낵바, confirm 모달 등)
• 2. 특정 페이지나 컴포넌트에서만 필요한 레이아웃에 필요한 상태(ex: ColorPicker 등)
• 3. 어플리케이션의 비즈니스 로직에 필요한 상태 (ex: 상품 배열, 장바구니 데이터 등)

이 중 1, 3 을 리덕스에서 전역으로 관리

3은 대체로 비동기적으로 업데이트 되는 경우가 많아 thunk 를 통해 액션을 처리

프론트엔드 개발은 어떤 일에 어느 정도의 노력과 시간이 필요한지를 쉽게 알 수 있지만 백엔드 개발 영역에서는 이를 예측하기가 어려워서 데드라인을 논의할 때 상대 개발자의 말만을 믿을 수밖에 없다.