Directory A directory, also known as a folder in some operating systems, is a file system structure used to organize and store files on a computer. It helps to manage files by grouping them into a hierarchical structure of directories and subdirectories.

In programming and scripting, "directory" is often abbreviated to "dir".

Repository In version control systems like Git, a repository is a location where files, including source code, are stored and managed. It not only houses the current version of every file but also maintains a history of all changes made to these files over time. This history is crucial for tracking modifications, collaborating on code, and reverting to previous versions if necessary.

Monorepo A monorepo, short for "monolithic repository", is a version control strategy in which many packages or modules are stored in a single repository. This approach stands in contrast to a multi-repo approach, where each package or module has its own separate repository.

Monorepos facilitate easier code sharing and collaboration across the different parts of a codebase, and are not limited to a specific package manager or programming language.

Multi-repo A multi-repo, short for "multi-repository" and also known as "polyrepo", is a version control strategy where each package or module has its own separate repository. This approach stands in contrast to a monorepo approach, where multiple packages or modules are stored in a single repository.

Workspace In JavaScript, a workspace refers to a specific entity in a repository that can be either be a single package or a collection of packages.

The package manager's root lockfile (i.e. pnpm-lock.yaml) is located at the workspace root, along with any additional configuration, such as the paths where packages are located when working in a multi-package workspace.

A workspace is often located at the root of a repository, but this is not a requirement. For example, some monorepos may have multiple workspaces, each located in a subdirectory of the repository.

Single-package workspace A workspace that represents a standalone package with a single package.json file at the workspace root.

Multi-package workspace A workspace that contains multiple packages.

A multi-package workspace contains multiple package.json files, including one at the workspace root for global configuration, and one in each package directory.

The configuration for these packages is stored at the root of the workspace. For pnpm, this configuration is in pnpm-workspace.yaml. npm and Yarn use the workspaces key in package.json.

This type of workspace is often associated with a monorepo.

Package A package is a collection of files and directories that are grouped together based on a common purpose. Types of packages include libraries, applications, services, and development tools.

Packages enable complex code bases to be decomposed into smaller, manageable, and independent components. This modular approach is essential to monorepos, a repository structure that houses multiple interconnected packages, facilitating streamlined management and development of large-scale projects.

In JavaScript, each package has a package.json file at its root, which contains metadata about the package, including its name, version, and any dependencies. Versioning of JavaScript packages generally follows semantic versioning, and JavaScript packages are often managed and distributed through npm.

reference: https://vercel.com/docs/glossary

필드에 입력하니까

아하

<TextInput
  value={education.grade}
/>  

이걸 빼니까 해결~

소셜 로그인 구현 방식에는 여러 가지 방법이 있지만, 프론트엔드 중심 처리 방식과 백엔드 중심 처리 방식 두 가지가 대표적입니다.

1️⃣ 기존 프로젝트 방식 (프론트엔드 중심)

✅ 과정:

1.    사용자가 프론트엔드에서 직접 카카오 로그인 URL로 이동 (window.location.href = kakao_auth_url)
2.    카카오가 리디렉트 URL을 통해 프론트엔드로 임시 코드(Authorization Code) 전달
3.    프론트엔드에서 받은 Authorization Code를 백엔드로 전송하여 액세스 토큰(JWT) 요청
4.    백엔드는 Authorization Code로 카카오 API에 요청 → 액세스 토큰 발급 → 사용자 정보 조회 후 자체 로그인 처리 및 JWT 발급
5.    프론트엔드는 받은 JWT를 로컬스토리지, 쿠키, Zustand 등의 상태 관리에 저장

✅ 📌 특징 • 프론트엔드에서 Authorization Code를 직접 백엔드로 보내서 로그인 요청을 수행 • 보안이 상대적으로 낮음 (클라이언트에서 Authorization Code를 직접 다루기 때문) • 구현 방식이 비교적 단순하며, 다양한 OAuth 제공업체와 쉽게 연동 가능

✅ 🔴 단점 • Authorization Code를 클라이언트가 다루기 때문에 악성 코드 공격에 취약 • 쿠키 기반 인증을 적용하기 어렵고, JWT를 로컬스토리지에 저장하면 XSS 취약점이 생길 수 있음

2️⃣ 최근 프로젝트 방식 (백엔드 중심)

✅ 과정:

1.    사용자가 프론트엔드에서 백엔드에서 제공하는 로그인 URL로 이동 (window.location.href = backend_auth_url)
2.    백엔드가 해당 요청을 카카오 OAuth 로그인 URL로 리디렉트
3.    사용자가 카카오 로그인을 완료하면 카카오가 백엔드로 Authorization Code를 전달
4.    백엔드가 Authorization Code를 사용해 카카오에서 액세스 토큰을 발급받고, 사용자 정보를 가져옴
5.    백엔드는 JWT를 생성하고, 프론트엔드로 리디렉트하면서 헤더에 JWT를 포함하여 전달
6.    프론트엔드는 백엔드에서 받은 JWT를 쿠키에 저장 (or 상태 관리)

✅ 📌 특징 • 프론트엔드는 OAuth 인증 과정에 직접 관여하지 않고, 백엔드가 모든 OAuth 인증을 처리 • 백엔드에서 JWT를 발급하고, 리디렉트 URL을 통해 응답 헤더에 JWT를 담아서 전달 • JWT를 쿠키(HttpOnly) 에 저장할 수 있어 보안성이 높아짐

