Mutation은 데이터를 읽는게 아닌 변경하는 로직에 대한 내용이다. CREATE UPDATE, DELETE의 역할을 수행한다.

useMutation의 특징

• mutate 함수를 반환한다.
• 캐싱할 필요가 없으므로 쿼리 키를 사용하지 않는다.
• 캐시가 존재하지 않으므로, isFetching이 없다.
• retry를 3회 시도하는 useQuery와는 다르게 retry가 일어나지 않는다. 만약 retry로 실패시 재시도하려면, 설정이 필요하다

사용법

• 기본적으로 useQuery와 같이 isLoading등이 존재하므로, 충돌을 피하기 위해 구조분해할당을 피해야할 경우가 있다.
• mutate메서드를 통해 인자를 받을 수 있다.

import { useQuery, useMutation } from "@tanstack/react-query";

async function deletePost(postId) {
  const response = await fetch(
    `https://jsonplaceholder.typicode.com/postId/${postId}`,
    { method: "DELETE" }
  );
  return response.json();
}


//isLoading 등 이미 선언된 요소들과의 충돌을 피함.
const deleteMutation = useMutation((postId) => deletePost(postId));

//jsx
return (
    <>
      <h3 style={{ color: "blue" }}>{post.title}</h3>
      <button onClick={() => deleteMutation.mutate(post.id)}>
        Delete
      </button>
      {deleteMutation.isError && <p>에러로 인해 지우지 못했습니다.</p>}
      {deleteMutation.isLoading && <p>지우는 중입니다.</p>}
      {deleteMutation.isSuccess && <p>데이터가 성공적으로 지워졌습니다.</p>}
    </>
  );

비동기 요청은 받아오는 속도가 느리고, 데이터 양이 방대할수록 오래걸린다. 사용자 경험을 위해 데이터를 미리 받아 캐싱해놓으면, 새로운 데이터를 받기 전에 사용자가 캐싱된 데이터를 볼 수 있어 UX에 큰 영향을 끼친다.

특징

• 데이터를 미리 캐싱해준다.
• 기본 값으로 즉시 stale 상태가 된다.
• refetching되는 사이에 화면에 임시적으로 보여준다.
  • cachetime이 만료되지 않는 가정하에!

사용법

• prefetch는 useQueryClient의 메소드로 사용한다.
• 불러오는 시점은 언제일까?
  • 페이지가 1에서 2로 넘어갈 때, 미리 3의 데이터를 받아와 쿼리 키에 캐싱한다.
  • 그러면, 다음 페이지로 넘어갈 때, 사용자는 미리 받아온 stale 상태의 데이터를 기다림 없이 볼 수 있다.
• useEffect를 사용해 현재 페이지의 상태가 바뀔 때마다 의존성에 의해 다음 페이지의 데이터를 요청하는 방법을 쓴다.

import { useEffect, useState } from "react";
import { useQuery, useQueryClient } from "@tanstack/react-query";

async function fetchPosts(pageId) {
  const response = await fetch(
    `https://jsonplaceholder.typicode.com/posts?_limit=10&_page=${pageId}`
  );
  return response.json();
}

const queryClient = useQueryClient();
  useEffect(() => {
    if (currentPage < maxPostPage) {
      const nextPage = currentPage + 1;
      queryClient.prefetchQuery(["posts", nextPage], () =>
        fetchPosts(nextPage)
      );
    }
  }, [currentPage, queryClient]);

  const { data, isLoading, isError } = useQuery(
    ["posts", currentPage],
    () => fetchPosts(currentPage),
    { staleTime: 2000, keepPreviousData: true }
  );

*isFetching vs isLoading

isFetching

• isFetching은 비동기 함수가 아직 데이터를 가져오지 못했을 때, true를 반환한다.

isLoading

• isLoading은 비동기 함수를 가져오지 못했으며, 캐싱된 데이터도 존재하지 않을 때, true를 반환한다.

• 데이터를 페이지마다 동적으로 가져와보자.

어떻게 요청 한 번에 하나씩 캐싱하지?

• 다음의 예시를 보자.

async function fetchPosts(pageId) {
  const response = await fetch(
    `https://jsonplaceholder.typicode.com/posts?_limit=10&_page=${pageId}`
  );
  return response.json();
}

const { data, isLoading, isError } = useQuery(["posts"], () => fetchPosts(currentPage));

• 위와 같이 데이터를 불러와서 적용하면 페이지를 넘길 때, 잘 받아와질까?

정답은 No.

• React Query는 기본적으로 쿼리키 posts에 캐싱하도록 선언되어있다.
• 즉, 페이지를 아무리 넘겨도 캐싱된 데이터는 같은 쿼리 키를 공유하므로 바뀌지 않는다.
• 그러므로, 아래와 같이 리스트에 페이지마다 다른 쿼리 키에 캐싱되도록 해줘야한다.

async function fetchPosts(pageId) {
  const response = await fetch(
    `https://jsonplaceholder.typicode.com/posts?_limit=10&_page=${pageId}`
  );
  return response.json();
}

const { data, isLoading, isError } = useQuery(["posts", PAGE_ID], () => fetchPosts(currentPage));

• 이제 제대로 작동하는 것을 볼 수 있다.

위의 useQuery는 이제 PAGE_ID에 의존성을 갖게 되었고, PAGE_ID가 바뀌면 새로 요청을 보내 해당 페이지를 출력해준다.

1. LightHouse 툴을 활용한 페이지 검사

• Category

  • 무엇을 위한 검사를 할지 항목을 선택 가능

• Device

  • 기기를 선택할 수 있음.
    • Mobile
    • Desktop

• Plugins

  • 커스텀 플러그인 세팅 가능

• Generate Report

  • 성능 검사를 완료하면 아래와 같이 보여준다.
  • 1.METRICS - 검사의 지표를 통해 성능을 확인할 수 있다.
  • 2.스크린 샷으로 랜더링된 페이지 목록을 볼 수 있다.
  • 3.Opportunities - 리소스의 관점에서 로딩 성능 최적화에서 어느 부분을 개선할 수 있을지 문제점과 문제점의 해결 방안을 제시해 준다.
  • 4.Diagnostics - 페이지의 실행 관점에서 렌더링 성능 최적화에서 문제점과 해결 방안을 제시해 준다.
  • 

