검색결과 데이터처리
props.refetchBoardsCount({ search: data });
검색한 결과의 총 갯수
1.rest와 graphql의 차이점
가. props의 실체
함수형 컴포넌트는 함수와 동일하다
즉
import Presenter from '.../'
과
{Presenter({count : 123})}
은 동일하다
즉 함수형 컴포넌트는 함수와 동일하기 때문에 그냥 실행하면 된다.
함수실행문에서 Presenter({count:123})의 {count:123}은 Arguments이다
따라서 props는 parameter임
나. el의 실체
kkk.map((el, index) => (
~~~~~
))
((el, index) => (
~~~~~
))은 함수이고 el, index는 parameter이고
kkk([],2)
에서 [], 2는 argument이다
다. prev의 실체
setCount( prev => prev + 1)
prev도 parameter다
라. graphql-variables 실체
export const FETCH_BOARDS = gql`
query fetchBoards($search: String, $page: Int) {
fetchBoards(search: $search, page: $page) {
_id
writer
title
contents
createdAt
}
}
`;
fetchBoards({
variables: {
search: mysearch
}
})
export const FETCH_BOARDS = gql`
query fetchBoards($asdf: String, $page: Int) {
fetchBoards(search: $asdf, page: $page) {
_id
writer
title
contents
createdAt
}
}
`;
fetchBoards({
variables: {
asdf: mysearch
}
})$로 붙은건 그냥 변수임
export const CREATE_BOARD = gql`
mutation createBoard($adsf: String) {
//createBoard는 묶음이름이라 아무이름을 써도 상관이 없다
createBoard(writer:$asdf){
_id
}
createProduct(writer:$asdf){
_id
}
}
`로 묶음배송이 가능함(언더페칭이라고 함)
한번의 요청으로 여러개의 fetch를 가져올 수 있음
restapi는 여러개의 fetch를 가져올라면 한개한개 전부 다 가져와야됨
오버페칭
restapi는 원하는거만 가져올 수 없어서 다 받아와야 하는데 그걸 해결한게 graphql
2. 정규표현식
정규표현식을 작성하기 위해서 양 옆에 /를 달아주어야 한다
/조건/.test("입력값")
/apple/.test("apple")
모든 문자 또는 숫자를 찾으려면
역슬래쉬를 붙혀주면 된
시작과 끝을 명확히 설정하지 않으면 입력값이 조건값에 포함만 되있어도 true를 반환함
시작과 끝을 명확히 설정하는 방법
^시작
$ 끝
하나의 문자 또는 숫자 이상
^역슬래쉬w+
없거나 한개일 경우
^역슬래쉬w?
없거나 한개이거나 여러개일 경우
^역슬래쉬w*
.은 모든것을 의미함
하나의 숫자 이상
역슬래쉬d+
자리수 정하기
역슬래쉬d{자리수}
자리수 또는 자리수
역슬래쉬d{자리수, 자리수}
문자만 의미
[a-zA-z]
공백
역슬래쉬s
3. global state
state끌올 했는데 또 올려야 하는 경우가 생김
끌올 끌올 해서 계속 props로 내려줌
이를 props drilling이라고 함
이게 매우 보기가 안좋기 때문에 공통의 컴포넌트가 있으면 좋겠다라는 생각에서 나온 것이 global state
props drilling을 하지 않고 바로 다이렉트로 꽂아버리기 -> redux
매우 복잡함 redux는 이를 개선한 것이 mobX, swr
state란 state는 모두 redux에 담아놨다가 최근에는
api로 받아오는 데이터 저장용 global state
// rest api = react query라이브러리, graphql = apollo-client 라이브러리
일반적인 global state
// rest api = context- api->recoil, graphql = context-api->recoil
fetchPolicy 패치정책
useQuery로 불러오면 cache state 에 저장되고 이후에 const { data } = useQuery에 data로 들어온다
즉 데이터가 불러오기전 undefined -> fetchBoard로 불러와지고 바뀌면 컴포넌트가 리렌더가 된다
왜 api와 일반 global state를 컴포넌트를 나눴을까?
패치정책
fetchPolicy => cache-first
다른 곳에서 동일한 api요청이 들어오면 굳이 백엔드에 다시 요청하지 않고 cache state에서 동일한 api요청 찾은 후 불러오는 것이 속도가 더 빠르다
이후 동일한 api요청이 없으면 백엔드에 들어가서 찾아옴
recoil-state
cache-state와 동일하지만 cache는 api로 받아오는 것이고 recoil은 api로 받아오지 않음
설치 후 컴포넌트에 동일한 이름으로 useRecoilState로 만들고 둘 사이에 공통점인 .atom을 만든다
오늘의 목표
1. rest와 graphql 차이
under-fetching. over fetching
2. 글로벌 스테이트
recoil
