2021 09 04

이누의 벨로그·2021년 9월 4일
0

TIL

목록 보기
1/3
post-custom-banner
  • 상태관리 및 swr 간략한 사용법 익히기

로그인, 피드 호출(getFeeds)(/GET) 시에만 전역저장소에 action dispatch (여기선 swr)

그 외 post, put delete 는 상태 dispatch 없이 api만 호출 하고 다시 GET요청해서 다시 dispatch하는 형식

swr은

const {data, error, isValidating, mutate(data? shouldRevalidate?) } = useSWR(url, fetcher);

로 선언
mutate은 다시 api 호출할 시점에 선언할 수 있는 data의 갱신 함수로, 주로 post요청 후에 데이터 갱신을 위해 사용한다. e.g) 로그인 요청 후에 바로 로그인 정보를 api에 요청하여 data에 저장

사용법은

mutate('/api/user', newUser, false); //newUser은 컴포넌트의 state, 
mutate('/api/user', updateUser(newUser), false) // updateUser은 Promise로 이처럼 비동기요청으로도 쓸 수 있음

공식 문서가 매우 잘되있으니 읽어보면 좋다.
https://swr.vercel.app/ko/docs/getting-started

!data면 로딩중

참고로 swr 사용법은 react-query 사용법과 같다.

리덕스 미들웨어 쓰면 비동기 처리도 되고 여러모로 좋다는데 useContext나 swr쓰면 참 간단한데 아직까지 리덕스 쓸만한 규모의 프로젝트를 안해봐서 체감을 못하는 것 같기도 하다.

백엔드랑 프론트엔드를 같은 컴퓨터에서 돌리려면 콘솔창 두개를 각각 띄워서 npm run dev를 둘 다 돌려야 함.
서로 다른 포트에서 CORS에러 해결하는 방법은 프론트는

webpack.config.js

devserver:
{proxy :{
	url:{
        changeOrigin:true, 
        target:${백엔드url}
        }}}

백엔드에선 express에선 미들웨어로

app.use(CORS({
     origin: true,
     credentials: true,
   }))

를 사용하는 방법.
개인적으로는 프록시가 편했다.

이유는 도메인이 같아야 쿠키가 정상적으로 전달되는데 로그인을 쿠키로 처리할 경우 프록시를 쓰지 않으면 CORS를 백엔드에서 해결하더라도 쿠키가 전달되지 않는다. 실제로 쿠키를 사용할 경우 withCredentials 옵션 없이는 POST 로그인 요청에 대한 응답은 오지만 swr이나 react-query로 유저 정보를 axios.get으로 호출하면 유저정보가 비어있다.

프록시를 사용하면 도메인이 같아져서 쿠키 생성 및 프론트에서 백엔드로 데이터도 정상적으로 전달 된다. 프록시를 사용하지 않고 백엔드의 CORS 옵션을 사용하면 비동기 요청에 get은 2번째 매개변수, post는 3번째 매개변수로 withCredentials:true를 넣어줘야 한다.

물론 이건 같은 컴퓨터에서 서버와 프론트를 같이 개발할 경우의 이야기이고 배포 후에는 프록시는 쓰지 않기 때문에 얄짤 없이 withCredentials 및 백엔드의 CORS를 사용해야 한다.

우분투

  • 우분투에 jetbrains ide 다 옮겼다. 윈도우에서 내던 에러 다 없어짐

  • 파이썬 버전도 정상 인식함

  • cmakelist라는 CLion에서 쓰는 c/c++ 용 처음보는 모듈이 있다... 이걸 알아야하는데...후...

  • mysql도 정상작동.

  • 돈주고 산 윈도우 컴 wsl GUI도 빵빵하게 지원해주게 업뎃 됐으면

profile
inudevlog.com으로 이전해용
post-custom-banner

0개의 댓글