2. Opprtunities 항목을 통한 최적화

• 이미지 사이즈 최적화를 먼저 보겠다.
• 아래의 이미지들을 보면 상당히 크기가 크다.

• 이 아래의 이미지를 보면 랜더링된 이미지는 고작 120 * 120이지만 불러온 이미지의 크기는 1200 * 1200임을 알 수 있다.
• 넓이로 따지면 100배 정도는 더 크다.
• 그러므로 120 * 120 크기의 이미지를 사용하는 것이 옳은가?
  • 해상도에 따라서 더 많은 픽셀을 요구할 수 있으므로 2배 정도 크기를 사용해보자.

• 아래와 같이 API를 통해 이미지의 주소를 가져온다.
• 이런 경우에는 이미지를 줄이기 쉽지 않다.
  • 이미지 CDN을 활용해 해결한다!

CDN이란?

Contents Delivery Network의 약자로 물리적 거리의 한계를 극복하기 위해 소비자(사용자)와 가까운 곳에 컨텐츠 서버를 두는 기술

ex) 미국 원본 서버에서 미리 한국 서버에 이미지를 복사해두면, 사용자가 요청할 때, 미국으로 요청을 보내지 않아도 된다.

image CDN이란?

image processing CDN

Image CDN은 기본적인 CDN 개념과 이미지 처리 과정을 거쳐 사용자에게 전달하는 과정이다. 사이즈, 포맷 등을 모두 처리할 수 있다.

http:cdn.image.com?src=[img src]&width=200&height=100

위와 같이 사용할 수 있다. 원본 이미지 소스를 width: 200, height: 100으로 가공하는 소스이다.

• Imagix와 같은 사이트에서 최적화 소스 솔루션을 제공한다.

React Native의 동작 원리

• React Native는 javascript기반의 마크업 언어를 iOS와 안드로이드 코드로 변환해 준다.
• react native는 bridge를 통해 안드로이드, ios에 요청을 보낸다. 앱을 만들기 위해서는 JavaScript, Markup/Styling 뿐만 아니라 위 그림에 나온 모든 인프라를 설치해야만 한다.
• 물론 Expo는 모든 과정을 대신 수행해 Javascript와 Markup/Styling만 진행하면 되도록 해준다. 하지만, 치명적인 단점이 있다.
  • Expo 서버에서 동작하므로 가끔 불안정함.
  • 상당히 앱 사이즈가 비대해짐. (Expo의 모든 기능을 내장한 채라서)
  • 세부 설정을 건들이기 상당히 불편함.

즉, 기본적으로 JavaScript로 읽고 동작하는 코드를 React Native가 Native 앱의 일부로 만들고 해석해주는 일종의 번역기라고 생각하면 된다.

1. Expo vs React Native CLI 무엇을 사용할까?

Expo의 장단점

장점

• React Native를 처음 개발하는 사람에게 편리하다.

• React Natvie를 위한 기본 설정이 미리 세팅되어있다.

• Android / Xcode를 설치하지 않아도 QR코드를 통해 에뮬레이터를 실행시킬 수 있다.

• 배포가 매우 쉽다.

  단점

• Java, kotlin, swift 등의 네이티브 모듈을 추가 할 수 없다.

• 기본 파일 크기가 크다

• 기능이 많은 앱 개발에는 부적합하다.

• 블루투스가 안된다.

• Eject로 다시 세팅하는게 상당히 번거롭다.

React Native CLI의 장단점

장점

• 네이티브로 앱을 개발할 수 있다.
• 기존 네이티브 언어로 개발을 이어나갈 수 있다.
• 네이티브 파일들을 직접 수정할 수 있다.
• 새로운 기능의 모듈을 직접 만들어 사용할 수 있다.
• Expo 패키지 이용이 가능하다.

단점

• 초기 환경 구성이 어렵고 오래걸린다. 옳은 방법으로 세팅하기도 어렵다.
• 프로젝트를 위해 Android / Xcode를 전부 설치해 빌드 및 배포를 해야한다.
• 배포와 업데이트 시간이 상대적으로 오래걸린다.
• 안드로이드, IOS에 대한 폴더 구조에 대한 기본지식이 필요하다

Recoil, 왜 사용할까?

• Context API는 Provider 하위의 모든 컴포넌트가 상태 변화 시 리렌더링
• 전역 상태 관리 코드가 굉장히 간결하며, 사용이 간편함.
• 페이스북에서 공식적으로 만들었으며, 권장하는 전역 상태 관리 툴
• 서버 상태/클라이언트 상태를 분리할 때, 코드 복잡도가 매우 낮아짐.

1. Redux보다 좋아?

Redux의 동작 원리

• MVC패턴의 문제점
  • 페이스북에서 MVC패턴의 고질적인 문제를 해결하기 위해 만든 패턴
    • 규모가 커져 수많은 Models, Views가 생기면 복잡도가 엄청나게 증가함.
  • 
  • Model이 늘어날수록 전파해야할 대상도 증가해 신속하지 못하며, 모델에서 전파된 이벤트가 모든 Views에 예측이 불가하게 전파된다.

• Flux패턴

  • View가 Model을 변경할 수 없는 단방향 데이터 흐름
  • Action: 상태 변화 담당
  • Dispatcher: 데이터 저장소(Store)로 Action의 메세지를 전달
  • Model: 데이터 저장소(Store) 역할. Action의 타입에 맞게 상태 변화
  • View: 컴포넌트 및 페이지. 상태 변화 시, 해당 상태를 가진 컴포넌트를 리렌더링

• Redux는 Flux패턴과 유사하지만 다르다.

  • Redux는 싱글톤패턴을 사용
  • Reducer로 상태 관리를 넘기고 그 조각들을 단 하나의 거대한 저장소에 묶어서 사용함. (Dispatch, Store)

Recoil의 동작 원리

• Atoms

  • Atom은 저장소의 역할을 하며, 상태의 작은 단위임
  • Atom은 unique key로 구분되며, Atom의 상태가 바뀌면 구독하는 모든 컴포넌트가 리렌더링됨.(동일한 상태를 공유함)
  • 

