프론트엔드 - 16

컴포넌트, props, data, prev,el,graphql-variables의 실체

컴포넌트,props의 실체

일반적인 함수

// 함수의 선언
const func2 = (param) => {
		console.log(param.count)
	}

// 함수의 실행
func2({count : 123})

// 결과
	// 123

• func2 함수 실행 시 {count: 123} 이라는 객체가 인자로 들어가서 실행 됨

• 함수형 컴포넌트도 마찬가지로 함수이기에 실상은 return 문에서 Presenter 라는 함수를 리턴하고 있는 것
  
  
  

• 따라서 함수 안에 인자로 들어가는 부분은 객체형태로 들어가고, 이는 곧 props 객체임을 알 수 있음
  *즉 props로 받아와서 props.aaa, props.bbb로 쓰던 것은 props라는 객체 자체를 인자로 함수에 넘긴 후, 해당 객체에서 필요한 키만 뽑아서 쓰는 것

prev의 실체

setCount((prev)=>{return prev+1})

• prev 또한 마찬가지로 화살표 함수의 매개변수에 인자로 들어가는 것

graphql-variables(변수)의 실체

+a) $는 사실 변수다

const CREATE_BOARD = gql`
mutation createBoard($writer: String){
		createBoard(writer: $writer){
			_id
		}
	}
`

• $writer 는 사실 이름이 변경되어도 상관없는 매개변수

+a) mutation, query 앞에 작성하는 이름은 그룹명이다

const REQUEST = gql`
mutation 한번에요청할그룹이름 ($변수 : String){
	원하는API1(백엔드지정:$변수){
		//받아올 것
	}

	원하는API2(백엔드지정:$변수){
		//받아올 것
	}
}
`

• graphql 은 한 번의 요청에 여러 API를 동시에 요청할 수 있기에 이런 각 API들을 묶어서 그룹화하고, 해당 그룹의 이름을 지정하기 위해 작성했던 것

Graphql 의 탄생 이유 (rest-api의 문제점과 endpoint)

• endPoint = API 가 서버에서 리소스 접근이 가능하도록 하는 URL
  
  
• graphql이 없던 시절, rest-api의 가장 큰 문제는 너무 많은 endpoint가 만들어진다는 점이었음
  *POST, GET, PUT, DELETE, UPDATE 방식을 한 번씩 이용해도 이미 5개나되는 endpoint 생성 (한 개의 요청에 한 개의 endpoint 생성 필요)

언더페칭, 오버페칭

언더페칭 = 필요한 데이터 수에 비해 한 번에 하나의 API 요청으로 데이터를 여러 번 받아오는 것
*rest-api는 endpoint에 body를 넣어 보내서, 한 개의 endpoint에 한 개의 body만 들어감 (graphql 과 달리 한 번에 하나의 API만 요청가능)

오버페칭 = 굳이 필요하지 않은 데이터까지 모두 받아오는 과정
*rest-api는 필요한 데이터와 상관없이 모든 결과값을 데이터로 받아와야 하지만, graphql은 필요한 데이터만 받아올 수 있음

graphql 은 사실 rest-api다

• graphql은 rest-api의 POST 방식에서 data를 넣어 요청을 보낼 수 있음에 착안하여 만들어진 방식
  *즉 완전한 새로운 방식이 아닌 기존 rest-api의 응용버전이라고 할 수 있음

• POST 방식의 body에 실행할 함수들의 이름을 적어서 endpoint 요청

• 이후 백엔드로 넘어간 데이터는 미리 만들어 둔 함수들 중 데이터와 매칭되는 함수들을 실행하고, 원하는 결과값을 받아오게 됨