✅ 🟢 장점 • Authorization Code를 프론트엔드에서 다루지 않음 → 보안성이 높아짐 • JWT를 쿠키(HttpOnly, Secure)로 관리 가능 → XSS 공격 방지 • API 요청마다 JWT를 Authorization 헤더로 보내는 방식보다 자동 로그인 유지에 유리

✅ 🔴 단점 • 로그인 과정이 더 복잡하고, 백엔드에서 OAuth 처리 부담이 증가 • 프론트엔드에서 JWT를 직접 다루지 않기 때문에, 상태 관리 라이브러리(Zustand 등)와의 연동이 어렵고, API 요청 시 인증이 자동으로 포함되지 않는 문제가 있을 수 있음.

3️⃣ 어느 방식이 더 흔한가?

📌 OAuth 로그인 방식 트렌드

방식 보안성 사용 사례 쿠키 기반 인증 가능 여부 프론트엔드 중심 낮음 (취약점 존재) 일반적인 OAuth 연동, SPA ❌ (JWT를 직접 저장해야 함) 백엔드 중심 높음 (Code 처리 없음) 보안이 중요한 서비스 (금융, 기업 내부 서비스) ✅ (HttpOnly 쿠키로 가능)

💡 최근에는 백엔드 중심 방식이 보편화되는 추세입니다. 특히, XSS / CSRF 방지를 위해 HttpOnly 쿠키를 사용하는 방식이 보안적으로 우수하기 때문입니다. 그래서 OAuth 인증 후 JWT를 헤더에 담아서 프론트엔드로 리디렉트하는 방식이 종종 사용됩니다.

4️⃣ 프론트엔드에서 JWT를 응답 헤더로 받아서 처리하는 방법

백엔드가 로그인 후 리디렉트 시 JWT를 응답 헤더에 포함하여 프론트엔드로 전달하면, 프론트엔드는 이를 쿠키에 저장해야 합니다.

