Redux

어떤 일이 있었나.... 유저가 속한 프로젝트들을 보여주기 위해 유저의 정보를 이용해 DB에 유저가 속한 프로젝트들의 정보를 가져와야 했다. DB에서 프로젝트들의 정보를 가져오기 까지 완료했다. 그렇다면 가져온 데이터는 어떻게 보관해야 할까? 라는 의문이 들었다. 가공은 객체 형식으로 된 데이터를 가져왔기에 비교적 쉽게 가공이 된다 치자. 내가 고민한 보관 방법은 Redux의 store에 보관을 해도 될까였다. 데이터를 가져올 방법을 고민하던 중 보게 된 react-query의 useQuery의 설명문을 보다 이런 의견을 보게되었다. 이 의견을 보니.... 흠.... 아무래도 우리가 만들고 있는 서비스가 실시간 수정이 가능도 하고, 다른 유저가 프로젝트에 새로 입장해도 안보여지면 이상할 것 같았다. 그래..

이전에 로그인 API를 구현하고 이제는 컴포넌트들을 생성하여 API와 연결해줘 완성을 했다. 만드는 동안 발생했던 에러들과 내가 새로 알게된 것들과 함께 정리하는 시간을 갖아보려한다. 내가 공부한 로그인 방법의 API를 정리한 글에서 나와있듯이 데이터 입력 > 데이터 검토 > 유효성 검사(토큰확인) > 결과 와 같은 순서로 구성되어있으며, 위의 기능들을 하기 위한 장치들은 API에서 모두 만들어 놨으므로 이제는 이용하는 일만 남았다. 모듈에서는 액션, 액션생성함수, 리듀서, 초기State를 담아주고, 최상위 index에서는 store와 sagaMiddleware, localstorage를 관리해준다. 그리고 컨테이너에서 dispatch로 액션을 전달하여 State에 정보를 전달해준다. 데이터의 흐름은 페..

리덕스의 장점 컴포넌트의 상태 업데이트 관련 로직을 다른 파일로 분리시켜 효율적으로 관리한다. 컴포넌트 끼리 상태 공유시 손쉽게 상태값을 전달하거나 업데이트가 가능하다. 단순히 전역 상태관리만 한다면 Context API로 충분하지만, 프로젝트의 규모가 클 수록 리덕스를 사용해 상태를 더 체계적으로 관리할 수 있다. →→ 코드의 유지보수성을 높이고 작업효율( 편한 개발자 도구 지원, 미들웨어 기능 지원 )을 극대화 한다. 1. 개념 정리 액션 상태에 변화가 필요하면 액션이 발생한다. 객체로 표현되며 다음과 같은 형태를 갖는다. 대부분 이름은 대문자로 작성하며 고유성을 갖아야 한다. { type: 'Toggle_Value' } // 액션 객체는 type 필드를 갖어야 한다. 액션 생성 함수 액션 객체를 만..