• Selector

  • Atom의 상태를 바탕으로 함수 연산을 통해 새로운 값을 반환하는 순수 함수. 기본적으로 연산된 값을 캐싱한다.
  • 말이 어려워보이지만, 값을 가공해서 계산된 값을 내뱉는 함수임.
  • 기존의 Atom의 상태가 변화하면 Atom을 구독하는 모든 Selector들도 다시 실행.(종속 관계)
  • Selector의 장점은 기존에는 상태를 보존하면서 값을 가공하기 불편했던 문제가 해결된다는 점이다.

2. Recoil 사용법

• Atom

  • 선언

    export const smallState = atom({
          key: 'smallState', // 고유한 키 값
         default: "작은 상태",
    });

  • 참조 & 상태 변화

    function SmallStateComponent() {
      const [smallState, setSamllState] = useRecoilState(smallState);
      return (
      <div>{smallState}</div>
        <button onClick={() => setSmallState("다른 작은 상태")}>
          상태를 바꿔보자
        </button>
      );
    }

  • 상당히 useState와 유사하다. Redux와 다르게 React스러운 상태관리임을 알 수 있다.

• Selector

  • 캐싱이 자동으로 이루어짐.
  • atom에 종속되어 항상 같은 값을 반환해야함
  • 참조 시에, read-only

    import { dataList } from "./atom";
    export const userSelector = selector({
      key: "mySelector",
      get: (params) =>
        ({ get }) => get(dataList).filter((myData)
    }
    );
    
    

• SelectorFamily
  • 파라미터를 통한 동적인 변화에 대응

    import { dataList } from "./atom";
    export const userSelector = selectorFamily({
      key: "mySelector",
      get: (params) =>
        ({ get }) => get(dataList).filter((myData) => myData.id.includes(`${params}`))
    }
    );
    

• React Query는 서버 상태를 관리하기 위해 아래와 같은 다양한 기능들을 지원한다.

  • 로딩 및 에러 처리
  • 페이지네이션 / 무한 스크롤
  • 데이터 요청
  • 데이터 사전 요청(Prefetching)
  • 데이터 수정 및 업데이트(Mutations)
  • 중복 요청 제거
    • 기존의 쿼리가 출력되는 동안 다른 컴포넌트에서 중복 요청이 일어나면 중복 요청을 제거한다.
  • 서버 요청 에러 재시도(Retry)

사용 방법

1. Query client 생성

쿼리들과 캐시를 관리하는 클라이언트

2. QueryProvider 적용

자식 컴포넌트들의 캐시와 클라이언트의 기본 설정값을 제공 query client에 값으로 적용

import { QueryClient, QueryClientProvider } from "@tanstack/react-query";

const queryClient = new QueryClient();

function App() {
  return (
    // provide React Query client to App
    <QueryClientProvider client={queryClient}>
      <div className="App">
        <h1>Blog Posts</h1>
        <Posts />
      </div>
    </QueryClientProvider>
  );
}

3. Hook 사용

useQuery를 기본적으로 데이터 패칭에 사용

import { useState } from "react";
import { useQuery } from "@tanstack/react-query";

import { PostDetail } from "./PostDetail";


//데이터를 요청해 캐싱할 값을 반환하는 함수
async function fetchPosts() {
  const response = await fetch(
    "https://jsonplaceholder.typicode.com/posts?_limit=10&_page=0"
  );
  return response.json();
}

export function Posts() {
  //인자 1: 쿼리 키 배열, 2: 비동기 데이터 요청 함수
  const { data, isLoading } = useQuery(["posts"], fetchPosts);

  if (isLoading) {
    return (
      <div>로딩 중</div>
    )
  }

  if (isError) {
    return <div>에러가 발생했습니다.</div>;
  }

  return (
    <>
      <ul>
        {data.map((post) => (
          <li
            key={post.id}
            className="post-title"
          >
            {post.title}
          </li>
        ))}
      </ul>
    </>
  );
}

• 여기서 중요한 점!

  • 비동기인 useQuery의 데이터 요청은 당연하지만 data를 undefined로 반환한다.
  • 렌더링 시점이 요청을 받아오는 속도보다 빠르므로 기본 제공해주는 isLoading을 사용해 데이터를 받아오는 중에는 로딩중을 조기 반환해줬다.
  • 에러 처리 또한 같은 방법으로 해줬다.

• 참고 사항

  • isFetching과 isLoading과의 차이점

    • isFetching: 아직 Axios, Fetch 등 요청이 끝나지 않았음. 더욱 포괄적인 개념.
    • isLoading: isFetching의 상태에서 캐싱된 데이터도 없는 상태를 의미함. 페이지네이션에서는 캐싱된 데이터가 존재하는지 여부가 중요하기도 함

  • Retry 속성

    • 기본적으로 queryClient는 디폴트 값으로 retry를 3회 시도하도록 설정되어있다. 그러므로, isError에서 에러가 발생 시, 데이터를 가져오기 위해서 3회를 자동으로 재요청을 보낸다.

  • error

    • isError 외에도 구체적인 에러를 표시해주는 error, onError도 구조분해할당으로 사용이 가능하다.

  • 어? 다른 작업하다가 왔는데 왜 다시 데이터를 가져올까?

    const queryClient = new QueryClient({
    defaultOptions: {
    queries: {
      refetchOnWindowFocus: true,
    },
    },
    })

    그건 사용자가 윈도우 창을 집중해 사용할 때, 다시 데이터를 요청하는 옵션이 디폴트로 true로 설정된 상태이기 때문이다.

사용 배경

• 전역에서 상태를 관리하는 Redux는 캐싱하는 개념이다.

• 그러나 정말 클라이언트(리액트)에서 수행하는 상태 관리로도 충분할까? No No

  • 예시
    • 모달의 오픈 여부
    • 토큰값을 가지고 있는지(JWT)
    • 인풋에 입력한 값의 상태 관리

1. 서버 상태의 특징

• 다른 사람들과 페이지에서 데이터를 공유하는 경우엔 서버에서 관리하는 데이터이므로 화면이 최신인지를 정확히 알 수 없음.
• 비동기 API인 Fetch, Update 등으로 관리함
• 클라이언트의 상태와는 별개임.
• 토큰, 캐시처럼 잠재적으로 만료되거나 사라질 수 있음. 리액트에서 관리하는 state들은 일종의 캐시라고 볼 수 있음.

2. 클라이언트 상태의 특징

• 리액트, 뷰 등 클라이언트 자체가 온전히 제어가 가능함
• 초기값 설정 등 조작에 제약이 없음.
• 다른 사람들과 공유되지 않고 UI나 사용자의 인터렉션에 의해 변화함.
• 클라이언트 내에서는 최신 상태로 관리됨.

React-Query란?

• 데이터 가져오기
• 캐시
• 동기화
• 데이터 업데이트

위와 같은 작업을 수행해주는 라이브러리이다.

• 여기서 잠깐! react-query를 사용하기 위해서는 stale과 CacheTime에 대하여 알 필요성이 있다.

데이터를 refetch(재요청)하는 주기를 판단해주는 개념인 stale과 fresh이다.

1. fresh - 데이터를 받아온 직후로 가장 데이터가 신선한 상태를 의미한다. fresh 상태일 경우엔 새롭게 mount 되어도 네트워크 요청이 일어나지 않는다. 그래서 staletime을 지정해야 한다.

2. stale - 신선하지 않은, 즉, 낡은 데이터를 의미하므로 refetch가 이루어짐을 알린다.

3. staleTime - 기본 값은 0이며, 이는 받아옴과 동시에 낡은 데이터이므로 캐싱 데이터와 상관없이 계속해서 fetch를 한다. 즉, 서버의 부담이 늘지만 데이터 구조가 자주 바뀌는 경우엔 지정해주지 않으면 된다.

   4. cacheTime - 데이터가 inactive상태일 때, 캐싱된 상태로 남아있는 시간. 기본 값은 5분이다. 쿼리 인스턴스가 unmount되면 데이터는 inactive상태로 변경되고 cacheTime만큼 유지된다.

      cacheTime이 지나면 가비지 콜렉터로 수집된다.

      cacheTime이 지나기 전에 다시 쿼리 인스턴스가 마운트되면, 데이터를 fetch하는 사이에 캐시 데이터를 보여준다.

      cacheTime은 staleTime이 아무리 길어도(임시로 보관해도) inactive된 시점을 기준으로 데이터를 삭제하는 시점을 결정한다. 즉, cacheTime이 짧으면 데이터는 어차피 사라진다.

      inactive는 스크린에서 사용되지 않는 데이터임을 의미한다.

      cacheTime은 말 그대로 신선한데이터를 유지한다. 즉, 디폴트로 staleTime과 cacheTime을 사용하면, 캐싱이 되지 않는다.

주의점

• enabled:false로 설정하면 fetch 실패시 계속해서 retry하는 행위를 차단한다.

  • 이는 useQuery의 기능을 사용하지 않겠다는 것 이므로 수동으로 호출(refetch)을 해야한다.

• refetch함수는 캐싱 결과와 무관하게 ajax요청을 날린다. 이미 해당 키 값이 QueryClient 객체에 저장되어 있어도 무시하고 재요청을 보낸다.

  • 즉, 캐싱을 구현하는 경우엔 enabled:true상태여야만 한다.

useQuery

• CRUD의 Read를 담당하고 데이터 요청을 담당함.

import { useQuery } from 'react-query'

function App() {
    //인자 1: 쿼리 키, 인자 2: 쿼리 함수(fetch, axios 요청)
    const info = useQuery('todos', fetchTodoList)
}

• Query Key - 이 데이터를 관리할 키 값 (위의 데이터는 todos키에 대한 데이터)
  • 파이썬 딕셔너리 생각하면 된다. (로컬 스토리지와도 같음)
  • Array로 저장해 ['todos', 1]처럼 저장해서 페이지네이션에도 활용이 가능함.
• useQuery의 반환값
  • data: 요청에 성공한 데이터
  • error: 에러 반환 객체
  • isFetching: 요청 중일 때, true
  • status, isLoading, isSuccess 등의 현재 query 상태
  • refetch: 해당 쿼리를 refetch하는 함수
  • remove: 해당 쿼리를 캐시에서 지우는 함수
  • etc

• useQuery의 옵션
  • onSuccess onError, onSettled 등 성공 실패 완료 시 실행할 Side Effect 정의
  • enabled: 자동으로 query 실행할지 여부
  • retry: query 실패 시, 자동으로 retry할건지 여부
  • select 성공 시 가져온 data를 가공해서 전달
  • keepPreviousData: 새롭게 fetching 시 이전 데이터 유지 여부
  • refetchInterval: 주기적으로 refetch 할지 여부
  • etc
• 

• JSX는 단 하나의 요소만 반환할 수 있다.

• 이 특성을 이용해 아래와 같은 방법들로 반환이 가능하다.

  • div태그로 묶어주기

  • 여러 복합 요소들을 리스트 형태로 넘겨주기

  • wrapper 컴포넌트 만들기

div 태그로 묶을 때는 아래와 같이 쓸모없는 div들을 많이 중첩하게 되기에 이상적이진 않다.

<div>
  <div>
      <div>
     <h2>깊이가 3인 컴포넌트 내부로 들어가봤습니다.</h2>  
    </div> 
  </div>
</div>

*해결책

• wrapper컴포넌트로 의미를 알 수 있는 구조 만들어주기.

const Wrapper = props => {
    return props.children
}

export default Wrapper;

div 대신 Wrapper로 감싸주면된다.

• div는 실제로 돔에 출력되지만 Wrapper는 아니다.
• 왜냐하면, Wrapper은 props.children을 통해 내용만 가져오며 직접적으로 div와 내부의 요소들을 가져온게 아닌, 간접적으로 내부의 요소들만 Wrapper내부에 불러왔기 때문이다.
• 그러므로, 실제 Wrapper 컴포넌트는 존재하지 않았던 것처럼 DOM에서 사라진다.

<Wrapper> //실제로 DOM에 출력되지 않는 Wrapper 컴포넌트
  <div>
      <div>
     <h2>깊이가 3인 컴포넌트 내부로 들어가봤습니다.</h2>  
    </div> 
  </div>
</Wrapper>

2. Vite

기존 webpack

• CRA(Create React App)는 Webpack 기반의 리액트 기본 보일러 플레이트(최소한의 변경으로 여러 곳에서 재사용되는 기능 및 코드)이다.
• JS는 인터프리터 언어이기에 low-level 인 Go 언어보다 느릴 수 밖에 없다.
• HMR(Hot Module Replacement) 사용 => 모듈 전체를 다시 로드하지 않고, 변경 부분만 교환, 추가, 제거하는 방식

Vite

• Webpack이 아닌 매우 빠른 Go 언어를 기반으로한 EsBuild 자바스크립트 빌드 툴을 사용
• vite는 자바스크립트 파일을 두 개로 나눠 빌드한다.
  • 개발하는 동안 바뀌지 않는 의존성(dependencies) ex) node_modules폴더
    • 라이브러리 설치 등 바뀌는 시점마다 매번 번들링을 해놔서 크기가 매우 큰 node_modules 폴더가 하나의 js파일로 합쳐지는 번들링에 시간을 잡아먹지 않음.
    • webpack은 브라우저 요청 이전에 모든 파일을 번들링해 하나로 모으지만, vite는 이 node_modules라는 의존성 폴더만 미리 esbuild를 이용해 빠르게 번들링함.
  • 소스코드
    • 자주 수정됨
    • 소스코드 전체가 동시에 로드되지 않아도 된다.