useEffect(() => { fetch('/auth/callback/kakao', { credentials: 'include' }) // JWT 포함된 응답 받기 .then((response) => { const token = response.headers.get('Authorization'); // JWT 헤더에서 가져오기 if (token) { document.cookie = jwt=${token}; path=/; Secure; HttpOnly; // 쿠키에 저장 } }) .catch((err) => console.error(err)); }, []);

✅ credentials: 'include'를 사용하면 쿠키 기반 인증을 활용할 수 있음

5️⃣ 최종 결론

📌 프론트엔드 중심 방식 → 구현이 쉽지만 보안이 취약 📌 백엔드 중심 방식 → 보안성이 높고 JWT를 HttpOnly 쿠키에 저장 가능

최근에는 “백엔드 중심 OAuth 인증”이 더 선호되는 방식입니다.

특히, JWT를 응답 헤더에 담아서 리디렉트하는 방법은 보안성을 높이기 위한 설계이며, 금융 서비스나 보안이 중요한 서비스에서 자주 사용됩니다.

✅ 결론적으로, 이 방식이 흔한 방법인지? → 최근 보안 강화 트렌드에 따라 점점 더 많이 사용되는 방식이며, OAuth 로그인 후 JWT를 응답 헤더에 담아 리디렉트하는 방식도 꽤 일반적입니다. 🚀

• 컴포넌트 내부의 불필요한 연산 방지
• 컴포넌트 내부의 불필요한 함수 재생성 방지
• 컴포넌트의 불필요한 리렌더링 방지

• useMemo
• memo
• useCallBack

프로젝트를 완성한 뒤에 최적화 기능 구현이 우선

1. for 문

가장 기본적인 루프 방법이다. 반복 횟수를 지정하거나 조건을 설정하여 반복할 수 있다.

for (let i = 0; i < array.length; i++) {
  console.log(array[i]);
}

• 장점: 초기화, 조건, 증감 부분을 자유롭게 설정할 수 있어 유연하다.
• 단점: 코드가 길어질 수 있으며, 반복 횟수를 명시적으로 관리해야 한다.

2. for...in 문

객체의 열거 가능한 속성에 대해 반복한다. 배열에도 사용할 수 있지만 권장되지 않는다.

const object = { a: 1, b: 2, c: 3 };
for (let key in object) {
  console.log(key, object[key]);
}

• 장점: 객체의 모든 열거 가능한 속성을 반복할 때 유용하다.
• 단점: 배열에도 사용할 수 있지만, 배열의 인덱스를 문자열로 처리하므로 예기치 않은 동작을 할 수 있다.

3. for...of 문

반복 가능한(iterable) 객체(Array, Map, Set, String 등)의 요소에 대해 반복한다.

const array = [10, 20, 30];
for (let value of array) {
  console.log(value);
}

• 장점: 배열 및 다른 반복 가능한 객체의 요소를 반복하는 데 적합하다. 코드가 간결하다.
• 단점: 객체의 속성을 반복할 수 없다.

4. forEach 메서드

배열에서 사용 가능한 메서드로, 각 요소에 대해 함수를 실행한다.

const array = [10, 20, 30];
array.forEach(value => {
  console.log(value);
});

• 장점: 간결하고 가독성이 좋다. 배열의 각 요소에 대해 함수형 프로그래밍 스타일로 작업할 수 있다.
• 단점: break나 continue를 사용할 수 없다. 비동기 처리를 잘 지원하지 않는다.

비교 요약

이 표를 통해 각 루프 방식의 사용 사례와 장단점을 이해하고, 상황에 맞는 적절한 루프를 선택할 수 있다.

canva developer resources - compound components patterns.dev

학습 배경

다음은 '오픈마인드' 프로젝트에서 내가 맡은 드롭다운 컴포넌트이다.

// Dropdown.js
export default function Dropdown({ options, handleOption }) {
  const [isOpen, toggleDropdown] = useToggle(false);
  const { selectedOption, selectOption } = useDropdown(options);

  return (
    <S.DropdownWrapper>
      <S.DropdownButton $isOpen={isOpen} onClick={toggleDropdown} type='button'>
        {selectedOption.content}
        {getCaret(isOpen)}
      </S.DropdownButton>
      {isOpen && (
        <S.OptionList>
          {options.map((option) => (
            <S.Option
              key={option.value}
              onClick={() => {
                selectOption(option);
                handleOption(option.value);
              }}
              $isSelected={option.content === selectedOption.content}
            >
              {option.content}
            </S.Option>
          ))}
        </S.OptionList>
      )}
    </S.DropdownWrapper>
  );
}

// useDropdown.js
import { useState, useCallback } from 'react';

export default function useDropdown(options) {
  const [selectedOption, setSelectedOption] = useState(options[0]);
  const selectOption = useCallback((option) => {
    setSelectedOption(option);
  }, []);

  return {
    selectedOption,
    selectOption,
  };
}

UI 와 디자인을 구분한다고, useDropdown 커스텀훅까지 만들었지만, Dropdown 컴포넌트는 여전히 지저분하다.

// FeedSection.jsx
    <S.SectionContainer className={className}>
      <Dropdown options={orderOptions} handleOption={handleOption} />
      <FeedList feeds={feeds} />
    </S.SectionContainer>

사용되는 Dropdown 은 지나치게 생략되었다. 과연 options 프롭스만 넘겨주면 내가 원하는 드롭다운을 매번 재사용하는게 가능할까?

정답은 그렇지 않다 위는 대표적인 안티패턴으로, 하나의 컴포넌트가 너무 많은 일을 맡은 경우가 해당된다.

기존 코드의 문제점

• 복잡성 증가: 모든 상태와 로직을 한 컴포넌트에 모아두면, 컴포넌트가 복잡해 유지보수가 어렵다.
• 재사용성 저하: 드롭다운 컴포넌트의 외부에서 이를 커스텀할 수 있는 것은 오직 options와 handleOption 뿐이다.
• 테스트 어려움: 컴포넌트가 복잡하니, 개별 기능을 테스트하기 어렵다.
• 성능 저하: 복잡한 컴포넌트는 쓸데없이 리렌더링이 일어날 가능성이 높다. 나는 위 문제점을 해결하기 위한 방안을 모색하던 중, 컴파운드 컴포넌트 디자인 패턴에 대해 알게 되었다.

  컴파운드 컴포넌트

  컴파운드 컴포넌트(Compound Component) 패턴은 여러 개의 독립적인 하위 컴포넌트들을 조합하여 UI를 구성하는 방식이다. 드롭다운과 같이 부모 컴포넌트와 자식 컴포넌트가 같은 상태를 공유하고, 함께 동작하는 경우에 컴파운트 컴포넌트를 따르는 것이 매우 효과적이다.

컴파운드 컴포넌트 패턴은 UI를 더욱 유연하게 구성할 수 있도록 하며, 각 하위 컴포넌트를 독립적으로 관리하면서도 상위 컴포넌트와 잘 연동되도록 할 수 있다.

예시 : 드롭다운

드롭다운 컴포넌트를 분석하면

1. 모두를 감싸는 컨테이너
2. 드롭다운을 토글하는 버튼
3. 토글 시 나타나는 메뉴
4. 메뉴 안의 각 선택지

이렇게 4가지로 구분할 수 있다.

1. 컨테이너 컴포넌트

   // Dropdown
   const DropdownContext = createContext();
   

const Dropdown = ({ children }) => { const [isOpen, setIsOpen] = useState(false); const toggle = () => setIsOpen(!isOpen);

return (
    <DropdownContext.Provider value={{ isOpen, toggle }}>
        <div className='dropdown'>{children}</div>
    </DropdownContext.Provider>
);

};

- 드롭다운은 컨텍스트로 감싸 isOpen 과 toggle 이라는 상태를 드롭다운과 하위 컴포넌트들이 동시에 사용할 수 있다.
1. 토글 컴포넌트
```jsx
// Toggle
const Toggle = ({ children }) => {
    const { toggle } = useContext(DropdownContext);

return (
        <button className='dropdown-toggle' onClick={toggle}>
            {children}
        </button>
    );
};

• 토글 컴포넌트는 toggle 이라는 동작을 받아, 클릭시에 isOpen 이라는 상태의 값을 변경할 수 있다.

3. 메뉴 컴포넌트

   // Menu
   const Menu = ({ children }) => {
    const { isOpen } = useContext(DropdownContext);
   
   return isOpen ? <div className='dropdown-menu'>{children}</div> : null;
   };

• 메뉴 컴포넌트는 isOpen 에 따라 조건부로 렌더링 된다.

4. 아이템 컴포넌트

   // Item
   const Item = ({ children, onClick }) => {
    return (
        <div className='dropdown-item' onClick={onClick}>
            {children}
        </div>
    );
   };

   // export
   Dropdown.Toggle = DropdownToggle;
   Dropdown.Menu = DropdownMenu;
   Dropdown.Item = DropdownItem;
   

export default Dropdown;

- 어차피 하위 컴포넌트들은 Dropdown 이랑 한 세트이므로, 한 번에 import 받을 수 있게 Dropdown의 프로퍼티로 넘겨준다.
5. 사용 예시
```jsx
// App.jsx
    <Dropdown>
        <Dropdown.Toggle>드롭다운 버튼</Dropdown.Toggle>
        <Dropdown.Menu>
            <Dropdown.Item onClick={() => handleItemClick(1)}>
                옵션 1
            </Dropdown.Item>
            <Dropdown.Item onClick={() => handleItemClick(2)}>
                옵션 2
            </Dropdown.Item>
        </Dropdown.Menu>
    </Dropdown>

• 만든 드롭다운 컴포넌트는 위 처럼 조합하여 만든다.
• 이렇게 될 경우, 우리는 Dropdown에 종속되어 있는 하위 컴포넌트들을 바깥에서 직접 커스터마이징 할 수 있어 디자인이 유연하다.

장점

• 유연성: 하위 컴포넌트들을 원하는 대로 조합하여 상위 컴포넌트를 구성할 수 있다.
• 재사용성: 하위 컴포넌트들이 독립적이므로 다양한 조합으로 재사용할 수 있다.
• 캡슐화: 상위 컴포넌트는 하위 컴포넌트의 상태와 동작을 관리하고, 하위 컴포넌트는 자신의 역할에만 집중할 수 있다.
• 가독성: 컴포넌트의 역할이 명확하게 분리되어 있어 코드의 가독성이 향상된다.

결론

컴파운드 컴포넌트 패턴은 복잡한 UI를 더 유연하고 유지보수하기 쉽게 만들어준다. 이 패턴을 사용하면 각 구성 요소를 독립적으로 관리할 수 있어 코드의 가독성과 재사용성을 높일 수 있다. 특히, 다양한 상황에서 쉽게 확장 가능하고, 사용자 정의가 필요한 경우에 매우 유용하다.

React로 개발하면서 컴포넌트의 복잡성이 증가할 때, 컴파운드 컴포넌트 패턴을 도입해보길 권해본다. 이를 통해 더 깨끗하고 관리하기 쉬운 코드를 작성할 수 있을 것이다. 또한, 팀 협업 시 컴포넌트의 역할이 명확해져 개발 효율성을 높일 수 있다.

대다수의 프로그래밍 언어

• 사람이 사용하는 프로그래밍 언어를 컴퓨터가 이해할 수 있게, 중간에 컴파일이라는 과정이 수반됨
• 프로그래밍 언어 -> AST: 추상 문법 트리 -> 바이트 코드

  타입스크립트

• 타입스크립트 -> AST -(타입 검사)> JavaScript
• 타입스크립트의 결과물은 바이트 코드가 아닌 자바스크립트 코드
• 타입 관련 문법들은 자바스크립트로 변환되어 사라짐, 프로그래밍 실행에 영향 X

타입스크립트 주요 동작 단계

타입스크립트는 크게 두 가지 주요 단계로 동작한다.

• 타입 검사
• 트랜스파일링

  1. 타입 검사 (Type Checking)

• 타입 지정: 타입스크립트에서는 변수, 함수 매개변수, 반환 값 등의 타입을 명시적으로 선언할 수 있다.

  let message: string = "Hello, TypeScript!";
  

```ts
function hello(a: number){
  console.log(a)
}
hello(33)
//correct


function hello(a: number){
  console.log(a)
}
hello("Joah")
//error

• 타입 추론: 명시적으로 타입을 선언하지 않은 경우, 타입스크립트는 변수의 초기 값이나 함수의 반환 값 등을 통해 타입을 추론한다.

  let count = 42; // 이 변수의 타입은 자동으로 number로 추론된다.

• 컴파일 타임 검사: 타입스크립트는 컴파일 중에 모든 타입 선언과 추론이 일치하는지 확인한다. 타입 불일치나 오류가 발생하면 컴파일 오류를 발생시킨다.

  let userName: string = 123; // 컴파일 오류: 'number' 타입을 'string' 타입에 할당할 수 없다.

  2. 트랜스파일링 (Transpiling)

• 트랜스파일러 역할: tsc는 타입스크립트 코드를 자바스크립트 코드로 변환한다. 이 과정에서 모든 타입 정보는 제거되고, 순수한 자바스크립트 코드만 남게 된다.

  // 타입스크립트 코드
  let greeting: string = "Hello, TypeScript!";
  console.log(greeting);
  

// 변환된 자바스크립트 코드 var greeting = "Hello, TypeScript!"; console.log(greeting);

- 타겟 설정: 개발자는 tsconfig.json 파일을 통해 트랜스파일링 설정을 정의할 수 있다. 특정 ECMAScript 버전을 지정하거나, 모듈 시스템 등이 이에 해당한다.
```json
{
  "compilerOptions": {
    "target": "ES5",
    "module": "commonjs"
  }
}

오류 사전 방지: 타입스크립트는 정적 타입 검사를 통해 코드 작성 중에 잠재적인 오류를 사전에 발견한다. 이는 디버깅 시간을 크게 줄이고, 코드의 안정성을 높인다. 예를 들어, 변수의 타입을 미리 지정함으로써 잘못된 타입의 값이 할당되는 것을 방지한다.

IDE 지원 강화: 타입스크립트는 정적 타입 정보를 제공하므로, 코드 작성 시 더 나은 자동 완성, 코드 탐색 및 리팩토링 지원을 받을 수 있다. 이는 개발 생산성을 크게 향상시킨다.

2. 코드 가독성 및 유지보수성 향상

명시적 타입 선언: 타입스크립트에서 변수와 함수에 명시적으로 타입을 선언할 수 있다. 이는 코드의 의도를 더 명확하게 만들어 팀원 간의 이해도를 높이고, 유지보수성을 향상시킨다.

인터페이스와 제네릭: 타입스크립트는 인터페이스와 제네릭 타입을 통해 복잡한 타입 정의를 더 명확하고 구조적으로 할 수 있게 해준다. 이는 복잡한 애플리케이션 개발 시 특히 유용하다.

3. 대규모 프로젝트 관리 용이

모듈 시스템: 타입스크립트는 모듈 시스템을 통해 대규모 프로젝트를 더 쉽게 관리할 수 있게 해준다. 이는 여러 개발자가 협업하는 프로젝트에서 특히 유용하다.

스케일링: 코드베이스가 커질수록 타입스크립트의 정적 타입 시스템과 모듈 시스템은 코드의 구조를 더 잘 유지하고, 복잡성을 관리하는 데 유리하다.

결론

타입스크립트는 코드의 안전성, 가독성, 유지보수성 면에서 자바스크립트보다 많은 이점을 제공한다. 따라서 대규모 프로젝트나 장기적인 유지보수가 필요한 프로젝트에서는 타입스크립트를 사용하는 것이 더 바람직하다.

타입스크립트에서 악명이 높은 공변성과 반공변성에 대해 알아보자. 먼저, 이 포스트는 tsconfig의 strictFunctionTypes 옵션이 true 인 경우를 기준으로 말함을 알린다.

{
    "compilerOptions": {
        "strictFunctionTypes": true;
    }
}

공변성 (Covariance): 좁은 타입을 넓은 타입에 대입 O / 넓은 타입을 좁은 타입에 대입 X

공변성은 한 타입이 다른 타입의 서브타입(subtype)일 때, 그 타입을 사용하는 다른 모든 맥락에서도 서브타입 관계가 유지되는 성질을 말한다.

예를 들어, 배열 타입은 공변적인데, Animal이 Dog의 슈퍼타입이라면, Animal[]은 Dog[]의 슈퍼타입이다.

interface Animal {
  name: string;
}

interface Dog extends Animal {
  breed: string;
}

let animals: Animal[] = [{ name: '여름이' }];
let dogs: Dog[] = [{ name: '여름이', breed: '말티즈' }];

animals = dogs; // 정상: Dog[]는 Animal[]의 서브타입
dogs = animals; // 에러: 넓은 타입을 좁은 타입에 대입 X

즉, Dog ⊂ Animal 이므로, Dog[] ⊂ Animal[] 의 관계 또한 성립하는 것을 공변성이라고 한다.

함수의 반환값의 타입 역시 공변적이다.

type giveDog = (a: string) => Dog;
declare const giveMaltese: (a: string) => Maltese;
declare const giveAnimal: (a: string) => Animal;

const dog: giveDog = giveMaltese; // 정상: Maltese ⊂ Dog 이므로 giveMaltese ⊂ giveDog
const dog: giveDog = giveAnimal; // 넓은 타입을 좁은 타입에 대입 X

반공변성 (Contravariance): 넓은 타입을 좁은 타입에 대입 O / 좁은 타입을 넓은 타입에 대입 X

반공변성은 한 타입이 다른 타입의 서브타입일 때, 그 타입을 매개변수로 사용하는 모든 맥락에서 역으로 서브타입 관계가 유지되는 성질을 말한다.

예를 들어, 함수 매개변수 타입은 반공변적이다.

type takeDog = (a: Dog) => string;
declare const takeMaltese: (a: Maltese) => string;
declare const takeAnimal: (a: Animal) => string;

const dog: takeDog = takeMaltese; // 에러: 함수의 매개변수는 반공변성을 따라 좁은 타입을 넓은 타입에 대입 X
const dog: takeDog = takeAnimal; // 정상: Dog ⊂ Animal 이지만 takeAnimal ⊂ takeDog

• 첫 번째 대입에서 에러가 발생하는 이유는 takeMaltese 함수는 Maltese 타입만 받아들일 수 있는데, takeDog 타입은 더 넓은 범위인 Dog 타입을 받아들일 수 있어야 하기 때문이다. 만약 takeDog 타입이 takeMaltese 타입을 받아들이면, Dog 타입의 다른 서브타입을 전달할 때 문제가 발생할 수 있다. 따라서 이는 타입 안전성을 보장하지 못한다.
• 두 번째 대입은 정상이다. takeAnimal 함수는 Animal 타입을 받아들이기 때문에 Dog 타입도 받아들일 수 있다. 즉, takeAnimal은 더 넓은 범위를 받아들이기 때문에 takeDog 타입으로 대입이 가능하다. 이는 타입 안전성을 유지한다.

반공변성은 타입 시스템에서 매개변수의 타입을 설정할 때 매우 중요하다. 함수의 매개변수 타입이 서브타입으로 대체될 경우, 호출 시점에 잘못된 타입이 전달될 수 있다. 예를 들어, takeDog 타입이 takeMaltese 타입으로 대체되면, Dog 타입의 다른 서브타입 (예: Bulldog)이 전달될 때 문제가 발생할 수 있다. 반대로, 더 넓은 타입인 Animal 타입을 사용하는 것은 안전하다.

출처

제로초 유튜브

useMemo 는 비용이 큰 연산에 대해 결과를 메모이제이션해 두고, 저장된 값을 반환하는 훅이다. 리액트 최적화를 얘기할 때 가장 많이 언급되는 훅이다.

import { useMemo } from 'react'

const memoizedValue = useMemo(() => expensiveComputation(a, b), [a, b]);

첫번째 인수는 특정 값을 반환하는 생성 함수를, 두번째 인수로는 해당 함수가 의존하는 값의 배열을 전달한다. 렌더링 발생 시 의존성 배열의 값의 변경이 없다면, 함수를 재실행하지 않고 이전에 기억해 둔 해당 값을 반환한다. 변경이 있었다면, 함수를 새로 실행해 값을 반환하고 해당 값을 기억한다.

메모이제이션의 반환값으로 컴포넌트도 올 수 있다.

• Memoized Component: 기억되고 있는 컴포넌트로, 의존성 배열의 값이 변화되지 않으면 리렌더링되지 않는다.

비용이 많이 드는 연산에서 useMemo 가 쓰인다는 것은 알았다. 그럼 모든 함수와 컴포넌트에 useMemo 를 적용하면 좋은거 아닌가?

하는 궁금증이 들었다.

관련 내용은 추가로 공부해 정리해보았다.

리액트 제공 API 중 useMemo, useCallback, memo 는 리액트에서 발생하는 렌더링을 최소한으로 줄이기 위해 사용된다. 그런데, 언제 정확히 써야하는걸까? 메모이제이션 비용과 렌더링 비용은 어떻게 비교하는걸까?

여기에 대해서는 갑론을박이 많다.

주장1: 섣부른 최적화는 독이다. 필요한 곳에만 메모이제이션 하라.

• 메모이제이션도 비용이 든다.
• 간단한 연산은 자바스크립트 메모리 어딘가에 두었다 꺼내오는 것보다, 매번 해당 작업을 수행하는게 더 빠르고 좋다.
• premature optimization은 지양해야 한다.
• 렌더링이 그렇게 큰 비용이 들면, 기본 리액트에서 이미 모든 컴포넌트를 PureComponent 나 memo 로 감싸서 나왔겠지.
• 메모이제이션은 무조건 좋은게 아니라, trade off 가 있다. 희생하는 면도 고려해야.
• 무조건 좋은 방향은 없음. 하드웨어 기술의 발전이 있으면, 매번 연산을 하는게 메모리에 저장하는 것보다 비용이 줄어들 수도 있어. 최적화 전략은 상황에 따라 판단. 미래에는 useMemo 가 최적화 기법으로 남아있지 않을 수도.

주장2: 렌더링 비용은 비싸다. 모조리 메모이제이션 하라.

• 일부 컴포넌트를 메모이제이션하는건 당장 성능에 도움이 된다.
• 렌더링이 자주 일어나고, 그 렌더링 안에 비싼 연산이 있다면 메모이제이션의 이점은 분명하다.
• 일단 모두 memo로 감싸고 지불해야 하는 비용은 props 의 얕은 비교뿐? -> 렌더링의 비용과 비교하면 훨씬 싸다.

이전에 프로토타입 체이닝을 통해 자바스크립트에서 상속이 구현됨을 확인했다.

var Person = (function(){
  function Person(name){
    this.name = name;
  }

  Person.prototype.sayHi = function(){
    console.log('안녕! 내 이름은 ' + this.name);
  }
return Person
}());

var me = new Person('Lee');
me.sayHi();

그런데, 많은 개발자들은 자바나 C#의 클래스 기반 객체지향 모델에 익숙하다. 이에 따라 ES6 에서는 클래스를 도입하여, 위 개발자들의 편의를 늘렸다.

그러나, 클래스는 껍데기만 클래스이지, 속살은 우리가 이미 아는 프로토타입 기반의 생성자 함수이다. 즉, 문법적 설탕에 해당한다. 다만, 기존 생성자 함수와는 완전히 일치하지는 않으므로 추가 공부가 필요하다.

클래스와 기존의 생성자 함수와의 차이점

1. 클래스는 new 연산자 없으면 에러
2. 클래스는 extends, super 키워드를 지원
3. 클래스는 호이스팅이 안되는 것처럼 동작..! -> 사실은 일어난다는건가?
4. 클래스 내부는 암묵적으로 strict mode 지정
5. 클래스의 constructor, 메서드(프로토타입, 정적)는 모두 Enumerable 값이 false. 열거불가능.

클래스 정의

클래스는 일급 객체이다. 즉, 함수를 값처럼 쓰고 자유롭게 만지는 것 마냥, 클래스도 동일하게 다룰 수 있다. 클래스는 함수다.

class Person {
  constructor(name){
    this.name = name;
  }

  sayHi(){
    console.log('안녕 내 이름은 ' + this.name);
  }

  static sayHello(){
    console.log('아아안녕~');
  }
}

const me = new Person('윤호');
console.log(me.name); // '윤호'
me.sayHi(); // '안녕 내 이름은 윤호'
Person.sayHello(); // '아아안녕~'

클래스 호이스팅

함수처럼 런타임 이전에 평가되고 함수 객체를 생성한다. ([[JS - 빌트인 객체, this, 실행 컨텍스트]] 참조) -> constructor 함수와 프로토타입이 쌍으로 생성된다.

그런데, 클래스는 클래스 정의 이전에 호출이 불가능하다.

const Person = '';
{
  console.log(Person); // ReferenceError
  class Person {}
}

호이스팅이 안 일어났다면, Person 은 상위 스코프의 '' 값을 참조하는게 맞고, 출력도 멀쩡히 되야 한다.

그런데, 참조 에러가 발생한다. 이는 클래스도 호이스팅이 일어난다는 증거다. 그런데, let, const 키워드 처럼 일시적 사각지대에 빠지기 때문에 호이스팅이 발생하지 않는 것처럼 동작한다.

인스턴스 생성

클래스의 존재 의의는 인스턴스 생성이기에 항상 new 와 함께 사용된다.

const Person = class MyClass{};
console.log(MyClass); // 참조 오류
const you = new MyClass(); // 참조오류

위에서 에러가 발생하는 이유는 MyClass 라는 클래스 이름은 클래스 몸체 안에서만 유효하기 때문이다. 기명 함수 표현식과 비교하면 이해하기 쉽다.

const var = function foo(){
   return '사랑해요~';
}
console.log(var); // 함수
console.log(foo); // 참조오류

메서드

클래스가 가질 수 있는 메서드 종류는 세 가지. constructor, 프로토타입 메서드, 정적 메서드가 있다.

• constructor

  클래스의 constructor 메서드와 프로토타입의 constructor 프로퍼티는 다르다! 클래스 내부에서 두 개 이상의 consturctor 는 있을 수 없다. consturctor 는 생략 가능하다. 생략시 클래스는 빈 객체를 생성한다. constructor 에 return 은 없어야 한다. 기본적으로 return this; 해야 하니까. 이거 건들면 인스턴스 생성이 안됨. 다만 return 1; 같이 원시값을 반환하면, construuctor 는 이를 무시하고 this 를 정상적으로 반환한다. 하지만 역시 return 을 생략하는게 가장 안전하다..!

• 프로토타입 메서드

  클래스는 prototype 프로퍼티에 메서드 추가하지 않아도 된다. 생성자 함수와 마찬가지로 클래스로 생성한 인스턴스는 프로토타입 체이닝의 일원이 된다. 클래스는 프로토타입 기반의 객체 생성 메커니즘일뿐, 생성자 함수와 역할이 동일하다.

• 정적 메서드

  클래스는 정적 메서드를 생성자 함수와 다르게 명시적으로 표시한다. static 키워드를 붙인다. 생성자 함수와 마찬가지로 정적 메서드는 인스턴스가 아닌 생성한 모체(생성자 함수/클래스)로 호출한다. this를 사용하지 않는 메서드라면, 정적 메서드를 쓰는게 좋다.

클래스의 인스턴스 생성 과정

1. 빈 객체로 인스턴스 생성 + 여기에 this 바인딩
2. 인스턴스 초기화 ~ constructor 내부 코드에 의해
3. 인스턴스 반환 (인스턴스랑 바인딩된 this가 암묵적으로 반환)

프로퍼티

1. 인스턴스 프로퍼티: constructor 안에서 정의
2. 접근자 프로퍼티: getter와 setter. 프로토타입 프로퍼티. 인스턴스에서 참조 가능.

   class Person{
     get FullName(){
       returen `${this.firstName} ${this.lastName}`;
     }
     set FullName(name){
       [this.firstName, this.lastName] = name.split(' ');
     }
   }

3. 클래스 필드

   class Person{
   name = 'Lee';
   getName = function(){
    return this.name;
   }
   }

   클래스 필드에 함수 선언하면, 이는 프로토타입 메서드가 아니라 인스턴스 메서드가 된다. 즉 인스턴스 만들때마다 새로 함수를 만들어 내니까, 하지 마라탕...
4. private field

   class Person = {
     #name = ''; // 얘는 클래스 몸체 안에서만 참조 가능
     constructor(name){
       this.#name = name;
     }
     get name(){
       return this.#name;
     }
   }

   인스턴스에서 접근 못하는 프로퍼티 만들 때 사용. 접근자 프로퍼티로 간접적으로 접근은 가능. 프라이빗 필드는 반드시 클래스 몸체에서만 정의해야 함...

클래스 상속

class Animal {
  constructor(age, weight){
    this.age = age;
    this.weight = weight;
  }

  eat(){return 'eat';}

  move(){return 'move';}
}

class Bird extends Animal {
  fly(){return 'fly';}
}

class Dog extends Animal {
  bark(){return '멍';}
}

상속을 주는 Animal 은 수퍼 클래스 / 상속을 받는 Bird 나 Dog 은 서브클래스 프로토타입 메서드는 물론, 정적 메서드도 상속 가능!

동적 상속

class 가 생성자 함수에게 상속을 받을 수 있다. class Derived extends Base:생성자 함수 {}

서브클래스의 constructor

constructor 생략하면 빈 constructor 가 암묵적으로 정의되고, 얘는 빈 객체를 반환한다. 그런데... 위에서 처럼 서브클래스에서 생략하면

class Tiger extends Animal {
  constructor(...args){ super(...args) }
}

사실 위의 코드가 암묵적으로 위 같은 constructor가 정의된다. super() 는 수퍼클래스의 constructor 를 호출하여 인스턴스를 생성한다.

super

super 키워드는 함수처럼 호출도 되고, this 처럼 식별자처럼 참조도 된다.

1. 호출하면 수퍼클래스의 constructor 를 호출

   class Base{
   constructor(a, b){
    this.a = a;
    this.b = b;
   }
   }
   

class Derived extends Base { constructor(a, b, c){ super(a, b); this.c =. c; } }

>서브 클래스에서 constructor 를 정의하면, 위위에 있는 암묵적인 super 호출 정의가 오버라이드 되므로, super를 호출해야 한다.
>super 호출은 웬만하면 constructor의 최상단
>그리고 얘는 반드시 서브클래스에서만 호출

2. 참조하면 수퍼클래스의 메서드를 호출
```js
class Base{
  constructor(name){
    this.name = name;
  }

  sayHi(){
    return `안녕! ${this.name}`;
  }
}

class Derived extends Base {
  sayHi(){
    return `${super.sayHi()}, 어떻게 지내!` // 메서드 오버라이딩
  }
}

여기서 super.sayHi 는 사실상 Base.prototype.sayHi 를 의미한다. 단, this 바인딩 면에서 다른 점이 있으니 조심해야 한다.

상속 클래스의 인스턴스 생성 과정 (몰라서 넘어감. 다음에 딥다이브해야지)

1. 서브 클래스의 super 호출. 수퍼클래스한테 인스턴스 생성 위임. 해줘잉.
2. 수퍼 클래스의 인스턴스 생성과 this 바인딩
3. 수퍼클래스의 인스턴스 초기화
4. 서브 클래스 constructor 로의 복귀와 this 바인딩
5. 서브클래스의 인스턴스 초기화
6. 인스턴스 반환

표준 빌트인 생성자 함수 확장

extends 는 생성자 함수에게도 상속을 받을 수 있다. class MyArray extends Array{} 하면, 내가 원하는 추가 메서드를 더한 배열 인스턴스를 생성할 수 있다.

그럴땐, 해당 템플릿 리포지토리의 리드미를 열람하여, 템플릿을 사용한 다른 선배들의 소스 코드를 참고하면 도움이 된다.

이 사람은 같은 템플릿을 사용하는게 맞는지 의심될 정도로, 커스텀을 많이 했다. 로그인 기능도 추가하고, 구독 기능도 추가한 것으로 보인다.

반면에 이 사람은 기본적인 틀은 유지하고, 원하는 컴포넌트만 따로 만들어서 추가한 것으로 보인다.

완전한 커스텀은 내 단계에서는 무리이므로, 아래 예시의 소스 코드를 확인해본다.

리포지토리가 public 이라면, 소스코드와 커밋 히스토리 모두 열람 가능하다.

초기 작업이라 간단하게 로고를 수정하고, 헤더 컴포넌트의 구조를 변경한 것으로 보인다.

이처럼 오픈소스의 장점을 물씬 활용하여, 내가 레벨이 부족하더라도 남의 코드를 교과서 삼아 참고하면, 나의 레벨보다 높은 도전적인 코드도 학습하고, 빠르게 내 것으로 적용할 수 있다.

일반적으로 블로그 연재글은 .md 또는 .mdx 형태의 파일로 /data/blog 디렉토리에 있을 것이다.

해당 글들은 깃허브 상에서 수정을 하고 새로운 글을 작성할 수도 있다.

vercel 에서 자동 배포를 지원하기 때문에, main 브랜치에 push 만 해주면 해당 변경사항이 배포된 사이트에 그대로 반영이 된다.

각 포스팅에 해당하는 md 파일들은 예시 코드들을 참고해서 작성할 수도 있고, 나만의 새로운 규칙을 코드를 직접 수정함으로써 적용할 수도 있다.

vercel 에서 공유되는 템플릿의 종류는 매우 많다. 이 중에서 조금만 커스텀해도 원하는 디자인의 블로그로 만들 수 있게, 자신에게 맞는 구조를 가진 템플릿을 선택한다.

선택한 템플릿에서 view demo 버튼을 누르면,

해당 템플릿을 이용할 때, 만들 수 있는 블로그를 미리 확인할 수 있다.

블로그 프로젝트 배포하기

해당 블로그 템플릿의 깃허브 레포지토리를 찾아 use this template 을 클릭하여, 내 레포지토리에 블로그 프로젝트를 생성한다.

생성한 레포지토리는 vercel 에서 start deploy 메뉴를 클릭하여

깃허브 레포지토리와 연결해준다.

연결되면 자동으로 배포까지 vercel 이 무료로 지원해준다. 도메인까지 지원해준다..! 약간의 빌드 타임을 기다려주면, 블로그 프로젝트의 배포는 완료된다.

커스텀 블로그를 배포하는 방법으로는 여러가지가 있다.

Netlify, GitHub Pages, Heroku, vercel

이 중에서 내가 선택한 배포 플랫폼은 vercel 이다. vercel 은 Next.js 를 개발한 회사로, 다양한 기능을 제공한다.

서버리스 함수, 엣지 네트워크, 즉시 배포, 프론트엔드 프레임워크에 최적화, 자동 스케일링

vercel 을 이용하여 정적인 사이트와 블로그를 배포하는 것에는 다음과 같은 이점이 있다.

1. 성능: Vercel의 엣지 네트워크와 자동 최적화는 빠른 로드 타임과 높은 성능을 보장한다.
2. 사용 용이성: 플랫폼이 직관적이고 배포 과정이 간단하여 개발자에게 친숙하다.
3. 개발자 경험: Vercel은 상세한 분석, 오류 추적, 내장 CI/CD 파이프라인을 제공하여 훌륭한 개발자 경험을 제공한다.
4. 무료 요금제: Vercel은 소규모 프로젝트와 개인 개발자에게 적합한 무료 요금제를 제공한다.

다양한 이점이 있으나, 무료라는 점이 나에게는 가장 매력적이었다. 그리고 커뮤니티가 활성화되어, 양질의 템플릿을 쇼핑하듯이 고를 수 있는 점이 가장 큰 매력이다.

https://vercel.com/templates