2. 웹 요청 처리하기 🔴
a) 비동기 작업 처리 & Promise 🟠
redux-thunk를 사용하여 비동기 작업을 처리하려 한다. axios라는 라이브러리를 이용하여 웹 요청을 할 것이다. axios는 Promise 기반 HTTP Client이다.
Promise는 ES6에서 비동기 처리를 다루기 위해 사용되는 객체이다. 크롬 개발자 도구에서 다음 코드를 실행해 봤다.
1초 뒤에 '숫자 1'이 프린트되었다.
다음으로, 1초에 걸쳐서 숫자를 더해가면서 1, 2, 3, 4를 프린트하는 코드를 작성했다.
비동기적으로 처리해야 할 작업이 많아지면, 코드의 구조가 깊어져서 가독성을 떨어뜨리는 결과로 이어진다. 소위 '콜백 지옥'이라고 불리는 현상이다. 이러한 문제를 해결하는 가장 유효한 방식 중 하나가 바로 'Promise'이다.
코드의 깊이가 일정하다는 점을 확인할 수 있다.
Promise는 비동기 작업의 결과를 나타내는 객체이다.
Promise는 비동기 작업의 결과에 따라 처리할 수 있다. 작업이 성공하면 '.then()' 메서드를 사용하여 이행된 상태의 결과를 처리할 수 있고, 작업이 실패하면 '.catch()' 메서드를 사용하여 거부된 상태의 오류를 처리할 수 있다.
b) axios 사용해보기 🟠
axios 설치
yarn add axiosaxios 적용
위 에러가 발생했다.
axios는 브라우저 환경에서 직접 사용할 수 있는 HTTP Client 라이브러리이다. 그러나 axios는 기본적으로 CommonJS 형식의 모듈 시스템을 사용하기에, 브라우저에서 직접 import 구문을 사용하면 위와 같은 에러가 발생한다고 한다.
axios를 브라우저에서 사용하려면 번들러를 사용하여 모듈 시스템을 변환해야 한다.
갑자기 배추만 주고 나베를 만들어오라고 한다. 공식문서를 읽어보고 다시 하든지 해야겠다.
3. Writing Logic with Thunks(공식문서) 🔴
- 'thunks'가 무엇인지, 그리고 왜 'thunks'를 redux logic을 작성하는 데 사용하는지 배워보자!
- thunk middleware가 어떻게 작동하는지 배워보자!
- 동기, 비동기 logic을 'thunks'에서 작성하는 기술에 대해 배워보자!
- 일반적인 thunk 사용 패턴에 대해 배워보자!
a) Thunk Overview 🟠
What is a "thunk"? 🟡
공식문서에서는, 'thunk'를 '지연되는 작업을 수행하는 코드 조각'으로 정의한다. 현재의 logic을 실행하는 대신, 차후에 작업을 수행하는 데 사용할 수 있는 function body나 code를 작성할 수 있도록 한다.
redux의 관점에서 구체적으로 보면, thunks라는 것은 redux store의 'dispatch', 'getState' 메서드와 상호 작용할 수 있는 내부 논리가 포함된 '함수 작성 패턴'이다.
thunks를 사용하기 위해서는, 'redux-thunk middleware'가 redux store의 구성요소의 일부로 추가되어야 한다.
'Thunks'는 redux 앱에서 비동기 로직을 작성하기 위한 표준적인 방식이다. 그리고 일반적으로 data fetching에 사용된다. 일반적으로 그렇다는 것이고 동기, 비동기 로직을 포함한 다양한 작업에 사용될 수 있다.
Writing Thunks 🟡
thunk 함수는 redux store의 'dispatch method'와 'getState method' 두 가지를 인수로 받는다. thunk 함수는 직접 호출하지 않고, store.dispatch()로 전달하는 방식으로 호출한다.
thunk 함수는 '임의의 로직(동기 또는 비동기)'을 포함할 수 있고, 언제든 dispatch나 getState를 호출할 수 있다.
일반적으로 Redux 코드에서, 액션 객체를 직접 작성하는 대신 액션 생성자를 사용하여 액션 객체를 생성하는 것처럼, 새로운 thunk 함수를 반환하는 thunk 액션 생성자를 사용한다. thunk 함수는 일반적으로 액션 생성자에 전달된 인수를 기억하고 해당 로직에서 사용할 수 있도록 한다.
function 키워드나 화살표 함수로 thunk 함수와 액션 생성자를 작성할 수 있다. 의미에 있어 큰 차이는 없다. fetchTodoById thunk 함수도, 코드와 같이 화살표 함수를 사용하여 작성할 수 있다.
thunk는 다른 redux 액션을 dispatch하는 것과 동일한 방식으로 액션 생성자를 호출하여 dispatch된다.
why Use Thunks? 🟡
Thunk는 UI 계층과 분리된 추가적인 redux 관련 로직을 작성할 수 있게 해준다. 이러한 로직은 비동기 요청이나 무작위 값 생성과 같은 side effects를 포함할 수 있으며, 여러 액션을 dispatch하거나 redux store 상태에 접근해야 하는 로직도 포함할 수 있다.
redux reducer는 side effects를 포함하면 안 되지만, 실제 애플리케이션에서는 side effects가 있는 로직이 필요하다. 컴포넌트 내부에 있을 수도 있지만, UI 계층 외부에 있어야 할 필요도 있다. Thunk로 대표되는 redux middleware는 이러한 side effects를 넣을 수 있는 공간을 제공한다.
클릭 핸들러나 useEffect 훅 내에서 비동기 요청을 수행하고 그 결과를 처리하는 등, 로직이 직접적으로 컴포넌트에 들어가는 것은 일반적이다. 하지만 가능한 한 이러한 로직은 UI 계층 외부로 이동시키는 것이 종종 필요하다. 이는 로직의 테스트 가능성을 향상시키거나, UI 계층을 가능한 얇고 '표현적'으로 유지하거나, 코드의 재사용성과 공유성을 향상시키기 위함일 수 있다.
Thunk는 한 마디로, Redux 스토어와 상호작용해야 하는 모든 코드를 미리 작성할 수 있는 구멍이라고 볼 수 있다. 이로써 해당 로직이 특정한 Redux 스토어 인스턴스에 결합되지 않고 재사용될 수 있게 된다.
Thunk Use Cases? 🟡
회고
무라카미 하루키는, "나는 천재가 아니라서, 재능보다 규칙과 단련을 믿는다"라고 말한 바 있다.
TIL 포스팅이 내일이면 100회에 접어든다. 99번의 포스팅을 하면서 얻은 통찰은, 우리 삶에서 꾸준함은 꽤나 날카롭고 강력한 무기라는 점이다. 그런데 어떤 날은 공부가 너무 잘 돼서 기분이 들떴고, 또 다른 날에는 다 때려치우고 싶을 만큼 "앉아만 있었다"라는 느낌이 강하게 들었다.
뭔가를 꾸준히 하려면 감정 기복이 없어야(=없을 수는 없고 적어야) 하는데, 그러한 상태에 도달하기 위해서는 성공과 실패의 이분법적 사고에서 벗어나야 한다. 할 일에 대한 성공과 실패에 무감각해질 때 비로소 꾸준함에 도달할 수 있다.
'완결의 습관'은 성공과 실패라는 이분법적 사고에 마취제를 놓는다. 내가 계획한 총량의 눈금을, 죽이 되든 밥이 되든 채웠다는 사실에 만족할 줄 알아야 한다. 채우려고 노력하는 것은 디폴트고...
열심히 하려고 하지 말고, 잘 하려고 하지 말고, 꾸준히만 하자. '열심히'와 '잘'은 '한철 장사'에나 유효한 덕목인 것 같다. 내일도 just ㄱㄱ!