**방식의 차이

• webpack

  • 기존에는 dev server 즉, 빌드 시작 시에 webpack이 모든 자바스크립트를 한 곳에 모아 번들링 한 후에 브라우저에 하나의 파일을 던져주는 방식이었음.

• vite는 Native ESM 즉, 자바스크립트 공식 모듈을 사용해 브라우저에서 필요한 소스코드만을 요청해 받아오는 방식을 사용한다.

  • Webpack은 소스코드를 업데이트하면 새로이 번들링을 진행한다. HMR을 사용하더라도 앱 사이즈가 커지면 무거워진 하나의 파일은 선형적으로 갱신 시간이 증가한다.
  • Vite는 하나로 묶는 과정이 없이 브라우저가 교체된 모듈만을 요청해 가져오는 방식으로 HMR을 이용하므로 앱 사이즈가 커져도 갱신 시간에 영향이 없다.

• 리액트에서는 동적으로 스타일 클래스를 추가하고 제거할 수 있다.

• 아래의 코드를 보면, input태그에 값이 들어오지 않은 채로 제출을 누르면 invalid라는 css클래스가 동적으로 추가되며 빨간색으로 input과 label 태그를 바꿔준다.

• 그리고, 입력이 들어올 때마다, 공백인지 아닌지를 판단해 제대로된 값이 들어온다면 invalid클래스를 제거해주도록해 원상복구 시키도록 한다.

