# Saga

devty

서론 Transaction 이란? Transaction은 일련의 작업 단위를 의미한다. 데이터베이스 관리 시스템(DBMS)에서 상태를 변환시키는 하나의 논리적 기능을 수행하기 위한 작업의 단위 또는 한꺼번에 수행되어야할 일련의 연산들을 의미한다. Transaction 특징은? 원자성(Atomicity) 트랜잭션이 데이터베이스에 모두 반영되던지, 아니면 전혀 반영 되지 않아야 한다. 트랜잭션 내의 모든 명령은 반드시 완벽히 수행되어야 하며, 모두가 완벽히 수행되지 않고 어느 하나라도 오류가 발생하면 트랜잭션 전부가 취소되어야 한다. 일관성(Consistency) 트랜잭션의 작업 처리 결과가 항상 일관성이 있어야 한다. 트랜잭션 전과 후에 데이터의 무결성 규칙이 유지되어야 한다. 고립성(Isolation) 각 트랜잭션이 독립적으로 실행되어야 함을 나타냅니다.

darcyu83

/* all([함수,함수들]) : 함수들을 동시에 실행한다. fork(함수) : 비동기 함수를 실행한다.(non-blocking) call(api 함수) : 동기 함수 호출 (blocking) (asynchronous -> synchronous) take : 1회성 동작 1-1 while take 문 : 동기적으로 동작 (blocking) while(true){ yield take("ACTION_", loginFetch) } 1-2-1 takeEvery : 비동기적으로 동작(non-blocking) yield takeEvery("ACTION_", loginFetc) 1-2-2 takeLeading : 첫 요청만 실행 1-3-1 throttle (scrolling) : 일정시간 내에 재 호출되지 않음 yield throttle("ACTION_", loginFetch, 2000) 1-3-2 debounce( te

taek_jini

front/pages/index.js front/sagas/post.js 쿼리스트링을 통해 데이터를 보낸다. >현재 스크롤을 내리면 같은 게시글을 계속 불러오는 버그가 있습니다. 여러 방법 중 lastId 방식으로 이 문제를 해결하는데, 먼저 mainPosts의 마지막(첫번째) 게시글의 id를 찾아서 이걸 lastId로 데이터를 전달해줍니다. 하지만, get방식은 데이터를 보낼 수 없기 때문에 넣으려면 쿼리스트링**(`/주소?key=${valu

taek_jini

이미지 업로드를 위한 multer front/component/PostFrom.js back/app.js encType="multipart/form-data" 이미지를 올리게되면 multipart 라는 form-data로 데이터가 전송이 되게 됩니다. 하지만, 지금의 백엔드에서는 json 형식과 이미지나 비디오 같은 데이터를 받을 수 없는 일반적인 Form 데이터만 받을 수 있기 때문에 multer를 설치합니다. > **multe

taek_jini

게시글 좋아요 구현 front/component/post.js front/reducer/post.js front/saga/post.js ![](https://velog.velcdn.com/images/taek_jini/post/11dc15af-91ac-4052-

taek_jini

게시글 불러오기 back/routes/posts.js 게시글을 불러오기 위해 posts.js를 만들어 줍니다. findAll로 여러개의 항목을 DB에서 찾아올 수 있습니다. 시퀄라이즈의 find 메소드는 SELECT 쿼리문으로 이해하면 됩니다. findOne : 특정된 하나의 레코드만 찾는다 findAll: 모든 레코드를 찾는다 보통의 SNS를 보면 1~20까지의 게시글이 있다면 최신게시글이 최상단에 위치하는것을 볼 수 있습니다. order를 통해 'DESC' 내림차순으로 설정을 하면 20~1로 최신 게시글이 제일 위에 나타나게 할 수 있습니다. 또한, 모든 게시글을 불러오기에는 컴퓨터 용량의 무리가 될 수

taek_jini

게시글, 댓글 완성하기 front/routes/post.js (게시글 작성 라우터) * 데이터가 어떻게 이동하는지 잘봐야 됩니다. 그래야 코드를 짤 때 수월하게 할 수 있습니다. * > 1. PostForm에서 Submit → dispatch({ addPost(text) }) reducers/addPost의 data로 text 데이터를 받음 sagas/addPost로 가서 action.data로 addPostAPI의 { content: data } axios가 백엔드로 요청함 routes/post.js에서 req.body.content로 데이터를 받고 처리해서 프론트로 전달 ![](https://velog.velcdn.com/images/taek

taek_jini

Redux-middleware 리덕스에 없던 기능들을 추가해주는 역할이다 기존의 컴포넌트 안에서 했던 비동기 처리를 리덕스에서 하도록 해서 사이드 이펙트를 최소화한다. 풀어서 얘기하자면 액션을 디스패치했을 때 리듀서에서 이를 처리하기에 앞서 사전에 지정된 작업을 실행할 수 있게 해준다. > 액션과 리듀서사이의 중간자 역할이다. 그 중 redux-thunk 와 redux-saga를 간단히 설명해보려 한다. redux-Thunk 리덕스가 비동기 작업을 처리할 때 가장 많이 사용하는 미들웨어로 액션 객체가 아닌 함수를 디스패치할 수 있다. 함수를 디스패치할 때는, 해당 함수에서 dispatch와 getState를 파라미터로 받아와야하고, 이 함수를 만들어주는 함수를 thunk라고 부른다. 따라서 리덕스 스토어의 상태에 접근하거나 또 다른 액션을 디스패치하는 것이 가능하다. thunk 미들웨어의 문제점은 action에서 너무 많은 일을 한다는 점이

0715yk

Redux-saga vs RTK Middleware RTK middleware란? RTK의 디폴트 비동기 처리 메서드로 들어가있는 thunk의 한계점 > Despite its simplicity, thunks have limitations. One of the most cited limitations is the inability to run code in response to dispatched actions or state updates. Doing so requires writing custom middleware or using more powerful middleware libraries like Redux-Saga. Thunks are also relatively diffi

0715yk

Redux Thunk(+ RTK) vs Redux-Saga : 흔히 redux의 비동기 처리 로직 혹은 사이드 이펙트를 처리하기 위한 용도로 redux-thunk나 redux-saga를 많이 사용한다. 이번 포스팅에서는 앞서 말한 redux와 연관되는 라이브러리가 필요한 이유부터 시작해서 각 라이브러리의 장단점을 가지고 서로를 비교하는 시간을 가져보도록 하겠다. 추가로 redux-thunk에서 나아가 RTK에서 제공하는 새로운 middleware(미들웨어)에 대해서도 알아보고자 한다. Redux 미들웨어 왜 필요할까? > By itself, a Redux store doesn't know anything about async logic. It only knows how to synchronously

jrl103

오늘은 매니저님께서 여기저기 돌아다니시면서 '리덕스의 흐름'에 대해 질문을 던지시는 것 같아서 미리 대비할 겸 정리하고자 한다.. 대충은 알고 있는데 이를 누군가에게 설명할 정도로 확실하고 빠삭하게 인지하고 있지는 않으니 이번 기회에 복습한다고 생각해야겠다. > # Redux 의 핵심 요소 - Action : State가 변하는것. “무엇이 일어날지” - Reducer : 변화를 일으키는, 즉 데이터(state)를 수정하는 함수. action을 통해 어떠한 행동을 정의했다면, 그 결과 어플리케이션의 상태가 어떻게 바뀌는지는 특정하게 되는 함수이다. - Store : action과 action에 따라 상태를 수정하는 reducer를 저장하는 어플리케이션에 있는 단 하나의 객체. store 는 state 를 수시로 확인해 View 한테 변경된 사항을 알려주는 역할을 한다. - Dispatch : **store

0715yk

리덕스(Redux)를 왜 쓰고 있을까? : 본래 React를 쓰면서 'state 끌어올리기'에 부담을 느끼거나, 불필요한 props drilling 등이 이슈가 되면서 전역적인 state 관리법이 필요해졌고, 그에 대한 해답(?)으로 나온 것이 Redux라고 할 수 있다(React + Flux 패턴). 하지만 요즘은 전역적인 state 관리를 꼭 redux로만 할 수 있는 것이 아니다. context와 useContext 등의 조합 혹은 recoil, zustand, jotai 등의 신흥 state 관리 라이브러리 등이 이미 많고, 충분히 효용성을 입증한 상태이다. 이런 상황에 우리는 Redux를 왜 계속 쓰고 있을까? 리덕스(Redux)의 단점 : 왜 쓰고 있는지에 관련한 장점을 살펴보기 전에 리덕스의 단점에 대해서 먼저 정리해보면, 리덕스 스토어 환경 설정이 복잡하다. 일례로 extension도 default로 세팅되는 것이 아니라 직접 해줘야한다. 리덕

leyuri

이 글은 인프런 제로초님의 '[리뉴얼] React로 NodeBird SNS 만들기' 를 바탕으로 정리한 내용입니다. saga 설치하고 generator 이해하기 thunk 삭제 saga 설치 saga 관련 코드를 추가한 후에 sagas 폴더를 만들어준다. 제너레이터(generator) 란? generator 도 함수의 일종이다. generator 에는 yield라는 개념이 나온다. .next()를 붙여야 그 아래 것들이 실행된다. 중단점이 있는 함수이다. 원래 js는 함수 위

darcyu83

Saga 적용 후 dispatch로 getMovies action creator를 전달하였다. 무한 로딩 로딩 로딩 ... 멈춤 왜? 이유는 1줄의 코드가 ... redux thunk와 헷갈려서 ... 원인을 찾앗다... 내시간... 오류 코드 일단 결론 먼저 2번째 줄 yield put(getMoviesAct()); 이 오류를 유발햇다. 기본적으로 action은 3가지 타입으로 구성 호출 / 성공 or 실패 내가 이해한 바로는 saga가 동작하는 순서는 moviesSaga takeLatest() 에서 처음 호출 액션을 실행 그리고는 getMoviesSaga에서 api 함수를 호출해서 결과 성공 / 실패를 나눠서 다시 dispatch한다. 아래는 redux thunk 코드 햇갈린... thunk는 액션 3가지 타입을 한개의 함수안에서 dispatch 한다. 유의해야할거 같다. 다르다 . 묘하게 헷갈린다.

darcyu83

리덕스 사가 구현 중 마주친 yield call 타입 에러가 나왔다. 'yield' expression implicitly results in an 'any' type because its containing generator lacks a return-type annotation. call()에 사용할 api 메소드 타입도 모두 설정한 상태인데 ....왜? API fetch method sagas.ts 검색을 해보았다. 링크텍스트 stackOverflow 답변을 간단히 요약하자면 **yield 왼쪽에 변수값의 타입은 항상 any yield 는 모든값을 대응해야 하므로 타입을 반환하지 않음. yield 로 산출되는 값의 타입은 사용자가 정의해야함. ** 고로 다음과 같이 타입을

mong-head

Error https://github.com/mong-head/error/blob/master/images/sagainfiniteloop_problem.PNG?raw=true 문제 상황 : mount하는 시점에 dispatch실행 mount, action은 한번씩만 불렸지만, reducer과 saga는 여러번 호출됨 관련 코드 Component (Layout.js) Action Types (types.js) Action (contactsAction.js) Saga (contactsSag

mong-head

Error > Unhandled Rejection (Error): When called with an action of type "CONTACTS_SET", the slice reducer for key "contacts" returned undefined. To ignore an action, you must explicitly return the previous state. If you want this reducer to hold no value, you can return null instead of undefined. reducer 규칙 state 값으로 null, undefined 넘겨줄 수 없다. 이전 state을 넘기거나 action에서 받아온 payload등을 넘겨야 함 수정 error good 참고 [reducer 규칙](https://velog.io/@mokyoungg/Redux-Reducer-%EC

sklsh917

.png) 프론트엔드 개발을 React로 하다보면 다양한 이유로 Redux를 만나게 되고 활용하게 됩니다. 그리고 Redux를 접해서 사용하다보면 자연스레 Redux Thunk와 Redux Saga 역시 접하게 됩니다. 이 두 리덕스 미들웨어들은 프로젝트에서 비동기처리를 담당하는 역할을 하는 걸로 알려져 있습니다. 비슷하게 비동기 로직을 처리하는 이 도구들은 어떤 차이점이 있길래 서로 다른 이름으로, 다르게 쓰이고 있는 것일까요? 이번 포스팅에서는 두 가지 미들웨어의 간단한 사용법과 어떤 상황에서 어떤 미들웨어를 사용하는 것이 조금 더 나을지에 대해 소개해드리도록 하겠습니다. 1. Redux의 미들웨어 우선 이 두 툴들의 이름이 미들웨어라는 것을

ysg81

- redux react-redux에서 로그인과 같은 비동기 작업을 해야 할 때는 위 흐름과 같이 진행됐어야 했다. 하지만 redux-thunk라는 미들웨어를 통해 비동기 작업을 조금 더 편리하게 관리할 수 있다. - redux-thunk ./redux-action.js 파일에서 thunk 액션을 생성해 준다 이후 해당 액션을 사용하고자 하는 곳에 불러온 뒤, 위 코드와 같이 사용하면 redux에서 비동기 액션을 사용함과 실제 액션을 사용하는 곳에는 훨씬 간결하게 코드를 작성할 수 있는 것을 볼 수 있다. > 참고 - redux-thunk에서 router 사용하기 : connected-react-router history.js 파일을 생성한다. 파일을 따로 생성하는 이유는 여러 곳에서 history파일을 불러와야 하기 때문이다. store에 import 해준 뒤, middleware로 적용한다. 또한 routerMiddlew

secho

Redux > 직접 작성한 예제를 기반으로 작성 > > 코드와 같이 보시면 더욱 도움될 것 같습니다 0. flow > 이전 글 에서 크게 달라지는 것이 없다. > > Action, Reducer은 완전하게 동일하다. > > 달라지는 점은, Context API에선 전역 데이터에 접근하기 위해 Provider에 등록했고 Reducer를 호출하기 위한 Context도 생성해주었다면 Redux에선 useDispatch 를 통해 reducer에 action을 전달해줄 수 있다. > > 또한 useSelector 를 사용해 useContext 를 사용하지 않고 바로 전역 데이터를 가져올 수 있다. > > Flow는 다음과 같다. > > 1. S