🎧Be Dilettante⌨️

여러 interface 타입을 조건별로 하나의 타입 안에서 정의하고 싶을 때

export enum SearchType {
  FRUIT = ‘FRUIT’,
  FOOD = ‘FOOD’,
  CLOTHES = ‘CLOTHES’,
  SHOES = ‘SHOES’,
  BAGS = ‘BAGS’,
}

type TypeName<T> = T extends SearchType.FRUIT
  ? FruitItem
  : T extends SearchType.FOOD
  ? FoodItem
  : T extends SearchType.CLOTHES
  ? ClothesItem
  : T extends SearchType.SHOES
  ? ShoesItem
  : BagsItem;

사용 스택 및 라이브러리: React, lodash

Debounce 사용 목적: 검색시 input의 onChange마다 함수가 호출되는 것을 debounce를 통해 방지

1. Input의 onChange를 통한 api 호출

 
아래 함수를 살펴보자.
 

 
 
 
 
이 함수는 input에 텍스트를 입력할 경우 input의 onChange를 통해 포켓몬을 조회하는 api를 호출한다.

input의 onChange는 input에 값이 입력될 때마다 호출되기 때문에 글자 수 만큼 handleSearch 함수가 호출되는 것을 아래에서 볼 수 있다. (검색 성능 저하)


 

 
 
이를 방지하기 위해 lodash의 debounce 함수를 적용해 볼 것이다.

💡Lodash란? A modern JavaScript utility library delivering modularity, performance & extras. (공식 문서에서 정의하고 있는 lodash의 의미이다; 모듈성, 성능과 추가 기능 등을 제공하는 모던 자바스크립트 유틸리티 라이브러리이다.)

2. Lodash의 debounce 적용

$ npm i -g npm //npm 설치 완료시 생략
$ npm i --save lodash

위 명령어를 통해 lodash를 설치한다.


 

• Debounce란?

Creates a debounced function that delays invoking func until after wait milliseconds have elapsed since the last time the debounced function was invoked.
 
 
 

import { debounce } from 'lodash';

필요한 함수 debounce만 구조분해로 import한다. (전체 lodash를 import하는 것보다 메모리가 훨씬 적다)
 
 

   const getPokemon = debounce(async (value: string) => {
    await axios
      .get(`https://pokeapi.co/api/v2/pokemon/${value}`)
      .then((res) => {
        setPokemon(res);
      })
      .catch((err) => {
        return;
      });
  }, 300);

 
 
 
그런 다음 기존 getPokemon 함수를 debounce 함수로 감싸준뒤 지연시간을 숫자로 적어준다. (위 예시에서는 0.3초로 설정) 
 
 
이렇게 하면 input에 타이핑이 되더라도 함수 호출을 0.3초마다 하는 것을 볼 수 있다.
 
 

 3. State 변경과 debounce 동시 적용

그렇다면 만약 state 변경과 debouce를 함께 호출할 경우 debounce는 효과적으로 작동할까?

아래 handleSearch 함수는 input의 onChange가 호출될 때마다(값이 변경될 때마다) 실행된다.

handleSearch내에서 setText를 통해 변하는 input값을 동시에 저장하고, debounce를 통해 api를 호출하면 아래와 같이 함수가 만들어진다.
 

const getPokemon = debounce(async (value: string) => {
    await axios
      .get(`https://pokeapi.co/api/v2/pokemon/${value}`)
      .then((res) => {
        setPokemon(res);
      })
      .catch((err) => {
        return;
      });
  }, 300);

const handleSearch = (e) => {
  setText(e.target.value);
  getPokemon(e.target.value);
}

위 함수에서 문제점은 우리의 예상과 다르게 getPokemon함수가 0.3초마다가 아닌 input의 value가 바뀔때마다 호출된다는 점이다.

이 코드의 문제점은 setText 함수를 실행할 때마다 컴포넌트가 재렌더링되어 debounce함수를 호출하는 getPokemon함수를 재생성한다는 점이다.
 

 4. 컴포넌트 재렌더링에 관계없이 debounce 함수 실행하기