• 아래의 코드를 통해 동적으로 특정 상황에 맞게 스타일을 쿼리스트링을 이용해 삽입하거나 제거할 수 있다는 사실을 알 수 있다.

const [isValid, setIsValid] = useState(true);

const goalInputChangeHandler = event => {
    if (event.target.value.trim().length > 0) {
      setIsValid(true);
    }
    setEnteredValue(event.target.value);
  };


const formSubmitHandler = event => {
    event.preventDefault();
    if (enteredValue.trim().length === 0) {
      setIsValid(false);
      return;
    }
  };


<div className={`form-control ${!isValid ? 'invalid' : ''}`}>

.form-control.invalid input {
  border-color: red;
  background: #ffd7d7;
}

.form-control.invalid label {
  color: red;
}

Styled Components

• Styled Components 란? 스타일이 적용되는 컴포넌트에만 영향을 미치고 다른 곳에서는 영향을 미치지 않는 라이브러리이다.
• 설치는 다음과 같다. npm install --save styled-components

Tagged template Literal

• 메서드의 괄호 대신에 백틱으로 전달하는 구문이다.
• styled.button 은 신기하게도 새로운 button을 반환하는 메서드이다.
  • h1 h2 p a button 어떤 html 태그들을 포함하고 있다.
• 이는 굳이 .button과 같은 선택자가 필요없고, 적용되는 추가적인 동작은 &을 붙이면 된다.
• 이렇게 생성된 버튼은 동적으로 생성된 클래스를 가지게 된다. 그리고 그 스타일 클래스는 고유한 값이므로, 다른 컴포넌트에 영향을 주지 않는다.

import styled from 'styled-components';

const Button = styled.button`
    font: inherit;
  padding: 0.5rem 1.5rem;
  border: 1px solid #8b005d;
  color: white;
  background: #8b005d;
  box-shadow: 0 0 4px rgba(0, 0, 0, 0.26);
  cursor: pointer;
  &:focus {
    outline: none;
  }
  &:hover,
  &:active {
    background: #ac0e77;
    border-color: #ac0e77;
    box-shadow: 0 0 8px rgba(0, 0, 0, 0.26);
  }
`

• 그리고 동적으로 백틱 내부로 props를 넘길 수 있다. 생성된 Button을 사용할 때, props를 넘기고
• border: 1px solid ${props => (props.전달받은 인자 ? 'red' : 'blue')}의 형태를 통해 동적으로 세부적인 css 요소에 접근할 수 있다.

• 부모 컴포넌트는 props를 통해 데이터를 전달한다. 그렇다면 자식은 어떻게 데이터를 부모에게 전달할까?
• 아래와 같이 하면 된다.
  • 부모 컴포넌트에서 자식 컴포넌트의 데이터를 받아올 함수를 만들어 props로 넘긴다
  • 자식 컴포넌트가 받은 함수에 데이터를 인자로 받는다.
  • 인자로 받은 데이터를 처리한다.

//자식 컴포넌트에서 submit을 통해 데이터를 전달
const submitHandler = (e) => {
    e.preventDefault();
    //이곳에 post 요청을 보낼 수도 있음!
    //axios.post('URL')
    props.getDataOfChildren(userInput) // 제출한 값을 인자로 받음.
    setUserInput('')
}

/////////////////////////////////////////

// 부모 컴포넌트


//자식에게서 data를 받아올 함수
const getDataOfChildren =  (childrenData) => {
    const newDataForm = {
        ...childrenData, //인자를 객체로 받아와 id를 부여해 새로운 객체 생성
        id: Date.now()
    }
    //여기서 setState를 통해 새로 저장하거나 사용!
}

