타입스크립트란?

TypeScript는 컴파일-타임 타입 검사자가 있는 JavaScript의 런타임입니다.

• 타입스크립트는 자바스크립트에 타입 을 부여한 언어다.
• 정적 타입 검사자 로서 프로그램을 실행시키기 전에 값의 종류를 기반으로 프로그램의 오류를 찾는다.
• 자바스크립트 코드의 런타임 특성 을 절대 변화시키지 않는다. 타입스크립트의 컴파일러가 코드 검사를 마치면 타입을 삭제해서 결과적으로 '컴파일된' 코드를 만든다. 즉 코드가 한번 컴파일되면, 결과로 나온 일반 JS 코드에는 타입 정보가 없다.
• TypeScript는 Javascript의 상위 레이어 다. Javascript의 기능을 제공하면서 그 위에 자체 레이어를 추가한다. 자바스크립트는 원시타입(string, number, object, undefined 등)을 가지고 있지만, 전체 코드베이스에 일관되게 할당되었는지는 미리 확인해주지 않는다. 타입스크립트는 이 레이어로서 동작한다.
• 클래스, 인터페이스, 모듈 등의 강력한 기능을 제공하며, 순수한 객체 지향 코드 를 작성할 수 있다.

장점

에러의 사전 방지

함수, 컴포넌트 등의 타입을 추론할 수 있어 코드를 실행하지 않아도 IDE 상에서 바로 알 수 있다.

코드 가이드 및 자동 완성

자동완성이 굉장히 잘된다. 함수를 사용 할 때 해당 함수가 어떤 파라미터를 필요로 하는지, 그리고 어떤 값을 반환하는지 코드를 따로 열어보지 않아도 알 수 있다.

프로그램 부분 간의 더 명확한 통신

리액트 컴포넌트의 경우 해당 컴포넌트를 사용하게 될 때 props에 무엇을 전달해줘야하는지, JSX를 작성하는 과정에서 바로 알 수 있고, 컴포넌트 내부에서도 자신의 props나 state에 어떤 값이 있는지, redux의 store 안에 어떤 상태가 들어있는지 바로 알 수 있다.

타입스크립트 프로젝트 시작하기

1. 타입스크립트 파일 생성 및 작성
   .ts 확장자

   // index.ts
   function sum(a: number, b: number): number {
   return a + b;
   }
   
   sum(10, 20);
   

2. 타입스크립트 설치
   $ npm i typescript -g

3. 자바스크립트 컴파일
   $ tsc index.ts

타입스크립트 설정 파일 옵션

tsconfig.json

예시

{
  "compilerOptions": {
    "allowJs": true,
    "checkJs": true,
    "noImplicitAny": true // 암시적으로 선언되었는데 any로 추론되면 에러 발생
  }
}

📑 referece

• 인프런 - 타입스크립트 입문(캡틴판교)
• 타입스크립트 - kr

React 애플리케이션에서 서버 상태를 가져오고, 캐싱하고, 동기화하고, 업데이트 하는 작업을 쉽게 만든다.

// ✅ : react-query를 사용하면 하나의 훅으로 모든 페칭에 연관된 상태를 한번에 제어할 수 있다.
const { status, data, error, isFetching } = useQuery(() => fetch(URL));

핵심개념 : Server-state와 client-state -- global state ㄴㄴ

• 비동기 관련된 로직 처리 -> 동기적으로 업데이트 되는 데이터와 액션만 남길 수 있다.
• Redux를 더 취지에 맞게 사용할 수 있음 : Redux는 전역관리를 useQuery는 서버에서 받아온 데이터 관리를

// TODO : 우리 프로젝트에 react-query를 쓰려는 이유가 뭐지? 상태관리를 리덕스없이 진챠 할 수 있는 것?

만들어진 동기

• react 자체가 데이터를 패칭해오거나 업데이트 하는 옵셔을 제공하지 앟ㄴ기 때문에 원래 React 개발자들은 각자의 방식으로 http 통신 로직을 짜야했다.
• Redux 같은 전역 상태관리 라이브러리들이 클라이언트 상태값에 대해서는 잘 작동하지만, 서버 상태에 대해서는 그렇게 잘 작동하지 않는다.Server State는 Client State와 완ㄴ전 다르기 때문
  • 서버 데이터는 항상 최신 상태임을 보장하지 않는다. fetching을 수행해야만 최신 데이터로 전환됨
  • 네트워크 통신은 최소한으로 줄이는게 좋은데, 복수의 컴포넌트에서 최신 데이터를 받아오기 위해 fetching을 여러번 수행하는 낭비가 발생할 수 있다.

사용법

• App.js에서 Context Provider로 컴포넌트를 감싸고 queryClient를 내려보내줌
  // TODO : Context가 뭐임??/

컨셉

• Query들은 4개의 상태를 가지며, useQuery가 반환하는 객체의 프로퍼티로 어떤 상태인지 확인이 가능하다
  • fresh : 새롭게 추가된 쿼리 인스턴스
  • fetching : 요청을 수행 중인 쿼리
  • stale : 인스턴스가 존재하지만 이미 패칭이 완료된 쿼리. 특정 쿼리가 stale된 상태에서 같은 쿼리를 useQuery로 또 호출해 마운트를 시도하면 캐싱된 데이터 반환
  • inactive : active 인스턴스가 하나도 없는 쿼리. 렌더링시에 다시 호출되지 않은 쿼리들은 inactive됨
• refetching이 일어나는 경우?
  • 렌더링 간 쿼리 인스턴스가 다시 만들어졌을 때
  • window가 다시 포커스 되었을 때
  • 네트워크가 다시 연결되었을 때
  • refetch interval이 있을 때 : 요청 실패한 쿼리는 디폴트로 3번 더 백그라운드단에서 요청하며, retry, retryDelay 옵션으로 간격과 횟수를 커스텀 가능하다

// TODO : 쿼리 인스턴스가 뭐임?

useQuery

useMutation

• server state에 side effect를 일으키는 경우에 사용(create, update, delete)
• useQuery를 호출하면 최상위에서 호출해야한다는 훅의 규칙에 위배되기 때문인듯

📑 reference
김맥스 기술 블로그 - React-Query 살펴보기