[TIL] 로그인 시 전역상태관리의 필요성

lezsuuu·2022년 9월 5일
0

TIL

목록 보기
30/42

(이전글) RefreshToken 도입 여부

우선 왜 상태에 aceess token을 저장 하는지 생각해 봐야 합니다. aceess token 가 로컬스토리지 등에 저장 된 것은 반응 (reative) 가 아니라 컴포넌트가 바뀐 것을 MVVM 패턴에 의해 알 수가 없습니다. 저장을 했는지 안했는지 또는 바뀌었는지 MVVM 패턴으로 알려면 (reative) 상태에 저장 되어 있어야 되는데 그것이 “전역 상태" 입니다. 상태가 아니라면 값이 바뀌어도 컴포넌트가 재 랜더링 되지 않습니다. 이를 깊게 알기 위하여 MVVM 패턴에 대하여 충분히 알 필요가 있습니다. “React 는 MVVM 패턴 구현체” 입니다. 물론 axios interceptors 에서 acess token 을 가져 와서 쓸때는 반응 (reative) 과 무관해 보이 겠지만 로그인 여부에 따라 컴포넌트가 다르게 랜더링 되는 것을 MVVM 패턴 에서 구현 하려면 “상태" 이여야 겠습니다.

그럼 왜 전역이며 컴포넌트 내부 상태가 아닌 이유는 모든 페이지가 유저 정보 (aceess token 포함)을 공유 하기 때문 입니다. 그런데 왜 리덕스 패턴이냐? 단방향 데이터 흐름으로 설계를 하면 복잡한 로직도 쉽게 구현 할 수 있기 때문입니다 (대부분 전역 상태가 결국 복잡한 로직을 요구하게 되기때문에) 다만 요즘은 atomic 한 상태가 복잡한 로직을 더 잘 해결 한다고 보는 것이 유행 입니다.

리액트에서 로그인 상태를 꼭! 필수로! 전역관리해야 하는가? 에 대한 의문이 있었다. 여기저기 검색해보고 멘토님께 문의도 한 결과 전역상태관리가 필수는 아니나 로그인 상태에 따른 컴포넌트 관리를 위해 전역상태관리를 하는 것이 좋다고 이해했다.

다만 프로젝트의 성격? 기획?에 따라 필요하지 않을 것도 같고... 지금 내가 하는 프로젝트에서는 하지 않아도 된다고 생각했지만

1) 지금까지 안 해봤으니까 공부를 위해서 해보기
2) 추후 프로젝트의 확장성을 고려해 미리 준비하기

특히 1번 목적을 위해 redux toolkit을 이용해 로그인 로직을 구현할 예정!

profile
돌고 돌아 벨로그

0개의 댓글