//props로 자식의 데이터를 가져올 함수를 전달
return (
    <div>
        <ChildrenComponent getDataOfChildren={getDataOfChildren}/>
    </div>
)

• 리액트에서 양방향 바인딩은 어떻게 구현할까?

• 아래와 같이 값이 입력되어 onChange속성으로 상태 값을 변경시킴과 동시에 value를 userInput의 상태로 설정해준다.

• 그러면, input이 바뀔 때는 userInput 값이 바뀌고, 반대의 경우에도 value로 인하여 서로 값을 바꾸는 관계를 형성한다.

const [userInput, setUserInput] = useState({
    name: 'chulsoo',
    age: 8,
    created_at: '2021'
})

const changeAge = (e) => {
    setUserInput((prevState) => {
        return {...userInput, age: 5}
    })
}

const submitHandler = (e) => {
    e.preventDefault();
    //이곳에 post 요청을 보낼 수도 있음!
    setUserInput('')
}


//value를 이용한 양방향 바인딩
<form onSubmit="submitHandler">
    <input type="text" value={userInput.name} onChange={changeAge}/>
</form>

• useState를 객체로 다루는 옳은 방법을 알아볼 것이다.

• useState의 두 번째 인자는 무조건 그 안의 값으로 대체한다.

• 그 원리를 이용해 현재 첫 인자인 userInput을 가져와서 사용하게 된다.

• 그런데 비동기 작업 등 여러가지 상태 업데이트가 계획되어있다면, 잘못된 시점의 userInput을 받아 올 수 있다.

  • 1번 예시와 같이 사용하면 가장 최신의 userInput을 가져왔다고 확신할 수 없다.
  • 2번 예시는 업데이트된 userInput을 인자로 받아와 새로 업데이트해 반환하므로 가장 최신의 값을 받아온다고 확신할 수 있다.

const [userInput, setUserInput] = useState({
    name: 'chulsoo',
    age: 8,
    created_at: '2021'
})
// spread 연산자 1
const exFunction = (e) => {
    setUserInput({
        ...userInput, //잘못된 시점의 userInput을 받아올 수 있음.
        age: 5,
    })
}

//spread 연산자 2
const exFunction = (e) => {
    setUserInput((prevState) => { //prevState는 따끈따근한 최신의 userInput 상태를 가져오므로 세이프한 방법임.
        return {...userInput, age: 5}
    })
}

• JSX는 리액트에서 사용하는 UI를 정의할 때 사용하는 도구다.
• JSX는 HTML 문법과도 같은 형태를 가졌지만 실제로는 JavaScript로써 export되는 동작 방식을 가지고 있다.
• 이는 브라우저에서 번들링되는 과정에서 Babel을 사용해 일반 JS 문법으로 변환해준다.
  • 번들링이란? 기능별로 모듈화했던 JavaScript 파일을 묶어주는 작업
  • 번들러에 대하여 => 웹팩(Webpack)과 같은 번들러의 주 역할은 서로 연관(의존성) 있는 여러 JS파일(모듈)들을 하나의 번들(Bundle) 파일로 묶어주는 역할을 한다.
    • Webpack을 이용한 Bundling 작업 덕분에 한 파일(CSR의 가장 큰 특징)에서 모두 묶어 요청/응답을 받으므로 네트워크 코스트가 줄어든다
    • Webpack의 주요 구성 요소 중 하나인 로더(Loder)가 일부 브라우저에서 지원이 되지 않는 ES6 형식의 자바스크립트 파일을 ES5로 변환하여 사용가능하게 한다. 즉, 고전의 브라우저까지 모두 호환할 수 있도록 돕는 아주 효자스러운 기능을 가졌다.

예제

1.

import React from 'react';

return React.createElement('div', {}, 
            React.createElement('h2', {}, "Let's get JSX!"),
            React.createElement(Expenses, {item: expenses}, "Let's get JSX2!") //Expenses는 컴포넌트
            )

2.

return (
    <div>
      <h2>Let's get JSX!</h2>
      <Expenses items={expenses}/>
    </div>
)

• 위의 1과 2는 완전한 동치이다.

• 두 코드의 차이점은 2번은 React를 직접 가져오지 않아도 되는데 내부적으로는 1번과 같이 동작하고 있다.

• 위의 return React.createElement 구문을 보면 반환은 오직 하나의 div 태그이고 내부적으로 계속해서 하위 태그들을 만들어내는 것을 볼 수 있다. 이러한 이유로 return은 오직 한 개만 반환하기에 div로 감싸주는 것 이다.

• 그리고 1번과 같이 사용하기 위해서는 React를 명시적으로 import해서 사용해야만한다.

즉, 보이지 않았겠지만, 내부에서는 React가 JSX를 사용할 때 항상 동작하고 있었다는 것을 의미한다. 왜 div와 같은 wrapper 태그가 필요했는지 이제야 이해할 수 있을 것이다.

• div 태그로 감싸 리액트 컴포넌트를 전달해주는게 기본적이다.

• 하지만 박스의 역할을 하는 Sidebar, Card, Box, Dialog 등은 모두 각각의 컴포넌트 틀 및 스타일, 기능을 가지고 있다.

• 그렇게 div의 역할을 대신해 감싸주는 wrapper의 역할을 하는 컴포넌트가 children prop이다.

• 그렇게 다양하게 재사용할 수 있는 여지를 줍니다. ul태그가 꼭 필요한 li태그들은 Category라는 아래의 wrapper컴포넌트를 생성하면 재사용성과 코드의 가독성이 증가한다.

const Category = (props) => {
  return <ul>{props.children}</ul>;
};


const App = () => (
  <Category>
      <li>리스트 입니다!</li>
      <li>리스트 입니다!</li>
      <li>리스트 입니다!</li>
      <li>리스트 입니다!</li>
      <li>리스트 입니다!</li>
  </Category>
);

• Enum은 특정 값들의 집합을 의미하고 타입을 지정해줄 수 있다.
• 함수에서 인자를 받을 때, 타입을 enum으로 지정할 시, enum 내부의 속성만을 호출할 때, 인자로 받을 수 있다. 아래와 같이 Answer객체를 타입으로 지정하면, Answer내부의 Answer.Yes 와 Answer.No만 인자로 사용해 함수를 호출이 가능하다.

  //숫자형 enum
  //별도의 값을 초기화하지 않으면 숫자형 enum임
  enum Shoes {
  Nike,
  Adidas //목록이 추가되면 인덱스 처럼 수가 증가함
  }
  