const getPokemon = useCallback(debounce(async (value: string) => {
    await axios
      .get(`https://pokeapi.co/api/v2/pokemon/${value}`)
      .then((res) => {
        setPokemon(res);
      })
      .catch((err) => {
        return;
      });
  }, 300),
  []
;

const handleSearch = (e) => {
  setText(e.target.value);
  getPokemon(e.target.value);
}

정답은 useCallback 함수로 debounce함수를 감싸주는 것이다.

위의 getPokemon 함수는 handleSearch에서 text가 변경이 되어도 이 변수를 구독하지 않기 때문에 debounce함수를 재생성하지 않는다.

원문: https://marmelab.com/blog/2024/01/23/react-19-new-hooks.html

일반적인 생각과 달리 React core팀은 리액트 서버 컴포넌트와 Next.js에만 오직 초점을 두진 않는다. 새로운 client-side 훅들이 다음 React 메인 버전인 19버전에 도입된다. 그들은 리액트의 두 가지 주요 문제점, 즉 데이터 가져오기(data fetching)과 폼(form)에 초점을 맞추고 있다. 이 훅들은 싱글 페이지 어플리케이션 작업을 하는 개발자를 포함해 React 개발자들의 생산성을 향상시켜줄 것이다.

더 이상 고민하지 말고, 새로운 훅들을 살펴보자!

• use(Promise)
• use(Context)
• Form actions
• useFormState
• useFormStatus
• useOptimistic
• Bonus: Async transitions

주목: 이 훅들은 React의 Canary와 실험적 채널에서만 사용할 수 있다. 이 훅들은 곧 출시될 리액트 19에 포함되지만, API는 최종 출시 전에 변경될 수 있다.

use(Promise)

이 새로운 훅은 클라이언트의 'suspending'을 위한 공식 API이다. 당신은 그것을 promise로 넘길 수 있고 리액트는 그것이 해결될 때까지 그것을 중단시킬 것이다. React use 문서에서 가져온 기본 구문은 다음과 같다.

import { use } from 'react';

function MessageComponent({ messagePromise }) {
    const message = use(messagePromise);
    // ...
}

좋은 소식은 이 훅이 데이터 패칭에 사용될 수 있다는 것이다. 여기 마운트시와 버튼 클릭시 데이터 패칭을 하는 구체적인 예시가 있다. 이 코드는 단일 useEffect를 사용하지 않는다:

<Suspense> 문서의 이 경고를 기억하는가?

프레임워크의 의견 없는 Suspense 지원 데이터 패칭은 아직 지원되지 않는다.

이는 React19에서는 더 이상 사실이 아니다.

새로운 use 훅은 숨겨진 힘이 있다: 다른 모든 React Hook들과 달리, use는 loop와 if와 같은 조건 절에서 호출할 수 있다.

이 말이 즉, 클라이언트 측에서 데이터를 가져오기 위해 TanStack Query와 같은 서드파티 라이브러리를 더 이상 사용할 필요가 없음을 의미할까? TanStack Query가 단순히 Promise를 해결하는 것 이상의 역할을 하기 때문에 더 두고 봐야 한다.

하지만 그것은 올바른 방향으로 나아가는 훌륭한 단계이며 REST 또는 GraphQL API를 기반으로 한 싱글 페이지 어플리케이션을 쉽게 만들 수 있을 것이다. 나는 이 새로운 훅에 매우 열광한다!

React 문서에서 use(Promise) 훅에 대한 자세한 내용을 읽어보아라.

use(Context)

React Context를 읽는데 같은 use 훅을 사용할 수 있다. 루프 안에서 호출할 수 있으며 if와 같은 조건문을 사용할 수 있다는 점을 제외하면 이는 정확히 useContext와 같다.

import { use } from 'react';

function HorizontalRule({ show }) {
    if (show) {
        const theme = use(ThemeContext);
        return <hr className={theme} />;
    }
    return false;
}

루프 혹은 조건절에서 컨텍스트를 읽는 유일한 방법이 컴포넌트를 둘로 나누는 것이기 때문에 이것은 일부 사용 사례에 대한 컴포넌트 계층 구조를 단순화할 것이다.

컨텍스트가 바뀌었더라도 컴포넌트의 리렌더링을 조건적으로 건너뛸 수 있기 때문에 성능 측면에서도 큰 혁명이 될 수 있다.

React 문서에서 use(Context) 훅에 대한 자세한 내용을 읽어보아라.

Form Actions

이 새로운 기능을 사용하면 함수를 <form>의 액션 프롭에 전달할 수 있다. 폼이 제출되면 React는 이 함수를 호출한다:

만약 당신이 <form action> 프롭을 React18에서 추가한다면 당신은 경고(warning)를 받게 될 것을 기억하라:

Warning: Invalid value for prop action on <form> tag. Either remove it from the element or pass a string or number value to keep it in the DOM.

다음과 같은 form을 작성할 수 있는 React 19에서 이 경고는 더 이상 사실이 아니다.

import { useState } from 'react';

const AddToCartForm = ({ id, title, addToCart }) => {
  const formAction = async (formData) => {
    try {
      await addToCart(formData, title);
    } catch (e) {
      // show error notification
    }
  };

  return (
    <form action={formAction}>
      <h2>{title}</h2>
      <input type="hidden" name="itemID" value={id} />
      <button type="submit">Add to Cart</button>
    </form>
  );
};

type Item = {
  id: string;
  title: string;
};

const Cart = ({ cart }: { cart: Item[] }) => {
  if (cart.length == 0) {
    return null;
  }
  return (
    <>
      Cart content:
      <ul>
        {cart.map((item, index) => (
          <li key={index}>{item.title}</li>
        ))}
      </ul>
      <hr />
    </>
  );
};

export const App = () => {
  const [cart, setCart] = useState<Item[]>([]);

  const addToCart = async (formData: FormData, title) => {
    const id = String(formData.get('itemID'));
    // simulate an AJAX call
    await new Promise((resolve) => setTimeout(resolve, 1000));
    setCart((cart: Item[]) => [...cart, { id, title }]);

    return { id };
  };

  return (
    <>
      <Cart cart={cart} />
      <AddToCartForm
        id="1"
        title="JavaScript: The Definitive Guide"
        addToCart={addToCart}
      />
      <AddToCartForm
        id="2"
        title="JavaScript: The Good Parts"
        addToCart={addToCart}
      />
    </>
  );
};

accToCart 함수는 서버 Action이 아니다. 이것은 클라이언트 측에서 호출되며 비동기 기능일 수 있다.

이렇게 하면 리액트에서 검색 폼과 같은 AJAX 폼의 처리가 크게 간단해질 것이다. 그러나 이것은 양식 제출(유효성 확인, 사이드 이펙트 등)을 처리하는 것 이상의 일을 하는 React Hook Form과 같은 서드파티 라이브러리를 없앨만큼 충분하지 않을 수 있다. 

Tip: 당신은 위 예제에서 몇몇 사용성 문제를 발견할 수 있다. (submit을 진행할 때 submit 버튼이 활성화되지 않음, 확인 메세지 누락, 늦은 카트 업데이트). 다행히도 더 많은 훅들이 이러한 사용 사례를 돕기 위해 제공되고 있다. 계속 읽어보길!

React 문서에서 the <form action> prop에 대한 자세한 내용을 읽어보아라.

useFormState

이 새로운 훅은 아래 묘사한 것처럼 비동기 폼 액션을 돕는 역할을 한다. useFormState를 호출해 폼이 제출된 마지막 시점부터 액션의 반환 값에 접근한다.

import { useFormState } from 'react-dom';
import { action } from './action';

function MyComponent() {
    const [state, formAction] = useFormState(action, null);
    // ...
    return <form action={formAction}>{/* ... */}</form>;
}

예를 들어, 이것은 당신이 폼 액션에서 반환된 확인 혹은 에러 메세지를 보여주게 한다.

import { useState } from 'react';
import { useFormState } from 'react-dom';

const AddToCartForm = ({ id, title, addToCart }) => {
  const addToCartAction = async (prevState, formData) => {
    try {
      await addToCart(formData, title);
      return 'Added to cart';
    } catch (e) {
      return "Couldn't add to cart: the item is sold out.";
    }
  };

  const [message, formAction] = useFormState(addToCartAction, null);

  return (
    <form action={formAction}>
      <h2>{title}</h2>
      <input type="hidden" name="itemID" value={id} />
      <button type="submit">Add to Cart</button>&nbsp;
      {message}
    </form>
  );
};

type Item = {
  id: string;
  title: string;
};

export const App = () => {
  const [cart, setCart] = useState<Item[]>([]);

  const addToCart = async (formData: FormData, title) => {
    const id = String(formData.get('itemID'));
    // simulate an AJAX call
    await new Promise((resolve) => setTimeout(resolve, 1000));
    if (id === '1') {
      setCart((cart: Item[]) => [...cart, { id, title }]);
    } else {
      throw new Error('Unavailable');
    }

    return { id };
  };

  return (
    <>
      <AddToCartForm
        id="1"
        title="JavaScript: The Definitive Guide"
        addToCart={addToCart}
      />
      <AddToCartForm
        id="2"
        title="JavaScript: The Good Parts"
        addToCart={addToCart}
      />
    </>
  );
};

주목: useFormState는 react가 아니라 react-dom에서 부터 import되어야 한다.

React 문서에서 useFormState에 대한 자세한 내용을 읽어보아라.

useFormStatus

useFormStatus를 사용하면 부모 <form>이 현재 제출 중이거나 성공적으로 제출했는지 알 수 있다. 폼의 자식에서 호출할 수 있으며 다음 속성을 가진 개체를 반환한다:

const { pending, data, method, action } = useFormStatus();

당신은 데이터 속성을 통해 유저가 제출 중인 데이터를 표시할 수 있다. 폼이 제출되는 동안 버튼이 비활성화된 pending 상태 또한 아래 예시와 같이 표시할 수 있다:

import { useState } from 'react';
import { useFormStatus } from 'react-dom';

const AddToCartForm = ({ id, title, addToCart }) => {
  const formAction = async (formData) => {
    try {
      await addToCart(formData, title);
    } catch (e) {
      // show error notification
    }
  };

  return (
    <form action={formAction}>
      <h2>{title}</h2>
      <input type="hidden" name="itemID" value={id} />
      <SubmitButton />
    </form>
  );
};

const SubmitButton = () => {
  const { pending } = useFormStatus();
  return (
    <button disabled={pending} type="submit">
      Add to Cart
    </button>
  );
};

type Item = {
  id: string;
  title: string;
};

const Cart = ({ cart }: { cart: Item[] }) => {
  if (cart.length == 0) {
    return null;
  }
  return (
    <>
      Cart content:
      <ul>
        {cart.map((item, index) => (
          <li key={index}>{item.title}</li>
        ))}
      </ul>
      <hr />
    </>
  );
};

export const App = () => {
  const [cart, setCart] = useState<Item[]>([]);

  const addToCart = async (formData: FormData, title) => {
    const id = String(formData.get('itemID'));
    // simulate an AJAX call
    await new Promise((resolve) => setTimeout(resolve, 1000));
    setCart((cart: Item[]) => [...cart, { id, title }]);

    return { id };
  };

  return (
    <>
      <Cart cart={cart} />
      <AddToCartForm
        id="1"
        title="JavaScript: The Definitive Guide"
        addToCart={addToCart}
      />
      <AddToCartForm
        id="2"
        title="JavaScript: The Good Parts"
        addToCart={addToCart}
      />
    </>
  );
};

주목: useFormStatus는 react가 아닌 react-dom에서 import해야 한다. 또한 부모 폼이 위에서 설명한 action prop을 사용할 때만 작동한다.

이 훅은 useFormState와 함께 불필요한 컨텍스트 효과로 컴포넌트를 어수선하게 만들지 않고 클라이언트 측 폼의 유저 경험을 향상시킬 것이다. useFormStatus 후크에 대한 자세한 내용은 React 문서에서 확인할 수 있다.

useOptimistic

이 새로운 훅은 actioin이 제출되는 동안 사용자 인터페이스를 최적으로 업데이트할 수 있게 한다. 

import { useOptimistic } from 'react';

function AppContainer() {
    const [optimisticState, addOptimistic] = useOptimistic(
        state,
        // updateFn
        (currentState, optimisticValue) => {
            // merge and return new state
            // with optimistic value
        },
    );
}

위 카트 예제에서 우리는 AJAX 호출이 완료되기 전에 새 항목이 추가된 카트를 표시할 수 있다: 

import { useState, useOptimistic } from 'react';

const AddToCartForm = ({ id, title, addToCart, optimisticAddToCart }) => {
  const formAction = async (formData) => {
    optimisticAddToCart({ id, title });
    try {
      await addToCart(formData, title);
    } catch (e) {
      // show error notification
    }
  };

  return (
    <form action={formAction}>
      <h2>{title}</h2>
      <input type="hidden" name="itemID" value={id} />
      <button type="submit">Add to Cart</button>
    </form>
  );
};

type Item = {
  id: string;
  title: string;
};

const Cart = ({ cart }: { cart: Item[] }) => {
  if (cart.length == 0) {
    return null;
  }
  return (
    <>
      Cart content:
      <ul>
        {cart.map((item, index) => (
          <li key={index}>{item.title}</li>
        ))}
      </ul>
      <hr />
    </>
  );
};

export const App = () => {
  const [cart, setCart] = useState<Item[]>([]);

  const [optimisticCart, optimisticAddToCart] = useOptimistic<Item[], Item>(
    cart,
    (state, item) => [...state, item]
  );

  const addToCart = async (formData: FormData, title) => {
    const id = String(formData.get('itemID'));
    // simulate an AJAX call
    await new Promise((resolve) => setTimeout(resolve, 1000));
    setCart((cart: Item[]) => [...cart, { id, title }]);

    return { id };
  };

  return (
    <>
      <Cart cart={optimisticCart} />
      <AddToCartForm
        id="1"
        title="JavaScript: The Definitive Guide"
        addToCart={addToCart}
        optimisticAddToCart={optimisticAddToCart}
      />
      <AddToCartForm
        id="2"
        title="JavaScript: The Good Parts"
        addToCart={addToCart}
        optimisticAddToCart={optimisticAddToCart}
      />
    </>
  );
};

UI를 최적으로 업데이트하는 것은 웹 앱의 유저 경험을 향상시키는 좋은 방법이다. 이 훅은 이 사용 사례에 많은 도움이 된다. useOptimistic에 대한 자세한 내용은 React 문서에서 읽을 수 있다.

보너스: 비동기 전환

React의 Transition API는 UI 차단없이 상태를 업데이트할 수 있게 한다. 예를 들어, 사용자가 마음을 바꿀 경우 이전 상태 변경을 취소할 수 있다.

이 아이디어는 startTransition를 호출해 상태 변화를 감싼다.

function TabContainer() {
    const [isPending, startTransition] = useTransition();
    const [tab, setTab] = useState('about');

    function selectTab(nextTab) {
        // instead of setTab(nextTab), put the state change in a transition
        startTransition(() => {
            setTab(nextTab);
        });
    }
    // ...
}

다음 예는 이 Transition API를 사용한 탭 네비게이션을 보여준다. "Posts"을 클릭한 다음 즉시 "Contact"를 클릭한다. 이로 인해 "Posts"의 느린 렌더링이 중단된다. "Contact" 탭이 즉시 표시된다. 이 상태 업데이트는 트랜지션으로 표시되기 때문에 느린 리렌더(re-render)는 사용자 인터페이스를 통제하지 않는다.

import { useState, useTransition } from 'react';
import TabButton from './TabButton';
import AboutTab from './AboutTab';
import PostsTab from './PostsTab';
import ContactTab from './ContactTab';

export function App() {
  const [isPending, startTransition] = useTransition();
  const [tab, setTab] = useState('about');

  function selectTab(nextTab) {
    startTransition(() => {
      setTab(nextTab);
    });
  }

  return (
    <>
      <TabButton isActive={tab === 'about'} onClick={() => selectTab('about')}>
        About
      </TabButton>
      <TabButton isActive={tab === 'posts'} onClick={() => selectTab('posts')}>
        Posts (slow)
      </TabButton>
      <TabButton
        isActive={tab === 'contact'}
        onClick={() => selectTab('contact')}
      >
        Contact
      </TabButton>
      <hr />
      {tab === 'about' && <AboutTab />}
      {tab === 'posts' && <PostsTab />}
      {tab === 'contact' && <ContactTab />}
    </>
  );
}

React 18.2에서는 Transition 훅을 사용할 수 있다. React 19의 새로운 점은 이제 비동기 기능을 지나 Transition을 시작할 수 있으며, React는 Transition을 시작하기를 기다리고 있다.

이는 AJAX 호출을 통해 데이터를 제출하고 그 결과를 트랜지션으로 렌더링하는 데 유용하다. 트랜지션의 pending 상태는 비동기 데이터 제출과 함께 시작된다. 이는 위에서 설명한 폼 actions 기능에서 이미 사용되고 있다. React가 startTransition으로 감싸진 <form action> 핸들러를 호출하여 현재 페이지를 차단하지 않는다.

이 기능은 아직 React 설명서에 문서화되어 있지 않지만 pull request에서 이 기능에 대한 자세한 내용을 읽을 수 있다.

결론

이러한 모든 기능들은 클라이언트 전용인 리액트 앱에서 작동하며, Vite와 함께 번들된 앱에서 작동한다. 비록 서버 통합형 리액트 앱에서도 이것이 작동하지만 이것을 사용하기 위해 Next 혹은 Remix와 같은 SSR 프레임워크를 사용할 필요는 없다. 

이러한 기능을 통해 리액트에서 데이터 패칭과 폼을 구현하기가 훨씬 쉬워진다. 하지만 훌륭한 유저 경험을 만들려면 이 모든 훅를 통합해야 하는데, 이는 복잡할 수 있다. 또는 최적의 빌트인 업데이트를 지원하는 사용자 친화적인 폼을 가진 react-admin과 같은 프레임워크를 사용할 수 있다.

이 기능들은 왜 React 18.3이 아닌 React 19에 도입되는 것일까? 이 기능들에는 약간의 변경 사항이 포함되어 있기 때문에 18.3 release에는 없을 것으로 보인다.

React 19는 언제 올 것인가 ? 아직 ETA는 없지만 이 게시물에 언급된 모든 기능은 이미 작동하고 있다. 하지만 아직 사용하는 것을 추천하고 싶지는 않다. (Next.js가 그렇게 한다고 해도) canary release를 프로덕트에 사용하는 것은 좋은 생각이 아니다.

리액트 코어 팀이 SSR 앱에서 일하는 사람들뿐만 아니라 모든 리액트 개발자들의 개발자 경험을 개선하기 위해 노력하고 있다는 것은 정말 기쁜 일이다. 또한 그들은 커뮤니티 피드백에 귀를 기울이고 있는 것 같다 - 데이터 패칭 및 폼 핸들링은 매우 흔한 문제이다.

나는 React의 Stable 릴리즈에 이 기능들이 보이길 기대한다!

원문:  https://dev.to/reenatoteixeira/everything-that-you-need-to-know-about-git-2440

 
 
나는 당신이 변경 사항을 되돌리고 손실된 데이터를 복구할 수 있도록 코드 버전의 중요성을 생각할 것이라고 확신한다. 창의적인 이름으로 파일 복사본을 만들어 가며 버전 관리를 하는 누군가(저는 아님)를 알 거라고 생각한다..
 

 
이것은 아마도 1972년 이전에 처음으로 중앙 집중식 버전 제어 소프트웨어 중 하나인 SCCS(Source Code Control System)가 출시되면서 누구나 자신의 코드로 버전 제어를 할 수 있는 방법이었을 것이다. 
 
그러나 우리는 여기서 SCSS를 얘기하려는 것이 아니라, 우리가 가장 관심있어 하는 것은 내년(07/04/2005)에 20주년을 맞는 분산형 오픈소스 버전 제어 소프트웨어인 GIT이다. 
 

목차

• 1. What's GIT?
• 2. How does GIT work?
• 3. Installing GIT
• 4. Configuring GIT
• 5. Starting a local repository
• 6. Working with GIT
• 7. Knowing branches
• 8. Syncing with the remote repository
• 9. Conclusion
• 10. References

1. GIT이란 무엇인가?

GIT은 리눅스 커널 제작자인 Linus Torvald이 개발한 2005년에 출시된 분산형 오픈소스 버전 관리 시스템이다. 
 
GIT을 통해 우리는 프로젝트의 버전을 전역적으로 관리할 수 있고(작업하는 폴더에서) 모든 변경사항을 리모트 레포지토리와 싱크를 맞출 수 있다(예를 들어 GitHub에서). 

2. GIT은 어떻게  작동할까?

모든 프로젝트 파일이 있는 폴더가 있는 물리적인 파일 캐비닛을 상상해보라. 누군가 파일을 조작하려고 할 때마다, 그들은 그것을 골라야 하고 폴더에서 그것을 지우고 끝난 후에는 다시 폴더에 되돌려 놓아야 한다. 따라서 두 사람이 동일한 파일을 작업하는 것은 불가능하여 발생 가능한 충돌을 완전히 피할 수 있다.
 

그러나 이것이 GIT이 작동하는 방식은 아니다! (thanks God)

이것은 중앙 집중된 버전 컨트롤 시스템이 작동되는 방식으로, 사용자는 파일을 'check-out(체크아웃)'하고 'check-in(체크인)'해야 한다. 특정 파일에 대한 작업이 필요할 때마다 해당 파일을 체크아웃하여 저장소에서 제거한 다음 작업이 완료되면 파일을 체크인하여 저장소로 반환해야 한다.

 
GIT같은 분산형 시스템에서는 같은 레포지토리의 파일에 여러 사람들이 동시에 파일에 접근하는 것이 가능하다. 누군가 파일을 조작할 때마다 파일을 로컬로 복제(또는 전체 레포지토리를 복제)한 다음 수정사항을 원격 레포지토리로 다시 보낼 수 있다. 이를 통해 여러 사람이 동일한 파일을 조작하면서 동일한 프로젝트에서 작업할 수 있다.

이것은 세계 여러 지역의 사람들이 같은 프로젝트에서 작업하고 수정 및 발생 가능한 충돌을 관리하는 대규모 오픈 소스 프로젝트의 배포를 허용한다(여기서 병합 충돌(merge conflicts)이 발생할 수 있다).

3. GIT 설치하기

GIT은 매우 간단한 설치 프로세스를 통해 주요 운영 체제(Windows, Linux, MacOs...)에서 사용할 수 있으며, 이는 명령줄이나 git-scm.com 의 공식 설치 프로그램을 통해 설치가 가능하다.

3.1 윈도우에서 설치하기

윈도우에 GIT를 설치하려면 공식 웹사이트에 들어가서 설치 프로그램을 다운로드하기만 하면 된다. 그리고 나서 지시사항을 따라가면 모든 것이 잘 될 것이다. 그리고 우리는 터미널에서 GIT 명령을 사용할 수 있을 것이다.

3.2 리눅스에서 설치하기

리눅스의 경우는 아래 명령을 사용해 GIT를 설치할 수 있다:

sudo apt install git-all

이 명령어를 통해 GIT이 우리의 터미널에서 실행될 준비를 해야 한다.

3.3 Mac에서 설치하기

Mac의 경우 GIT를 설치하는 가장 쉬운 방법은 Homebrew를 설치한 다음 터미널에서 아래 명령을 실행하는 것이다:
 

brew install git

 
이 명령어를 통해 GIT이 우리의 터미널에서 실행될 준비를 해야 한다.

4. GIT 구성하기

 
설치한 후에는 아래 실행을 통해 GIT을 구성하는 것이 중요하다:

git config --global user.name "[username]"
# e.g. John Doe

git config --global user. email "[email@email.com]"
# e.g. johndoe@email.com

또한 --global 태그를 제거하여 특정 로컬 리포지토리에 대한 특정 사용자를 구성할 수도 있다.

 5. 로컬 레포지토리 시작하기

 
GIT이 구성되면 로컬 저장소를 시작할 수 있다. 이를 위해 새 저장소를 처음부터 시작하거나 기존 원격 저장소를 복제할 수 있다.

5.1 처음부터 시작하기(git init)

새 레포지토리를 시작하려면 원하는 레포지토리 루트 폴더로 이동하고 아래 명령을 실행하기만 하면 된다.

git init

이를 통해 프로젝트 폴더에  .git 디렉토리가 생성되며, 이 디렉토리는 로컬 저장소의 작업 폴더의 버전 컨트롤을 담당한다. 

5.2 기존 레포지토리 복제하기(git clone)

기존 원격 저장소를 복제하는 것은 새 저장소를 처음부터 시작하는 것만큼 쉽다. 이를 위해 우리는 레포지토리를 다운로드 하고 싶은 곳에 리모트 저장소의 URL과 함께 git clone 명령어를 사용한다.

git clone [repository-url]

그리고 나면 전체 레포지토리가 우리의 로컬 저장소에 복제될 것이고 자동으로 연관된 원경 저장소와 연결될 것이다.

레포지토리 복제는 우리가 더이상 git remote 명령어를 미래에 사용할 필요가 없다는 것을 뜻한다.

6. GIT으로 작업하기

우리의 로컬 저장소에서 우리는 우리 프로젝트에 필요한 파일을 만들 수 있지만 그 파일들이 자동으로 GIT에 의해 동기화되지는 않을 것이다. 우리는 버전 변경 사항이 생길 경우 GIT에 보고해야 한다.

그러므로 우리는 우리가 원하는 대로 파일을 조작하고 변경 사항을 수정한 후에는 깃에 수정된 파일을 보낸다.

이를 위해 버전 컨트롤에 3단계의 무한 플로우가 있다는 것을 이해하는 것이 중요하다.

 MODIFY -> STAGE -> COMMIT

• MODIFY(수정 단계): 버전 컨트롤의 첫 번째 작업은 MODIFY이다. 여기서는 사용 가능한 마지막 버전과 비교하여 변경된 파일을 찾는다.
• STAGE(스테이지 단계): 두 번째 stage 단계에서는 우리가 다음 커밋에 추가하고 싶은 파일을 수정된 파일에 위치 시킨다.
• COMMIT(커밋 단계): 마지막 단계인 commit 단계에서는 우리가 변경 사항을 확인할 때 스테이지의 수정된 파일을 로컬 저장소에 보낸다.

수정된 파일들을 커밋한 후에는 로컬 저장소에서 새로운 버전을 가지게 되며, 다시 업데이트 사항들을 받고 한 번 더 '수정'하고 '스테이지'에 위치시키고 다시 '커밋'할 수 있으며 새로운 버전을 확인하는 등의 작업을 수행할 수 있다. (그래서 '무한' 플로우라고 한 것 ㅎㅎ)

커밋은 수정된 파일의 이전 버전을 덮어쓰지 않으며, 마지막 버전에 대한 포인터가 있는 새 버전을 포함하므로 GIT에 의해 트래킹되는 각 파일의 버전을 추적하는 것이 중요하다.

6.1 추가하고 커밋하기(git add와 git commit)

복잡하게 들릴지 모르지만, 버전 제어 흐름을 수행하는 것은 매우 간단하다다. 원하는 수정이 완료되었으므로, 우리는 아래 명령으로 커밋하고자 하는 단계에 수정된 파일을 추가한다:

git add [filename]

git add -A : 모든 수정된 파일을 스테이지에 한 번에 추가
git add *. [extensão-do-arquivo] : 특정 익스텐션 파일의 수정된 파일을 스테이지에 한 번에 추가 (git add *.html 과 같이)

우리는 git status 명령을 사용하여 언제든지 현재 로컬 저장소 상태를 확인할 수 있다:

새 파일을 만든 후 저장소 내에서 git status를 실행하면 새 파일이 "Untracked(추적되지 않음)"으로 표시된다. 즉, 이 파일은 새로운 것이며 GIT에 의해 추적되기 위해서는 어떤 커밋에라도 추가되어야 한다는 것을 의미한다.

GIT가 저장소 내의 특정 파일이나 폴더를 무시하도록 할 수 있다. 이를 위해서는 루트 폴더에 .gitignore라는 파일을 추가하고, 그 안에서 무시해야 할 파일이나 폴더의 이름을 적으면 된다.

주의: 무시된 파일과 폴더는 더 이상 GIT 트랙에 나타나지 않으며, 심지어 "Untracked"로도 표시되지 않는다. 추적을 재설정하려면 .gitignore 파일에서 원하는 이름을 삭제하기만 하면 된다.

파일을 포함하기 위해 git add 명령을 추가할 파일의 이름("index.html")으로 실행할 수 있다:

이러한 방식으로 git status 다시 실행하면 새 파일이 "stage"에 추가되었으며 최종적으로 다음 커밋에서 보낼 준비가 되었음을 알 수 있고, 이는 아래 명령을 통해 수행할 수 있다:

git commit -m "[descriptive-message]"

커밋은 고유 ID(해시 코드)를 가지며, 변경할 수 없다. 즉, 커밋은 확인되면 수정할 수 없다.

git commit -a: 직접 커밋을 수행하며 모든 수정된 파일을 스테이지에 추가하고 커밋한다.

파일을 성공적으로 커밋한 후 git status를 실행할 때 마지막 커밋을 통해 모든 수정 사항이 로컬 저장소에 효과적으로 저장되었기 때문에 더 이상 업로드할 수정된 파일이 없음을 알 수 있다.

또한 해시 코드, 브랜치, 작성자, 날짜 등 모든 커밋의 일부 메타데이터를 보여주는 git log 명령을 사용해 저장소의 커밋 로그를 검토해 변경한 내용을 확인할 수 있다.

이 모든 과정을 반복하여 프로젝트에 필요한 새 파일을 추가하고 수정한 후 새로운 커밋을 만들어 로컬 저장소로 보낼 수 있다.

git log -N : 마지막 N개의 커밋이 포함된 log를 보여준다.
git log [branch-A] [branch-B]: "branch-B"에는 있지만 "A"에는 없는 커밋 로그를 표시한다.
git log --follow [filename]: 파일의 이름을 변경한 경우에도 지정한 파일을 변경한 커밋 로그를 표시한다.
git diff: 저장소에서 사용 가능한 최신 버전과 비교하여 변경한 내용을 나열한다.
git diff [nome-do-arquivo]: 저장소에서 마지막으로 사용 가능한 버전과 관련하여 지정된 파일에 대해 수행한 변경 사항을 나열한다.

6.2 커밋 전과 후에서 변경 사항 취소하기

커밋이 이루어지기 전에 로컬 저장소에서 이루어진 모든 변경은 취소하거나 변경할 수 있지만, 커밋이 한 번 이루어지면 변경할 수 없다. 커밋은 불변의 객체이기 때문에 커밋에서 데이터를 편집하거나 변경하는 것은 불가능하다.

그러나 변경을 취소하는 새로운 커밋을 만들거나 이전 커밋에서 잘못된 정보를 수정할 수 있다. 어느 쪽이든 우리는 다음 명령 중 하나를 사용할 수 있다:

git checkout -- [filename]
# 커밋 전에 로컬 파일에 대한 변경 사항을 폐기(돌이킬 수 없는 작업)

git reset --hard HEAD
# 스테이지 단계(커밋 전)에 있는 파일의 변경 내용을 폐기

git reset --hard HEAD~1
# 로컬 리포지토리에서 수행한 마지막 커밋을 폐기(마지막 커밋만 해당)

git commit --amend
# 로컬 저장소에서 수행한 마지막 커밋을 대체하여 새 커밋을 작성

git revert [commit-hash]
# 지정한 커밋의 변경사항을 되돌리는 새 커밋을 작성

7. 브랜치에 대해 알아보기

브랜치는 저장소의 가지치기(ramification)에 지나지 않으며, 지금까지 모든 작업은 브랜치 'master/main'에서 수행되었다. 

기본적으로 레포지토리에 생성된 첫 번째 브랜치는 레포지토리의 메인 브랜치인 master/main 이다.

7.1 왜 브랜치를 사용하는가?

처음에는 별것 아닌 것처럼 보일 수 있지만 브랜치는 프로젝트 개발에 막대한 파워를 가지고 있다.

우리가 웹 플랫폼을 개발하고 있고, 새로운 기능을 테스트하고 싶지만, 우리의 저장소는 이미 호스트되었거나 다른 사람들과 공유하고 있고, 어떤 문제가 있는 변경들이 그것들에게 나쁜 경험을 야기할 수 있다고 생각해보라. 이 상황에서 우리는 무엇을 할 수 있을까?

프로젝트 폴더를 복사하여 붙여넣고 새로운 "테스트 버전"을 만드는 것에 대해 생각해본 적이 있다면, 맞는 말이다! 음, 거의...

GIT를 사용하면, 우리는 브랜치들로 비슷한 일을 할 수 있다. 브랜치이기 때문에, 우리는 단순히 "테스트"라고 불리는 새로운 브랜치를 만들 수 있다. 따라서 우리 프로젝트의 버전을 완전히 고립된 브랜치에서, main 브랜치에 영향을 주지 않고 바꿀 준비를 한다.

7.2 브랜치 만들기 (git branch)

브랜치를 만드는 것은 master/main 브랜치에 영향을 주지 않고 독립적으로 작업할 수 있는 저장소의 병렬 복사본을 만드는 것을 의미한다. 이를 위해서 우리는 단순히 아래의 명령어를 실행하면 된다:

git branch [branch-name]

특정 브랜치의 이름 없이 git branch 명령을 실행하려면 저장소에 사용 가능한 브랜치 목록을 표시하며, "*"의 표시는 현재 사용 중인 브랜치를 나타낸다.

git branch test 명령을 실행하기 전에 git branch 명령은 master 브랜치만 반환한다.

git checkout [branch-name]

git checkout test 명령을 실행한 후 활성 브랜치가 전환되는 것을 확인할 수 있다. 그 순간부터 모든 커밋된 정보는 브랜치 master/main 에 영향을 주지 않고 저장소의 test 브랜치로 전송된다.

필요한 만큼의 브랜치를 생성할 수 있으며, 아래 명령을 사용하여 기존 브랜치와 상호 작용할 수 있다:

git checkout -b [branch-name]
 -> 지정된 이름으로 새 브랜치를 만들고 직접 그 브랜치로 전환한다.
git branch -d [branch-name] -> 지정한 branch를 삭제한다.
git branch -m [new-name] -> 현재 branch의 이름을 지정된 이름으로 변경한다.

7.3 브랜치 병합하기(git merge)

다른 브랜치 작업을 완료하고 변경한 내용이 프로젝트에 문제를 일으키지 않았다고 확신한다면, 현재 브랜치의 모든 변경 사항을 적용하여 master/main 브랜치로 병합할 수 있다. 

브랜치를 병합하려면 변경 사항을 받을 브랜치로 전환하고 다음 명령을 실행해야 한다.

git merge [branch-name]
# 지정된 브랜치를 현재 활성된 브랜치로 병합

여기서 우리는 branch 'test'에 있기 때문에 git checkout 명령어를 통해 master 브랜치로 전환해야 하며 git merge 명령어를 병합하고 싶은 브랜치 이름과 함께 실행해야 한다. (여기서는 'test')

이렇게 하면 test 브랜치에서 수행된 모든 작업(이 경우 style.css 파일 작성)이 master 브랜치에 병합된다.

7.4 병합 충돌

서로 다른 브랜치를 깃 머지(git merge)로 병합할 때 동일한 행에서 하나 이상의 파일이 변경되어 병합을 자동으로 수행할 수 없는 경우에서 일부 충돌이 발생할 수 있다.

이렇게 되면 git status 명령을 실행하여 어떤 파일이 충돌하는지 확인할 수 있다.

우리는 병합을 진행하기 전에 어떤 변경 사항이 발생해야 하는지 정의하거나 변경 사항을 검토하여 상호 호환되도록 충돌을 해결해야 한다. 이를 위해 GIT는 충돌하는 파일에 마커를 삽입하여 해결을 돕는다.

충돌을 해결한 후 수정된 파일을 다시 스테이지에 올려놓고 새로운 충돌 없는 버전을 커밋하고 git merge 명령을 다시 실행하면 문제 없이 성공적으로 병합할 수 있다.

8. 원격 저장소와 동기화

우리는 이미 로컬 저장소를 원격 저장소에 연결하고 모든 작업을 원격으로 동기화하여 최신 상태로 유지하는 것이 가능하다는 것을 알고 있다.

이를 위해 git push 명령어를 실행해 로컬 저장소로부터 모든 커밋을 원경 저장소로 보내야 한다. 그러나 먼저 원격 저장소를 구성해야 한다.

8.1 원격 저장소 구성하기

원격 저장소를 구성하는 것은 매우 간단하다. 우리는 이를 위해 Github를 사용할 것이다.

먼저 GitHub 계정에서 빈 저장소를 새로 시작해야 한다(이름을 선택하고 "Creating repository"를 클릭하기만 하면 된다) :

다음으로 원격 저장소와 로컬 저장소와의 관계를 다음 명령어를 우리의 로컬 저장소에서 실행해 구성해야 한다.

git remote add origin [remote-repository-url]

git remote -v : 로컬 저장소에 연결되어 있는 원격 저장소의 URL을 보여준다.

원격 저장소가 적절하게 연결되었다면, 우리는 우리의 로컬 브랜치 master/main의 이름을 git branch -m main 명령어를 통해  main으로 바꿔야 한다(당신의 로컬 브랜치가 이미 main으로 불리고 있다면 이 단계를 무시하라).

우리가 push 하는 로컬 저장소의 메인 브랜치를 원격 저장소의 메인 브랜치와 동일한 이름으로 유지하는 것이 중요하다.

마지막으로 위의 단계를 완료한 후 다음 명령을 사용하여 로컬 저장소를 처음으로 원격 저장소와 동기화할 수 있다:

git push -u origin main

git push-u origin main 명령을 실행할 때 GitHub credentials(사용자 및 액세스 토큰)을 입력해야 할 수도 있다.

만약 Github 액세스 토큰이 무엇인지 모른다거나 하나의 액세스 토큰을 설정하지 않았다면 여기를 클릭하라.

GitHub CLI를 사용해 인증을 구성함으로써 이 문제를 해결할 수도 있다. 여기를 클릭하여 방법을 알아보세요.

인증(Authenticating)을 한 후에는 git push 실행이 성공적으로 되어야 하고 로컬 저장소의 모든 커밋이 원격 저장소와 동기화된다.

8.2  처음 이후 Git push (git push)

위의 모든 단계를 거친 후에는 아래와 같이 별도의 파라미터 없이 git push 명령만으로 새로운 동기화를 할 수 있다.

이 경우 github CLI를 이용하여 git push 명령 실행에 필요한 인증을 건너뛰었다. 여기를 클릭하면 방법을 알 수 있다.

8.3  로컬 저장소 업데이트하기 (git pull)

분산된 원격 저장소를 사용하면 원격으로 변경할 수 있으므로 (원격 저장소에서 직접) 로컬 저장소가 오래된 상태일 수 있다.

이를 고려할 때, 로컬 저장소를 업데이트하고 원격 저장소에서 변경한 내용을 동기화하는 것이 매우 중요하며 로컬 프로젝트를 항상 원격 저장소에서 사용할 수 있는 최신 버전으로 유지해야 한다. 이 작업을 수행하기 위해 다음 명령을 실행한다:

git pull

새로운 README.md 파일이 우리의 원격 저장소에 직접 생성되어 우리의 로컬 저장소가 업데이트되지 않았다고 생각해보라.

위에서 언급한 것처럼 git pull을 사용하여 원격 저장소로부터의 변경 사항을 로컬 저장소 내에서 동기화할 수 있다. 

처음 7개의 행이 git pull 명령을 실행할 때 git fetch 명령의 return 값이다. 즉, git fetch 명령을 먼저 실행하지 않고 git pull 명령을 실행하면 GIT는 둘 다 함께 실행해 원격 저장소에서 업데이트를 찾아 로컬 저장소에 동기화한다.

git fetch -> 원격 저장소에서 업데이트를 가져오지만 로컬 저장소를 동기화하지는 않습니다(git pull이 필요함).

9. 결론

여태까지의 모든 것은 GIT이 프로그래머의 일상생활에서 필요한 버전 제어 시스템이라는 확신을 갖게 하며, GIT의 주요 명령과 사용법을 아는 것이 우리의 기술적 연공서열의 전환점이 될 수 있다는 점이다. 마지막으로, 로컬 및 원격 저장소를 동기화하고 업데이트하며 지금까지 배운 모든 것을 바탕으로 이 놀라운 버전 제어 시스템의 실용성을 계속 발전시킬 준비가 되어 있다.

10. 참조

• GIT's official documentation.
• [PT-BR] GIT: Mini course to get you started (learn in 45 minutes) - Codigo Fonte TV

https://web.dev/articles/dom-size-and-interactivity

🗣️ 크기가 큰 돔은 우리가 생각하는 것보다 상호적으로 영향을 끼칠 가능성이 높다. 이 가이드는 그 이유에 대해 설명하고 이에 대해 우리가 취할 수 있는 행동에 대해 설명한다.

웹 페이지를 만들 때 페이지에 DOM(Document object model)이 있다는 점은 명백한 사실이다.

DOM은 페이지의 HTML 구조를 나타내고 페이지의 구조와 내용에 접근하도록 자바스크립트와 CSS를 보낸다.

그러나 문제는 DOM의 사이즈가 브라우저가 페이지를 빠르고 효율적으로 렌더링하는데에 영향을 준다는 점이다.
일반적으로 DOM이 클수록 처음에 해당 페이지를 렌더링하고 나중에 페이지 라이프사이클에서 렌더링을 업데이트하는데에 더 많은 비용이 든다.

이는 DOM을 수정하고 업데이트하는 상호 작용이 많은 페이지에서 빠른 응답에서 미치는 영향이 많은 레이아웃 작업을 다룰 때 큰 DOM이 문제가 된다.

비용이 많이 드는 레이아웃 작업은 페이지의 INP(Interaction to Next Page)에 영향을 미친다. 만약 페이지가 유저 상호작용에 빠르게 반응하도록 하려면 DOM의 크기를 필요한 만큼만 유지하는 것이 중요하다.

◾️ 언제 페이지의 DOM의 크기가 커질까?

A: 핵심 용어: DOM 요소와 DOM 노드의 차이점을 아는 것은 중요하다. DOM 요소는 DOM 트리의 특정 HTML 요소를 나타낸다. 그리고 DOM 노드는 DOM 요소의 용어와 중복되는 의미를 갖지만 그것의 정의는 주석, 공백 및 텍스트로 확장된다. Lighthouse의 DOM 크기 측정은 DOM 노드를 참조하지만 이 가이드에서는 가능할 때마다 DOM 노드보다 DOM 요소를 참조할 것이다.

Lighthouse에 따르면 페이지의 DOM사이즈가 1,400 노드를 넘을때 과도하다고 본다. Lighthouse는 DOM이 800노드를 넘으면 경고를 보내기 시작한다.

다음 HTML을 예로 들어 보겠다:

<ul>
  <li>List item one.</li>
  <li>List item two.</li>
  <li>List item three.</li>
</ul>

위 코드에는 4개의 DOM 요소: <ul> 요소와 3개의 하위 요소 <li>가 있습니다. 당신의 웹 페이지에는 확실히 이보다 더 많은 노드가 있을 것이기 때문에 DOM 크기를 확인하기 위해 무엇을 할 수 있는지 이해하는 것이 중요합니다. 따라서 페이지의 DOM을 가능한 한 작게 만든 후 렌더링 작업을 최적화하기 위한 다른 전략뿐만 아니라 DOM 크기를 확인하기 위해 우리가 어떤 것을 할 수 있는지 이해하는 것이 중요하다.

◾️크기가 큰 DOM이 어떻게 페이지 성능에 영향을 미칠까?

큰 DOM은 다음과 같이 몇 가지 방식으로 페이지 성능에 영향을 미친다.
1. 페이지가 초기 렌더링되는 동안 CSS가 페이지에 적용되면 CSSOM(CSS 개체 모델)이라는 DOM과 유사한 구조가 생성된다. CSS 셀렉터의 구체성이 증가하면서 CSSOM은 더 복잡해지고 웹 페이지를 화면에 그리는 데에 필요한 레이아웃, 스타일링, 합치기 및 페인트 작업을 실행하는 데에 더 많은 시간이 필요하다. 이 추가 작업으로 인해 페이지 로드 중 초기에 발생하는 상호 작용에 대한 대기 시간이 늘어난다.

2. DOM을 수정하거나 요소 삽입 혹은 삭제 또는 DOM 내용과 스타일 수정과 같은 일이 일어나면 이 업데이트들을 렌더링하는 작업에 매우 많은 비용이 소요될 수 있다. CSS 셀렉터의 구체성 증가는 페이지의 초기 렌더링과 마찬가지로 HTML 요소가 상호작용의 결과로 DOM에 삽입될 때 렌더링 작업에 추가될 수 있다. 
 
3. JavaScript가 DOM을 쿼리할 때 DOM 요소에 대한 참조는 메모리에 저장된다. 예를 들어 document.querySelectorAll을 호출해 모든 <div>을 페이지에서 선택할 때,  많은 수의 DOM요소를 반환하면 메모리 비용이 상당할 수 있다.
 

 
모두 상호 작용에 영향을 미치지만 위 목록 중 두 번째 항목이 특히 중요하다. 상호작용들에 의해 DOM이 변경되면 페이지의 좋지 않은 INP에 기여할 수 있는 작업이 시작될 수도 있다.

◾️어떻게 DOM사이즈를 측정할까?

당신은 다양한 방법으로 DOM사이즈를 측정할 수 있다. 첫 번째 방법은 Lighthouse를 사용하는 방법이다. Lighthouse에서 검사를 실행하면 현재 페이지의 DOM에 대한 통계가 'Diagnostics' 제목 아래 'Avoid an excessive DOM size(과도한 DOM사이즈 피하기)' 항목에 표시된다. 이 부분에는 DOM 요소의 총 개수, 가장 많은 하위(children) 요소를 포함하는 DOM 요소 및 가장 깊은 DOM 요소 또한 볼 수 있다.

더 간단한 방법은 주요 브라우저의 개발자 도구에서 JavaScript 콘솔을 사용하는 것이다. DOM의 총 HTML 요소의 개수를 얻으려면 페이지가 로드된 후 콘솔에서 다음 코드를 실행한다:

  document.querySelectorAll('*').length;
  

메모: 위의 코드에는 DOM의 HTML 요소의 개수만 포함되어 있다. DOM의 모든 노드를 포함하지는 않는다.

DOM 크기 업데이트를 실시간으로 확인하려면 성능 모니터 도구를 사용할 수도 있습니다. 이 도구를 사용하면 현재 DOM 크기와 함께 레이아웃 및 스타일 작업(기타 성능 측면)등을 연관시킬 수 있다.

 
DOM의 크기가 Lighthouse DOM 크기의 경고 값에 접근하거나 실패하는 경우, 다음 단계는 DOM의 크기를 줄여 웹 사이트의 INP가 향상될 수 있도록 사용자 상호 작용에 응답하는 페이지의 기능을 향상시키는 방법을 찾는 것입니다.

◾️어떻게 상호작용에 영향을 받는 DOM 요소의 개수를  측정할까?

실험실에서 만약 당신이 페이지 DOM의 크기과 관련된 것으로 의심되는 느린 상호작용을 수집하려 한다면, 당신은 "스타일 재계산(Recalculate Style"이라는 레이블이 지정된 프로파일러에서 활동을 선택하여 영향을 받은 DOM 요소의 개수를 파악하고 아래쪽 패널에서 컨텍스트 데이터를 관찰할 수 있습니다.
 

 
위 스크린샷에서 작업의 스타일 재계산(선택 시)에 영향을 받는 요소의 개수가 표시되는지 확인한다. 위 스크린샷은 많은 DOM 요소가 있는 페이지의 렌더링 작업에 DOM 크기가 미치는 영향의 극단적인 경우를 보여주지만, 이 정보는 어떤 경우에도 DOM 크기가 상호 작용에 응답하여 다음 프레임을 그리는 데 걸리는 시간에 한계 요소인지 판단하는 데에 유용하다.
 

◾️어떻게 DOM 사이즈를 줄일까?

불필요한 마크업을 위해 웹사이트의 HTML을 감사하는 것 외에도 DOM 크기를 줄이는 주요 방법은 DOM 깊이를 줄이는 것이다. DOM이 불필요하게 깊을 수 있다는 신호 중의 하나는 브라우저 개발자 도구의 요소 탭에서 다음과 같은 마크업이 보이는 신호이다.
 

    <div>
      <div>
        <div>
          <div>
            <!-- Contents -->
          </div>
        </div>
      </div>
    </div>

 
이와 같은 패턴을 보면 아마도 DOM 구조를 평평하게 하여 패턴을 단순화할 수 있다. 그렇게 하면 DOM 요소의 개수가 줄어들고 페이지 스타일을 단순화할 수 있는 기회가 주어진다.
 
DOM의 깊이는 사용하는 프레임워크의 증상일 수도 있다. 특히 JSX에 의존하는 것과 같은 구성 요소 기반 프레임워크에서는 상위 컨테이너에 여러 구성 요소를 중첩해야 한다.
 
그러나 많은 프레임워크에서는 fragment라고 알려진 것을 사용하여 nesting 구성 요소를 피할 수 있습니다. fragment를 기능으로 제공하는 구성 요소 기반 프레임워크에는 다음과 같은 것이 있다(그러나 이에 국한되지는 않다):
 

• React
• Preact
• Vue
• Svelte

선택한 프레임워크에 fragments을 사용하면 DOM 깊이를 줄일 수 있다. DOM 구조를 평평하게 만드는 것이 스타일링에 영향을 미치는 점이 걱정된다면 플렉스박스(flexbox) 또는 그리드(grid)와 같은 보다 현대적인(및 더 빠른) 레이아웃 모드를 사용하면 이점을 얻을 수 있을 것이다.

◾️기타 고려해야 할 전략

DOM 트리를 평평하게 하고 불필요한 HTML 요소를 제거하여 DOM을 최대한 작게 유지하더라도 사용자의 상호 작용에 따라서 변경될 수 있어 여전히 꽤 큰 렌더링 작업이 시작될 수 있다. 이러한 위치에 있다면 렌더링 작업을 제한하기 위해 고려할 수 있는 다른 전략이 있다.
 
- 추가적인 접근법
페이지가 처음 렌더링될 때 처음에 페이지의 많은 부분이 사용자에게 보이지 않는 위치에 있을 수 있다. 이는 시작 시 DOM의 해당 부분을 생략하여 HTML을 느리게 로드하지만, 사용자가 페이지에서 초기에 숨겨진 측면을 페이지에서 필요한 부분과 상호 작용할 때 추가될 수 있기도 하다.

이 접근 방식은 초기에 로드될 때와 아마도 이후에도 유용하다. 초기 페이지 로드의 경우, 더 적은 렌더링 작업을 앞에서 수행하게 된다. 즉, 초기 HTML 페이로드가 더 가벼워지고 더 빨리 렌더링된다. 이는 중요한 기간 동안 메인 스레드의 관심을 끌기 위해 경쟁을 덜 하면서 실행할 수 있는 더 많은 기회를 제공할 것이다.

만약 페이지 초기 로드시의 숨겨진 부분이 많다면 리렌더링 작업을 유발하는 다른 상호작용들의 속도를 높일 수 있다. 그러나 다른 상호 작용이 DOM에 추가됨에 따라 페이지 수명 주기 전반에 걸쳐 DOM이 증가하며 렌더링 작업이 증가한다.

시간이 지나면서 DOM을 추가하는 것은 까다로울 수 있으며 고유한 절충점이 있다. 이 경우에는 사용자 상호 작용에 대한 응답으로 페이지에 추가하려는 HTML을 채우기 위한 데이터를 얻기 위해 네트워크 요청을 할 가능성이 높다. 중간 네트워크 요청은 INP에 포함되지 않지만 인지된 지연 시간을 증가시킬 수 있다. 가능한 경우 로딩 스피너 또는 데이터를 가져오는 중임을 표시해 사용자가 무언가가 발생하고 있음을 알도록 한다.

◾️CSS 셀렉터의 복잡성 제한

브라우저가 CSS의 셀렉터를 파싱할 때 해당 셀렉터가 현재 레이아웃에 적용되는 방법과 적용되는 경우를 알려면 DOM 트리를 횡단해야 한다. 이러한 css 셀렉터들이 복잡할수록, 브라우저는 페이지의 초기 렌더링뿐만 아니라, 상호작용의 결과로 페이지가 변경되는 경우 스타일 재계산 및 레이아웃 작업을 증가시키기 위해 더 많은 작업을 수행해야 한다.

더 알아보기: 스타일 계산의 복잡성과 스코프 줄이기

◾️ content-visibility 프로퍼티를 사용하라

CSS는 화면 밖 DOM요소를 느긋하게 렌더링할 수 있는 효과적인 방법인 content-visibility 프로퍼티를 제공한다. 요소들이 뷰포트에 접근하면 필요에 따라 렌더링된다. content-visibility의 이점은 초기 페이지 렌더링시 상당한 양의 렌더링 작업을 줄여줄 뿐만 아니라 사용자의 상호작용으로 페이지 DOM이 변경될 때 오프스크린 요소 렌더링 작업을 생략할 수 있다는 것이다.

 더 알아보기: content-visibility: 렌더링 퍼포먼스를 올려주는 새로운 CSS 프로퍼티

🌟  결론

DOM 사이즈를 필요한것으로만 줄이는 것이 당신의 웹사이트의 INP를 최적화하는 좋은 방법이다. 이렇게 하면 DOM이 업데이트될 때 브라우저가 레이아웃 및 렌더링 작업을 수행하는 데 걸리는 시간을 줄일 수 있다. 당신이 DOM 크기를 의미 있게 줄일 수 없더라도 렌더링 작업을 DOM 하위 트리로 격리하는 데 사용하는 CSS containment 및 content-visibility 프로퍼티 같은 몇 가지 기술이 있다.

그러나 렌더링 작업을 최소화할 수 있는 환경을 만들고 페이지가 상호 작용에 반응해 수행하는 렌더링 작업의 양을 줄이면 웹 사이트가 사용자와 상호 작용할 때 더 잘 반응한다고 느낄 수 있다. 즉, 웹 사이트에 대한 INP가 낮아지고 사용자 경험이 향상된다.

🗣️ 이 글은 아래 글의 번역글입니다.

https://blog.logrocket.com/typescript-vs-flow-vs-proptypes/

자바스크립트는 변수의 데이터 타입이 런타임 환경에서 그 변수에 의해 결정되고, 프로그램을 통해 우리가 다른 값으로 그 변수에 할당할 경우에도 변할 수 있는 동적 타입 언어(Dynamically typed language)이다.

자바스크립트에는 변수의 타입을 제한하거나 주석 처리할 방법이 내장되어 있지 않다. 우리가 프로그램을 작성할때 변수가 가져야 하는 타입에 대해 고민을 많이 하는 것을 덜어주고 조금 더 빠르게 작성할 수 있게 해주지만, 이 말은 또한 우리의 프로그램이 버그를 갖거나 변수가 다른 타입이 되어 예기치 못한 행동을 유발할 수도 있다는 뜻이기도 하다.

자바스크립트의 이러한 동적 타이핑의 문제를 피하기 위해 우리는 프로그램을 다른 언어로 작성하고 자바스크립트로 트랜스파일 해야 한다. 이를 위해 변수를 엄격하게 확인하고 제어하는 자바스크립트의 타입 익스텐션이 필요하다.

여기 자바스크립트의 정적 타입 익스텐션을 제공하는 많은 언어들이 있다.

• Microsoft의 Typescript
• Facebook의 Flow
• Scala.js
• Kotlin
• Facbook의 Prop Types

이 글은 타입스크립트, Flow, Prop Types에 초점을 맞추고 이 언어들의 기능과 능력을 비교한다.

✣ Type-Checkiing 라이브러리 / 언어 비교하기

이 글에서는 이러한 자바스크립트 확장 라이브러리/언어의 기술과 능력을 비교하고 대조할 것이다.

유사점과 차이점을 탐색할 때 먼저 주목해야 할 중요한 차이점은 TypeScript와 달리 Flow 및 PropTypes는 프로그래밍 언어가 아니라는 것이다. Flow와 Prop Types는 오직 정적 타입 체킹 라이브러리이며 차이점은 해당 라이브러리의 사용을 지원하는 프레임워크에 영향을 미친다.

⚙️ 프로젝트에 타입스크립트 설치하기

타입스크립트는 이 글에서 비교한 세 가지 기술중 가장 많은 라이브러리를 제공하며 Vue, Angular 또는 React에서 즉시 타입스크립트를 사용하는 것이 쉽다.

예를 들어, 우리는 Typescript와 함께 Vue를 설치할때 Vue CLI에서 내장된 Typescript 옵션을 선택해 설치할 수 있다. Typescipt를 선택하면 우리는 tsconfig.json 파일(보통 브라우저의 최대 지원을 위해 ECMAScript 2009 설정)에서 Javascript로 트랜스파일하기 위한 구성을 할 수 있다.

    // tsconfig.json
    {
      "compilerOptions": {
        // Vue의 브라우저 지원을 위해
        "target": "es5",
        // 이를 통해 'this'에 대한 데이터 속성을 엄격하게 추론할 수 있음
        "strict": true,
        // webpack 2+ 또는 rollup을 사용하는 경우 트리 쉐이킹을 활용하려면 아래를 입력
        "module": "es2015",
        "moduleResolution": "node"
      }
    }

그리고 나서 컴포넌트 생성시 Vue를 참조하면 Typescript 타입 추론을 얻게 된다.

    
    import Vue from 'vue'

    const Component = Vue.extend({
      // ...
    })

또한 Vue를 사용하면 다음과 같이 클래스를 사용하여 고유한 특별한 방식으로 Typescript를 사용해 컴포넌트를 작성할 수 있다.

    
    <template>
      <button @click="onClick">Click!</button>
    </template>


    <script lang="ts">
        import * as Vue from "vue";
        import { Component } from "vue-property-decorator";

        @Component()
        class App extends Vue {
          public message: string = "Hello World";

          public onClick(): void {
            window.alert(this.message);
          }
        }

        export default App;
    </script>

여기서 일부 Typescript 어노테이션과 함께 Javascript 친화적인 구문을 볼 수 있다. 예를 들어 Angular는 Typescript와 함께 설치되고 Typescript를 거의 독점적으로 사용한다. 한때 Angular 앱을 순수 Javascript로 작성하는 옵션이 있었는데 인기를 끌지는 못했다.

⚙️ 프로젝트에 Flow 설치하기

반면에, Babel 구성에 Flow 지원을 활성화해 프로젝트에 Flow를 추가할 수도 있다.

Flow를 추가하기 위해 아래 명령어를 실행한다.

npm install --save-dev @babel/preset-flow

그리고 .babelrc에 다음 코드를 추가한다.

    {
      "presets": ["@babel/preset-flow"]
    }

⚙️ 프로젝트에 PropTypes 설치하기

프로젝트에 PropTypes를 추가하기 위해 PropTypes 라이브러리를 추가하고, 컴포넌트의 prop types를 정의하고 PropTypes.checkPropTypes을 호출한다.

Prop Types를 설치하기 위해 다음 명령어를 호출한다.

npm install --save prop-types

그리고 나서 컴포넌트의 prop type 유효성 검증을 정의하고 프로퍼티와 values 객체를 설정한다.

    
    const myPropTypes = {
      name: PropTypes.string,
      age: PropTypes.number,
      // ... prop types 검증을 정의한다
    };

    const props = {
      name: 'hello', // 유효
      age: 'world', // 유효하지 않음
    };

그리고 Prop Type을 체크한다.

   
   	// 'MyComponent' 컴포넌트로 정의한다

    // Works with standalone PropTypes
    PropTypes.checkPropTypes(myPropTypes, props, 'age', 'MyComponent');

    // 다음과 같은 에러를 반환한다
    // Warning: Failed prop type: Invalid prop `age` of type `string` supplied to
    // `MyComponent`, expected `number`.

타입 정의와 구문 체크

앞서 언급한 것처럼 세 가지 기술 모두 변수에 대한 타입 체크 및 제한을 제공하며 이것들을 비교해 보려 한다.

🛠️ Flow와 Typescript의 타입 정의

Flow와 Typescript는 상당히 유사한 타입 정의 구문을 갖고 있다.

공통점:

• 변수 타입 체크에 대한 Javascript 원시 타입과 파생(객체)된 타입을 제공
• 유사한 타입 어노테이션 구문을 가지고 있음
•  연산자와 다양한 유틸리티 타입을 사용하여 Javascript 타입 시스템의 유연성을 유지
• 선택적 프로퍼티에 대한 타입, 즉 Typescript는 nullable 타입이 있고 Flow에는 maybe 타입이 있음
• 변수 타입을 갖는 코드를 작성하는데 사용하는 제너릭이 있음

마지막 공통점의 예시는 아래에 있다.

function identity<T>(value: T): T {
    return value
}

제네릭은 다른 타입들로 덮어 씌여질 수 있는 변수 타입을 가진다 :

identity<string>('foo').

또한 다음 코드는 Typescript와 Flow에서 동일하다. 여기서 함수 concat은 문자 유형인 두 변수를 가지고 둘의 합을 반환한다.

    function concat(a: string, b: string) {
      return a + b;
    }

🛠️ PropTypes의 타입 유효성 검사기

반면에 PropTypes는 컴포넌트의 프로퍼티 설정을 위해 자체 타입 유효성 검사기를 사용한다. 즉, PropTypes에서는 PropTypes 객체를 사용해 타입을 정의한다.

    
    import React from 'react';
    import PropTypes from 'prop-types'

    class MyComponent extends React.Component {
      render() {
        // ... do things with the props
      }
    }

    MyComponent.propTypes = {
      optionalArray: PropTypes.array,
    ...

🛠️ 타입 캐스팅

Flow와 Typescript 모두 변수를 한 타입에서 다른 타입으로 명시적으로 캐스팅하는 기능을 제공한다.

Flow에서는 기호 : 를 사용해 캐스팅하고 Typescript에서는 as 키워드를 사용해 캐스팅한다.

    
    // TypeScript
    let value = 1 as number;

    // Flow
    let value = 1;
    (value: number);

PropTypes는 한 타입에서 다른 타입으로 명시적으로 캐스팅하는 기능을 제공하지 않는다.

🛠️ Interfaces, enums, 커스텀 타입

Interface는 객체의 구조와 프로퍼티를 제한하는 타입 정의이다. Enums는 열거된 값들이며 변수를 enum 값 중 하나로 제한해 타입으로 사용할 수 있다. Flow, TypeScript 및 PropTypes를 사용하면 커스텀 타입 제한을 할 수 있다.

Flow와 TypeScript는 interface 키워드를 사용해 커스텀 타입 객체를 정의한다. 모두 implements 키워드를 사용해 클래스가 인터페이스의 구조를 상속할 수 있게 한다.  아래 예시를 살펴보자.

    
    interface PersonInterface {
      firstName: string;
      lastName: string;
      fullName(firstName: string, lastName: string): string
    }

    class Person implements PersonInterface {
        firstName: string;
        lastName: string;
        constructor(firstName: string, lastName: string){
            this.firstName = firstName;
            this.lastName = lastName;
        }

        fullName(firstName: string, lastName: string): string {
            return `${firstName} ${lastName}`;
        }
    }

만약 인터페이스에 있는 모든 값을 구현하지 않으면 Flow와 Typescript는 에러를 반환할 것이다.

Flow와 Typescript 또한 타입 체킹을 위해 enum 키워드를 사용해  enum 리스트를 정의한다.

enum Status {
  Active,
  Paused,
  Off,
}

const status: Status = Status.Active //일치
const wrongStatus: Status = 'test' //불일치, 정의된 타입을 따르지 않음

한 가지 독특한 Flow의 특징은 타입 체킹 코드를 아래와 같이 주석에 쓴다는 점이다.

function greet(greeting /*: string*/) /* : string */ {
  return greeting;
}

타입스크립트에서는 이를 사용할 수 없다. 그러나 주석에는 자동완성 또는 구문 하이라이트 기능이 없기 때문에 이는 큰 장점이 아니다.

반면에 PropTypes은 아래와 같이 PropTypes.oneof를 사용해 enum 타이핑을 정의한다. 

...
optionalEnum: PropTypes.oneOf(['News', 'Photos']),
...

PropTypes는 또한 PropTypes.shape을 이용해 객체 타입 구조를 정의한다.

...
optionalObjectWithShape: PropTypes.shape({
    optionalProperty: PropTypes.string,
    requiredProperty: PropTypes.number.isRequired
}),
...

🔧 텍스트 에디터 지원

Flow와 Typescript 모두 Visual Studio Code와 Sublime과 같은 에디터가 지원하는 내장된 플러그인 지원을 가지고 있다.

Flow와 TypeScript에 대한 에디터 지원은 개발자가 다음과 같은 기능을 사용하는 것을 의미한다.

• IntelliSense (자동완성)
• Go to Definition(정의로 이동) / Peek Definition (정의 보기)
• Diagnostics(진단) (Errors, Warnings)
• 타입 정보 hover
• 전환 가능한 코드 적용 범위 리포트

Babel을 통해 기존 프로젝트에 Flow 설치를 지원하는 문서도 있습니다. Flow 지원 및 TypeScript 에디터 지원을 위한 에디터/IDE 설치에 대한 자세한 내용을 읽어보세요.

PropTypes 또한 할당된 값에 대해 컴포넌트의 prop types을 자동 생성해주는 Visual Studiio code 기능이 있다.

PropTypes에는 PropTypes.checkPropTypes를 호출하여 다른 라이브러리에 적용할 수도 있다(React에서는 자동으로 호출됨). PropTypes의 공식 문서에는 다른 라이브러리 지원에 대한 언급이 있지만, 이것이 다른 라이브러리에서 어떻게 작동하는지에 대한 외부 문서는 많지 않다.

🔧 효율성과 성능

Flow과 Typescript의 성능의 차이는 작다. TypeScript는 지속적으로 500-600MB의 RAM을 사용하며 Flow도 크게 다르지 않다. 컴퓨팅 자원의 효율성 측면에서는 둘 사이에 큰 차이가 없다.

PropTypes의 효율성? 이 Reddit 스레드에 따르면 TypeScript는 더 빠르고 버그가 적다. 

👥  커뮤니티 지원

TypeScript의 커뮤니티는 Flow 및 PropTypes과 비교하면 가장 크다. Flow와 PropTypes는 이전에 말했던 것처럼 공식 소스를 제외하면 문서가 적고 StackOverflow의 질문도 적다. 

Vue, Angular 및 React 같은 많은 프론트엔드 라이브러리, 프레임워크 및 플랫폼에는 TypeScript에 대한 지원이 내장되어 있다. Express와 같은 Node.js 웹 프레임워크에 TypeScript를 추가할 수 있으며 Nest.js는 TypeScript가 내장되어 있는 상태로 구축되어 프로젝트를 크게 변경하지 않고 TypeScript를 사용할 수 있다.

Express에서 TypeScript를 사용하려면 다음 명령을 실행하여 TypeScript 트랜스파일러를 설치하면 된다.

npm install --save-dev typescript

그런 다음 tsconfig.json 파일을 추가해 다음과 같이 작성하여 TypeScript 트랜스파일러를 구성할 수 있다.

{
    "compilerOptions": {
        "module": "commonjs",
        "esModuleInterop": true,
        "target": "es6",
        "noImplicitAny": true,
        "moduleResolution": "node",
        "sourceMap": true,
        "outDir": "dist",
        "baseUrl": ".",
        "paths": {
            "*": [
                "node_modules/*"
            ]
        }
    },
    "include": [
        "src/**/*"
    ]
}

Express 및 Node에 대한 타입 정의를 설치하려면 다음을 실행한다.

npm install --save-dev @types/node @types/express

보다시피, 많은 라이브러리와 프레임워크에 대해 TypeScript 타입 정의가 존재하기 때문에 기존 라이브러리에서 TypeScript를 사용하는 것이 그리 어렵지 않다. TypeScript에 대한 더 많은 타입 정의를 보려면 확실히 타입이 지정된 웹 사이트로 이동해 보면 된다.

📄 리소스와 문서

TypeScript는 사용 가능한 리소스 및 문서의 양 측면에서 확실히 다른 정적 타입 라이브러리보다 경쟁력이 있다.
TypeScript는 다음을 제공한다:

• Quick start guides (빠른 퀵 가이드)
• A detailed handbook (상세한 핸드북)
• Lots of sample code (많은 샘플 코드)
• A sandbox to experiment in (구현가능한 샌드박스 존재)

추가 이점으로 TypeScript의 플레이그라운드는 다양한 버전의 TypeScript를 지원하므로 다양한 버전의 TypeScript 트랜스파일러에서 코드가 어떻게 작동하는지 확인할 수 있다.

🔮 결론

TypeScript는 많은 라이브러리와 프레임워크에서 지원되므로 많은 사람들이 매일 TypeScript를 사용하고 있다. 많은 예제와 설명을 포함해 TypeScript의 각 기능에 대한 많은 정보가 있고, 정적 타이핑을 구현하는 데 가장 적합한 옵션일 가능성이 높다.

반면 Flow는 React로 Flow를 설정하는 방법에 대한 일부 문서와 짧은 문서만 있으며, 이는 다른 JavaScript 프레임워크에서 Flow를 설정하는 데에도 적용할 수 있다. 또한 지금까지 PropTypes은 세 가지 옵션 중 가장 드문 문서를 갖고 있지만 이런 게시물도 몇 개 있다.

🎧 마무리 노래 추천..

🏄‍♀️ input 태그로 파일을 업로드하거나 파일의 url을 가지고 있을 경우 파일의 확장자를 제대로 알 수 있는 방법에 대해 알아보자.

How to: 파일 업로드 후 e.target.files의 name을 활용

<input type="file" id="avatar" name="avatar" accept="*" />

위 파일 객체는 input태그를 통해 파일을 업로드 한 후 얻게 되는 값이다.

그 중 name값에는 파일의 이름이 존재하는데 이를 활용해 확장자 값을 구할 수 있다.

<input
    type="file"
    id="upload"
    onChange={(e) => {
      const files = e.target.files;
      const filename = files[0].name;
      const splitedNameArr = filename.split('.');
      const lastSplitedVal = splitedNameArr.at(-1);

      console.log(lastSplitedVal);
    }}
  />

파일 name에서 split을 통해 . 을 기준으로 나눈 뒤 마지막 . 뒤의 값을 확장자로 인식하는 방법을 활용했다.

이렇게 하면 파일 이름 사이에 . 이 존재하더라도 가장 마지막 . 뒤 값을 확장자로 볼 수 있다.

* Array.prototype.at() 기능이 너무 맘에 들어 링크 남긴다!

https://developer.mozilla.org/ko/docs/Web/JavaScript/Reference/Global_Objects/Array/at

출처: https://www.udemy.com/course/learn-flutter-dart-to-build-ios-android-apps/

📁 lib - main.dart를 가지고 있는 폴더, 가장 중요한 폴더. 가장 많은 시간을 보낼 폴더

📄 lib/main.dart - flutter 앱의 entry point 역할

🖇import ...; - Dart파일을 import하기 위한 방법

Flutter UI는 Widgets과 함께 빌드된다. Combining(결합) & Nesting(중첩) 을 통해.

📁 android,ios - flutter가 android,ios를 실행하기 위한 파일

📁 build - 빌드될 때마다 flutter가 알아서 변경해주는 빌드 폴더(건드릴 일이 없다)

📄 pubspec.yaml - 프로젝트의 dependencies와 이에 대한 메타데이터 정보, Flutter sdk 정보 등을 저장하는 공간 (font, image, image 파일들..)

📁 test - 실행하기 전 test파일을 통해 main.dart의 에러를 먼저 발견할 수 있게 해주는 폴더