코드숨_코드리뷰 스터디 5주차 회고

date

Jun 4, 2023

slug

codesoom5

author

status

Public

1. Redux에서 비동기 액션 등록하기

1-1) thunk 없이 비동기 액션 함수 등록

별도의 미들웨어 없이 비동기 함수를 실행하기 위해서는 아래와 같은 작업들이 필요하다

fetch를 비동기적으로 하는 함수로 data fetching

해당 데이터값을 dispatch로 넘겨주기

fetch 함수 실행

const INCREMENT_COUNTER = 'INCREMENT_COUNTER';

// ./api.js
// fetch 함수
function async fetchData() {
	const response = await fetch(url)
	const data = await response.json()
	return data
}

// app.js
// fetch를 비동기적으로 하는 함수
function async loadData({dispatch}) {
	const data = await fetchData()
	dispatch(setData(data))
}

useEffect(()=>{
	loadData({dispatch})
},[])

// action.js
export function setData(data){
	return {
		type:SET_DATA,
		payload : {data}
	}
}

//reducer.js
if(action.type === SET_DATA) {
	const {data} = action.payload
	return {
		...state,
		data
	}
}

1-2) What is Redux-thunk

위와 같이 redux의 복잡한 비동기 함수를 불러오고 다시 액션을 호출하는 구조를 한 번에 작업하기 위해 redux-thunk가 나왔다.

즉, dispatch로 함수를 넘기면 이런 작업을 쉽게 할 수 있다.

Action creator가 액션을 반환하는 대신에 함수를 반환합니다. 그래서 특정 액션이 실행되는 것을 지연시키거나 특정한 조건이 충족될 때만 액션이 실행될 수 있도록 할 수 있다.

thunk란? 표현식을 래핑하여 평가를 지연시키는 함수 (지연시키기 때문에 think를 과거형 표현식으로 만듬)

1-3) 미들웨어로 등록하기

Redux-thunk를 활용하려면 우선 미들웨어를 등록해야한다.

import { createStore, r } from 'redux';

import thunk from 'redux-thunk';

import reducer from './reducer';

const store = createStore(reducer, applyMiddleware(thunk));

1-4) thunk를 활용한 비동기 액션 함수 등록

thunk를 활용해서 심플하게 비동기 액션 요청하기 action에 비동기 작업을 추가하고, 해당 함수를 action 함수 호출하듯이 호출하면 된다.

//action.js

export function loadData(){
	return async (dispatch)=>{
		const data = fetchData()
		dispatch(setData(data))
	}
}

//app.js
useEffect(()=>{
	dispatch(loadData())
},[])

2. Redux Test 하기

2-1) reducer test 하기

data가 바뀌었다는 전제하에 reducer로 해당 action 실행시 값이 바뀌어야한다.

2-2) app test 하기

Api fetching mocking 파일만들기

// ../services/__mocks__/api.js

export async function fetchCategories(){
	return []
}

jest.mock('./services/api')

3. 회고

3-1) 테스트 커버리지

테스트 커버리지 100% 달성을 기한내에 하지 못했다.

각 테스트 커버리지가 어떻게 구성되고, 어떻게 해결해야하는지를 아직 명확하게 이해를 하지 못했다.

아래의 글을 읽고 이해를 하긴 했으나 과제 완성을 더디게 하다보니 아직 이해를 못한 부분이 있다.

다만, 테스트커버리지를 100%로 만들기 어렵다는 건 그 만큼 테스트하기 좋은 아키텍쳐가 아니라는 것이고,

그 부분에서 좀 더 명료하게 설계를 하는 것이 중요하다는 것을 알게 되었다.

물론 아래의 글을 읽어보면 테스트커버리지가 100%라고 해서 에러가 아예 없는 것은 아니다.

테스트 커버리지 100% 향해서

도입

https://hyunminh.github.io/test-coverage/

3-2) 밀리지 않기…!!

개인 사정으로 이번 주 일정들이 조금씩 밀렸다.

한 번 밀리기 시작하니까 개념적으로 충분히 따라가고 있는지 자신이 없어졌다.

이번 주도 기업 과제 테스트도 있고, 할 일이 많다.

해야할 것들을 하나씩 차근차근 해보자!