let myShoes = Shoes.Nike; console.log(myShoes) // 0

//문자형 enum enum Shoes2 { Nike = '나이키', Adidas = '아디다스' //목록이 추가되면 인덱스 처럼 수가 증가함 } console.log(Shoes2.Nike) // 나이키

// ex enum Answer { Yes = 'yes', No = 'no' }

function askQuestion(answer: Answer) { if (answer === Answer.Yes) { console.log('정답') } if (answer === Answer.No) { console.log('오답') } }

askQuestion(Answer.Yes) //파라미터의 타입이 Answer인 값만 넘길 수 있다. askQuestion(Answer.No) ```

• 인터페이스는 커스텀 타입을 정의 및 상속을 통해 확장할 수 있고 재사용성이 높다.
• 인덱싱이나 딕셔너리 패턴과 같이 key 혹은 value에 타입을 지정해주고 그 값에도 타입을 지정할 수 있다.

  interface User {
  age: number;
  name: string;
  }
  

// 변수에 활용한 인터페이스 var seho: User = { age: 33, name: '세호' }

// 함수에 인터페이스 활용 function getUser(user: User) { console.log(user) }

const capt = { name: '캡틴', age: 100 }

getUser(capt)

//함수의 스펙(구조)에 인터페이스 사용 interface SumFunction { (a: number, b: number) }

var sum: SumFunction; sum = function(a: number, b: number): number { return a + b }

//인덱싱 interface StringArray { [index: number]: string; }

var arr1: StringArray = ['a', 'b', 'c']; arr1[0] = 'a';

//딕셔너리 패턴 interface StringRegexDictionary { [key: string]: RegExp; //정규표현식 생성자 RegexExpression }

let obje: StringRegexDictionary = { // sth: /abc/, cssFile: /.css$/, jsFile: /.js$/, }

// obje['cssFile'] = 'a' Regex가 들어와야하는데 문자열이라 에러가 뜸

Object.keys(obj).forEach(function(val) {})

//인터페이스 확장

interface Person { name: string; age: number; }

interface Developer extends Person { language: string; }

let captain: Developer = { name: '캡틴', age: 100, language: '영어' }

## 2. Union & Interface
- Union
  - 기본 타입 - 여러 종류의 타입을 선택할 수 있음.
  - 객체 형태의 함수 인자 - 표기한 객체들에 모두 해당되는 속성만 사용 가능함.
    - 그 이유는, 두 객체 중에 한 객체를 선택했을 때, 다른 객체의 인자에 참조하게되면 안전하지 않기 때문이다.

  - 호출하는 관점에서는, 한 객체에 해당하는 모든 속성을 인자로 넘겨줘야만 한다. `겹치지 않는 속성은 사용하지 않는데 왜 인자로 넘겨야하지?` 라고 이상하게 느껴질 수 있지만, `내가 이 객체를 사용할 거야!`라는 것을 함수에 알려주기 위해서이다.
- Intersection
  - 객체 형태의 함수 인자 - 표기한 객체들의 모든 속성을 사용할 수 있다.
  - 중요한 점은, 함수를 호출할 때, 무조건 함수 내에서 사용되는 모든 객체에 포함되는 속성을 인자로 넘겨줘야만 한다는 것이다.
```ts
let sihyun: string | number | boolean;
function logMessage(value: string | number) { //Union Type은 하나의 타입 이상을 쓸 수 있음
  if (typeof value === 'number') {
    value.toLocaleString();
  }
  if (typeof value === 'string') {
    value.toString();
  }
  throw new TypeError('value must be string or number')

}
logMessage('hello');

interface Developers {
  name: string;
  skill: string;
}

interface Person2 {
  name: string;
  age: number;
}

function askSomeone(someone: Developers | Person2) {
  someone.name //공통 속성만 접근가능
  // someone.age
  // someone.skill
}


//인터섹션

let unionA: string | number | boolean;
let interB: string & number & boolean;

function askSomeone2(someone: Developers & Person2) {
  someone.name //공통 속성만 접근가능
  someone.age
  someone.skill
}

askSomeone({name: 'developer', skill: 'web development'})
askSomeone({name: 'sehan', age: 100})

askSomeone2({name: 'developer', skill: 'web development', age: 100}) //세 인자가 다 들어와야만 intersectio 함수가 동작함
let sihyun: string | number | boolean;
function logMessage(value: string | number) { //Union Type은 하나의 타입 이상을 쓸 수 있음
  if (typeof value === 'number') {
    value.toLocaleString();
  }
  if (typeof value === 'string') {
    value.toString();
  }
  throw new TypeError('value must be string or number')

}
logMessage('hello');

interface Developers {
  name: string;
  skill: string;
}

interface Person2 {
  name: string;
  age: number;
}

function askSomeone(someone: Developers | Person2) {
  someone.name //공통 속성만 접근가능
  // someone.age
  // someone.skill
}


//인터섹션

let unionA: string | number | boolean;
let interB: string & number & boolean;

function askSomeone2(someone: Developers & Person2) {
  someone.name //공통 속성만 접근가능
  someone.age
  someone.skill
}

askSomeone({name: 'developer', skill: 'web development'})
askSomeone({name: 'sehan', age: 100})

askSomeone2({name: 'developer', skill: 'web development', age: 100}) //세 인자가 다 들어와야만 intersectio 함수가 동작함

• 다른 타입에 해당할 경우는 빨간 줄을 표시한다.

  let str: string = 'hello';
  let num: number = 10;
  

let arr: Array = [1, 2, 3]; let arr2: Array = ['A', 'B', 'C']; let items: number[] = [1, 2, 3];

## 2. 튜플, 객체, 진위값
- 튜플은 모든 값에 타입을 각각 지정해준 배열임.
- 객체는 내부에 속성 타입을 지정하지 않아도 상관이 없음.
```ts
//튜플
let address: [string, number] = ['gang', 1]; //순서에 맞는 타입까지 지정하는 것이 튜플

//객체
let obj: object = {};
let person: object = {
  name: 'capt',
  age: 30
};

//객체 내부에 있는 속성 또한 타입 지정이 가능
let person2: { name: string, age: number } = {
  name: 'capt',
  age: 30
}

//진위값
let show:boolean = true

3. 함수 타입

// 함수의 파라미터에 타입 정의
function add(a: number, b: number) {
  return a + b;
}

add(10, 20);

//반환 값에 타입을 정의
function add2(): number {
  return 10 + 20;
}

//두 방식을 조합

function add3(a: number, b: number): number {
  return a + b;
}

//파라미터의 유연함과 제약
function add4(a: number, b: number): number {
  return a + b;
}

add4(10, 20, 30, 40) 
//에러 발생. 30, 40은 더 들어갈 수 없음. JS는 그냥 유연하게 무시함

add4(10)
//에러 발생. 인자가 부족함


//함수의 옵셔널 파라미터
function log(a: string, b?: string, c?: string) {

}

log('hello')
log('hello', 'world') //하나의 인자는 필수이지만, 두 개, 세 개는 필수가 아니게 되는 방식

1) 지연된 함수열을 병렬적으로 평가하기 - C.reduce, C.take

