[ 엘리스 SW 엔지니어 트랙 ] 58일차

📍 58일 차 1.13. 목. 실시간 강의

오늘은 기존에 vanilla JS를 연동하여 redux로 상태관리를 진행한 것에 이어서 react로 redux, react-redux 라이브러리를 사용하여 상태 관리하는 법을 배웠다. 실습을 위주로 강의를 진행했기 때문에 글로 남길만한 내용이 별로 없다. 그리고 마지막에는 test 코드 작성하는 법을 배웠는데, 이 과정은 내일이나 내일모레 이론강의 수강 이후에 작성하겠다.

---

❏ 리덕스의 3가지 규칙

1. 단일 스토어: 나의 애플리케이션 안에는 하나의 스토어가 들어가있다. 여러 개의 스토어를 사용할 수 있지만 상태 관리가 복잡해질 수 있으므로 권장하지 않는다.
2. 읽기 전용 상태: 리덕스 상태는 읽기 전용이다. 리덕스의 상태를 업데이트할때는 기존의 객체는 건드리지 않고 새로운 객체를 생성해주어야 한다. 불변성을 유지하는 이유는 내부적으로 데이터가 변경되는 것을 감지하기 위해 얕은 비교(shallow copy) 검사를 하기 때문이다. 객체의 변화를 감지할 때 객체의 깊숙한 안쪽까지 비교하는것이아니라 겉핥기식으로 비교하여 좋은 성능을 유지할 수 있는 것이다.
3. 순수 함수: 변화를 일으키는 리듀서는 순수한 함수여야한다.

1. 리듀서는 이전 상태와 액션 객체를 파라미터로 받는다.
2. 파라미터 외의 값에 의존하면 안된다.
3. 이전 상태는 절대 건드리지 않고, 변화를 준 새로운 상태 객체를 만들어 반환한다.
4. 똑같은 파라미터로 호출된 리듀서 함수는 언제나 똑같은 결과 값을 반환해야 한다.
5. 리듀서 함수 내에서 랜덤값을 만들거나 Date 함수를 사용하여 현재 시간을 가져오거나, 네트워크 요청을 한다면 파라미터가 같아도 다른 결과를 만들어 낼 수 있기때문에 사용하면 안된다. 
이러한 작업은 리듀서 함수 바깥에서 처리하자. 액션을 만들때 처리해도되고, 리덕스 미들웨어에서도 처리해도 된다.
6. 네트워크 요청과 같은 비동기 작업은 미들웨어를 통해 관리한다.

❏ React-redux

1. 보통 프레젠테이 셔널 컴포넌트(props 를 받아와서 화면에 UI 를 그려주기만 하는 컴포넌트)와 컨테이너 컴포넌트(리덕스와 연동되어있는 컴포넌트, 리덕스로부터 상태를 받아오거나, 리덕스 스토어에 액션을 디스 패치하기도 한다.)를 분리한다. 필수 사항은 아님
2. connect vs useSelector, useDispatch 의 차이: connect 함수를 사용하여 컨테이너 컴포넌트를 만들 경우, 해당 컨테이너 컴포넌트의 부모 컴포넌트가 리렌더링 될 때 해당 컨테이너 컴포넌트의 props 가 바뀌지 않았다면 리 렌더링이 자동으로 방지되어 성능이 최적화됩니다. 반면, useSelector를 사용하여 리덕스의 상태를 조회했을 때는 이 최적화 작업이 자동으로 이루어지지 않으므로, 성능 최적화를 위해서는 React.memo 를 컨테이너 컴포넌트에 사용해 주어야 합니다

const TodosContainer = () => {(...)}

export default React.memo(TodosContainer);

3. combineReducers: reducer가 여러 개 있다면, 하나로 합쳐주는 메소드
4. reducer를 구현할 때 reducer는 순수 함수여야 한다. global variable의 값을 수정하면 안 된다.

728x90

❏ Test

1. TDD: 레이아웃을 짜고 테스트 코드를 작성한 다음에 로직을 구현하는 경우가 많다. 테스트 주도만을 위하다 보면 생산성이 저하될 수도 있다.
2. unit test: 하나의 모듈을 기준으로 독립적으로 동작하는 가장 작은 단위의 테스트 → react 에서 component 단위로 테스트할 수도 있다. 기능마다 대응하는 테스트 코드 작성
3. intergration test: 한 번에 모아서 테스트