• 현재는 싱글스레드의 특성상 한 작업이 끝나면 다음 작업으로 넘어가는 식으로 작업한다. 하지만 한꺼번에 병렬적으로 연산하면 부하는 커지지만 훨씬 빠른 속도로 처리할 수 있다.

  const C = {};

  function noop() {
  }

  const catchNoop = ([...arr]) =>
    (arr.forEach(a => a instanceof Promise ? a.catch(noop) : a), arr);

  C.reduce = curry((f, acc, iter) => iter ?
    reduce(f, acc, catchNoop(iter)) :
    reduce(f, catchNoop(acc)));

  C.take = curry((l, iter) => take(l, catchNoop(iter)));

  C.takeAll = C.take(Infinity);

  C.map = curry(pipe(L.map, C.takeAll));

  C.filter = curry(pipe(L.filter, C.takeAll));

  const delay1000 = a => new Promise(resolve => {
    console.log('hi~');
    setTimeout(() => resolve(a), 1000);
  });

    go([1, 2, 3, 4, 5, 6, 7, 8, 9],
      L.map(a => delay1000(a * a)),
      L.filter(a => delay1000(a % 2)),
      L.map(a => delay1000(a * a)),
      // C.take(2),
      C.reduce(add),
      log,
      _ => console.timeEnd(''));

• 기존의 reduce는 배열의 하나씩 꺼내서 acc에 더해주는 식으로 연산했다면, C.reduce는 배열의 모든 값을 한꺼번에 출발시켜 병렬적으로 동시에 연산한다.

1) Promise + 지연평가

• take와 map은 기본적으로 Promise를 이용해 비동기로 처리해주는 로직이 내부에 필요하다.
• 그렇기에 map에서는 받은 함수를 Promise인지 판별해 then을 통해 값을 가져올 수 있게 해줘야하고, take 또한 마찬가지로 비동기 상황에서 연산의 순서를 보장하는 then을 재귀를 통해 해결할 수 있다.

     go(
      [1, 2, 3],
      L.map(a => Promise.resolve(a + 10)),
      take(2),
      log);
    go(
      [Promise.resolve(1), Promise.resolve(2), Promise.resolve(3)],
      L.map(a => a + 10),
      take(2),
      log);
    go(
      [Promise.resolve(1), Promise.resolve(2), Promise.resolve(3)],
      L.map(a => Promise.resolve(a + 10)),
      take(2),
      log);
    go(
      [1, 2, 3],
      map(a => Promise.resolve(a + 10)),
      log);
    go(
      [Promise.resolve(1), Promise.resolve(2), Promise.resolve(3)],
      map(a => a + 10),
      log);
    go(
      [Promise.resolve(1), Promise.resolve(2), Promise.resolve(3)],
      map(a => Promise.resolve(a + 10)),
      log);

• then으로만 재귀 없이 처리해준다면, go를 통한 연산 중간에 비동기 연산을 하면, 그 아래의 모든 연산이 then으로 비동기적으로 묶여버린다. 그렇기에 재귀를 통해 Promise 구문의 연산이 끝나면, 재귀를 통해 다음 구문이 Promise인지 즉시 판단해줄 수 있다.

2) Kleisli Composition - L.filter, filter, nop, take

• 세이프 코딩을 하기위해선 Promise를 통해 비동기적으로 반환하는 값이 조건에 해당하지 않으면 reject를 넘겨 다음 then이 아닌 catch로 흘러간다는 보장이 있어야한다.

• 그렇기에 아래의 코드를 보면, 1은 문제가 없지만 2는 filter에서 a % 2에서 걸리므로 reject를 반환하고 다음 L.map 등을 모두 지나쳐 take안에서 catch를 통해 미리 reject에 담아놓은 nop 이라는 표시를 받았다면 다음으로 넘어가 3에 대한 연산을 시작한다.

• 즉, 평가에 가까운 take log 등의 연산에서 reject를 통해 빠져나온 연산을 받아 재귀를 통해 다음 연산으로 넘기도록 처리해줘야 정상적으로 작동한다.

<script>
  go([1, 2, 3, 4, 5, 6],
    L.map(a => Promise.resolve(a * a)),
    // L.map(a => a * a),
    filter(a => Promise.resolve(a % 2)),
    // L.map(a => a * a),
    /*L.map(a => {
      log(a);
      return a * a;
    }),
    L.map(a => {
      log(a);
      return a * a;
    }),*/
    // take(4),
    /*log*/);
</script>

## reduce에서 nop 지원

<script>
  go([1, 2, 3, 4, 5],
    L.map(a => Promise.resolve(a * a)),
    L.filter(a => Promise.resolve(a % 2)),
    reduce(add)/*,
    log*/);
</script>

<script>
  go([1, 2, 3, 4, 5, 6, 7, 8],
    L.map(a => {
      log(a);
      return new Promise(resolve => setTimeout(() => resolve(a * a), 1000))
    }),
    L.filter(a => {
      log(a);
      return new Promise(resolve => setTimeout(() => resolve(a % 2), 1000))
    }),
    take(2),
    reduce(add),
    log);
</script>