FE 훈딩의 개발일지

[ Trouble Shooting ] Storybook 8.0.9 + Next.js 14.2.1 + tailwindcss 3.4.1 에서 Storybook에 tailwindcss 적용 안되는 문제

hoonding — Wed, 1 May 2024 01:15:55 +0900

문제 상황

Storybook 8.0.9 버전 + Next.js 14.2.1 버전 + tailwindcss 3.4.1 버전에서 Storybook에 tailwind가 적용되지 않는 문제가 있었습니다.
애초에 Storybook 8버전이 2024년 3월에 나왔기에, tailwindcss 관련 에러가 있어 해결되지 않았다고 생각했습니다.

tailwind 적용 안되는 상황

해당 버튼 컴포넌트의 class에 tailwind className들이 모두 들어있었지만, 정상적으로 Style이 적용되지 않은 모습을 확인할 수 있었습니다.

이후 Storybook 버전 다운을 고려하였고, 그래도 분명 해결방법이 있을거라 생각하고, Storybook Repo로 돌진하였습니다.
너무 운좋게도 저와 비슷한 Issue를 겪는 사람이 있었고, 해결방법을 찾을 수 있었습니다.

https://github.com/storybookjs/storybook/issues/26869

[Bug]: Storybook doesn't run with tailwindcss in next.js · Issue #26869 · storybookjs/storybook

Describe the bug Describe the bug I have a default next.js setup To apply tailwind to Storybook, I followed the official docs Tailwindcss has applied to my next.js app when I run yarn dev but not t...

github.com

위의 Storybook Issue 중 저와 비슷한 상황을 찾을 수 있었고, 무려 4일 전 사람들이 해당 문제를 해결한 방법을 찾을 수 있었습니다.

감사합니다..감사합니다..

문제 해결

위의 Issue Comment 에 따라 순차적으로 진행했습니다.

1. postcss.config.mjs -> postcss.config.cjs로 수정

postcss.config.mjs 파일을 CommonJS 코드 파일로 수정합니다.

2. postcss.config.cjs 내의 export 방식을 module.exports 로 변경하기

[ 변경 전 postcss.config.mjs 파일 ]

/** @type {import('postcss-load-config').Config} */
const config = {
  plugins: {
    tailwindcss: {},
  },
};

export default config;

[ 변경 후 postcss.config.cjs 파일 ]

/** @type {import('postcss-load-config').Config} */
const config = {
  plugins: {
    tailwindcss: {},
  },
};

module.exports = config;

3. tsconfig.json의 include 에 **/*.cjs 추가

// tsconfig.json
...
...
"include": [
	"**/*.cjs",
    ...
    
]

** .storybook/preview.ts 에 globals.css(tailwind.css) 파일 import

// preview.ts
import type { Preview } from '@storybook/react';
import '../styles/tailwind.css';

....

추가로, .storybook 폴더 > preview.ts 파일에 tailwind 초기화 css 파일을 꼭 import 해줘야 Storybook에서 tailwind가 정상적으로 동작합니다.
여담으로 저는 이 부분도 되어 있지 않아, 삽질을 조금 했습니다..

해결 완료 사진

행복합니다.. 행복합니다...

정말 3시간 동안 삽질을 열심히 하다가,,, 해결해서 너무 행복합니다!

비슷한 Issue가 있다면 도움이 되었으면 좋겠습니다 :)

DNS란?

hoonding — Sun, 3 Sep 2023 16:47:38 +0900

DNS

DNS란 Domain Name System으로, TCP/IP 네트워크 상에서 Domain Name을 IP로 바꾸는 시스템을 의미하거나, 이러한 역할을 하는 Domain Name Server를 의미하기도 한다.

Domain Name

도메인 네임은 사람들이 원하는 사이트에 방문하기 위해 브라우저에 입력하는 주소를 말한다. 외우기 어려운 IP주소가 아닌, 사람이 기억하기 쉽게끔 사용하는 Name이다.

또한, DNS는 거대한 분산 시스템으로, DNS가 저장하고 관리하는 계층적 구조를 도메인 네임스페이스라고 한다. 도메인 네임 스페이스는 계층적 구조로 이루어져 있어, 분산 데이터베이스 시스템을 관리한다.

TLD(Top-Level Domain)

도메인 확장자라고 불리는데, 이는 최상위 도메인이다. .com, .kr, .net 등이 이에 해당한다.

SLD(Second-Level Domain)

최상위 도메인 앞에 오는 도메인 이름을 뜻한다. 이는 일반적으로 사용자 지정 섹션으로, naver, google 같은 이름을 뜻한다.

Subdomain

서브 도메인은 www와 같은 제일 앞에 오는 접두사를 뜻한다.

DNS 동작 방식

https://hanamon.kr/dns란-도메인-네임-시스템-개념부터-작동-방식까지

사용자가 브라우저에 www.naver.com을 입력하면, 사용자의 PC는 미리 설정된 Local DNS 서버에 www.naver.com의 IP 주소를 요청한다.
Local DNS는 자신의 캐시를 확인한다. 만약 해당 주소에 대한 정보가 없으면, Local DNS는 Root DNS 서버에 www.naver.com의 IP 주소를 직접 요청한다.
Root DNS 서버는 .com 최상위 도메인(TLD)을 관리하는 DNS 서버의 주소를 Local DNS에게 알려준다.
Local DNS는 이어서 .com 최상위 도메인 네임 서버에게 naver.com을 관리하는 Authoritative DNS 서버의 주소를 요청한다.
.com 최상위 도메인 네임 서버는 Local DNS에게 naver.com의 Second Level Domain(SLD) DNS 서버 주소를 알려준다. Local DNS는 이 서버에게 www.naver.com의 IP 주소를 직접 물어본다.
SLD DNS 서버는 www.naver.com의 IP 주소를 응답한다. Local DNS는 이 IP 주소를 캐싱하고, 사용자의 PC에 해당 IP 주소를 반환한다. 사용자의 PC는 이 IP 주소로 www.naver.com에 접속한다.

사용자 → LocalDNS 서버 → Root DNS 서버
→ TLS DNS 서버
→ SLD DNS 서버

DNS Recursive Query, Iterative Query

Recursive Query

클라이언트가 DNS 서버에 특정 도메인 이름에 대한 IP 주소를 요청할 때, 해당 DNS 서버가 IP 주소를 알고 있지 않다면, 그 서버는 다른 DNS 서버에 이 정보를 물어본다. 이러한 요청은 필요한 정보를 찾을 때까지 다른 DNS 서버들에 전달되며, 최종적으로 원하는 IP 주소를 얻게 되면 원래의 요청을 보낸 클라이언트에게 그 정보를 전달한다. 이 방식의 주요 특징은 클라이언트가 첫 요청을 보낸 서버만을 대상으로 응답을 기다리며, 그 서버가 나머지 모든 작업을 수행한다는 것이다.

Iterative Query

클라이언트는 DNS 서버에 특정 도메인 이름에 대한 IP 주소를 요청한다. 해당 DNS 서버가 요청받은 정보를 모르면, 클라이언트에게 더 나은 정보를 제공할 수 있는 다른 DNS 서버의 주소를 알려준다. 클라이언트는 그 주소로 직접 연결하여 요청을 보낸다. 이 방식은 클라이언트가 각 과정에서 직접 새로운 서버에 요청을 보내는 특징을 가진다.

참고

DNS란? (도메인 네임 시스템 개념부터 작동 방식까지) - 하나몬

이 게시물의 중요 포인트 DNS(도메인 네임 시스템)이 사람이 읽을 수 있는 도메인 이름(www.hanamon.kr)을 IP 주소로 변환하는 시스템이라는 것은 쉽게 알 수 있습니다. 이번 글에서는 이렇게 도메인

hanamon.kr

OSI 7계층

hoonding — Thu, 10 Aug 2023 21:03:50 +0900

표준구조 : 7계층 모델 / Open Systems Interconnection (OSI) Architecture

OSI 7계층은 네트워크 통신이 일어나는 과정을 7개의 계층으로 구분한 모델이다. 가장 상위 계층인 응용 계층부터 표현, 세션, 전송, 네트워크, 데이터 링크 그리고 가장 하위 계층인 물리 계층으로 이루어져 있다. 각 계층이 본연의 역할을 하는 프로토콜을 두고 통신함으로서 네트워크 과정에 문제가 생겼을 때 빠르고 정확하게 해결할 수 있다는 장점이 있다.

OSI 7계층 구조도

7계층: 응용(Application) — Message

사용자가 네트워크 자원에 접근하는 방법을 제공하고, 사용자가 실행하는 응용 프로그램들이다. 이 계층에는 HTTP, DNS (도메인 변환), SMTP (이메일) 등이 여기에 해당된다.

6계층: 표현(Presentation) — Message

전달받은 데이터를 읽을 수 있는 형식으로 변환한다. 유니코드 인코딩/디코딩, JPEG 압축, 암호화 등이 표현 계층에 포함된다.

5계층: 세션(Session) — Message

포트(Port) 간의 TCP/IP 연결을 생성하여 세션(Session)을 만드는 작업을 수행하는 계층이다. Socket이 5계층에 해당한다.

4계층: 전송(Transport) — Segments

3계층에서 사용하는 IP는 데이터가 소실되어도 책임지지 않는다. 결국, 신뢰성을 보장하지 않는다. 따라서 4계층에서는 신뢰성을 보장하기 위한 노력을 한다. 4계층에는 TCP와 UDP가 이 계층에 해당한다.

:: TCP — 연결지향 프로토콜

TCP는 연결지향 프로토콜로, 두 호스트 사이에서 패킷(Packet)들을 보내기 위해 미리 연결 구성을 한다. 높은 신뢰성을 보장한다. 흐름(Flow)제어, 혼잡(Congestion) 제어 같은 신뢰성을 위한 기능들을 지원하지만 상대적으로 전송 속도는 더 느리다.

::UDP — 비연결 프로토콜

각 패킷을 독립적으로 전송한다. 패킷이 아닌 데이터그램 방식으로 IP 체크섬을 이용한 최소한의 오류 검출만 수행한다. UDP는 신뢰성을 보장하기 위한 여러 장치들이 없기에 신뢰성이 낮다. 속도가 빨라서 실시간 서비스에 적합하다.

3계층: 네트워크(Network) — Packets

멀리 떨어진 노드에 여러 번 거쳐서(2HOP 이상) 전송하기 위한 계층이다. 일반적으로 데이터그램 형식의 IP를 사용하지만, 가상회선 형식의 ATM도 있다. 그리고 3계층에는 라우터가 포함된다.

:: 라우터(Router) — 중계자, 공유기

근처의 IP-MAC 주소를 알고 있어서(라우팅 테이블) 목적지 IP 주소 방향으로 패킷을 중계해줄 수 있다. 우리가 흔히 공유기라고 부르는 것이 라우터의 일종 (NAT 라우터)

2계층: 데이터(DataLink) — Frames

하나의 링크로 직접 연결된 노드 사이의 비트묶음(프레임)을 교환하는 계층이다.

:: MAC(매체 접근 제어)

동시에 여러 장치에서 한 링크에 신호를 보내게 되면, 간섭(충돌)이 생겨서 신호가 망가진다. ⇒ 2계층에서 공평하게, 효율적으로 충돌 안생기도록 관리한다. 전송하기 전에 회선이 idle한지 확인 후 전송한다(CSMA)

:: MAC 주소(Physical Address)

하나의 링크에서 여러 장치가 동시에 전송하려면 주소가 필요하다. 앞에서 나온 MAC(매체 접근 제어)를 위한 주소이다. NIC(네트워크 어뎁터)마다 부여된 주소로, 장치를 변경하지 않는 이상 이 MAC 주소는 Unique하다.

1계층: 물리(Physical)—Bits

2계층의 Frames는 1계층에서 비트로 변환되어, 물리적 매체를 통해 전송된다. 1계층에서는 전기신호를 전송한다.

[ React ] State - Context API와 useReducer() 동시에 사용하기

hoonding — Thu, 10 Aug 2023 16:40:43 +0900

아래 글은 React 공식문서를 기반으로 작성된 글입니다.

Context를 사용해 데이터를 깊게 전달하기 – React

The library for web and native user interfaces

ko.react.dev

일반적으로 props로 부모에서 자식으로 전달한다. 하지만 props drilling이 너무 깊게 일어나면, 관리하기에 너무 어려워지거나, 코드를 작성하면서 그 props를 사용하지도 않지만 prop으로 전달받아야하는 일이 발생한다.

이때 props로 명시적으로 전달하지 않고, 바로 전달할 수 있는 방법이 Context API이다.

state를 여러 컴포넌트를 통해 전달하는 경우

기본적으로 어떤 한 state를 여러 컴포넌트에서 쓰고 싶을땐 props를 활용하여 다른 컴포넌트에 데이터를 전달한다.

위의 그림에서 볼 수 있듯이 LoginForm 컴포넌트에서 로그인 state가 있을 때, 이 로그인 state는 Shop컴포넌트, Cart 컴포넌트에서 사용하고 싶을 수 있다.
그러면 이 로그인 state는 각각의 Component에서 쓰기 위해서 부모로 전달하고 결국 App 컴포넌트까지 끌어올린 뒤 props를 통해 그 로그인 state를 사용하고 싶은 Component에 전달해야하는 prop 체이닝이 일어난다.
prop 체인은 실제로 데이터가 필요하지 않은 Component 에 전달해야하는 번거로움 + 불필요성 이 있다.
따라서 prop을 제거하고자 Context API가 필요한것이다.

Prop Drilling

prop을 트리 깊숙하게 전달하거나, state를 너무 높이 끌어올린다면, prop drilling이 발생한다.

이러한 prop drilling을 해결하고자, Context API가 등장했다.

Props vs Context

Props

컴포넌트를 구성하고 그것들을 재사용할 수 있도록하는 매커니즘 → 보통은 props로 전달하는것이 일반적.
재사용 가능한 Component를 구성할때는 Props를 써야함!!!
Ex. Input 컴포넌트, Button 컴포넌트…
만약 Input 컴포넌트에서 Context를 사용한다면 모든 Input은 모두 동일한 작업을 수행하게 된다.
그렇게 되면 재사용하기 어려워진다!! → forwardRef 를 사용하기

Context

많은 컴포넌트를 통해 전달하고자 하는 것이 있는 경우
매우 특정적인 일을하는(로그아웃만 하는 기능)이 있는 버튼 같은 경우!

Context API 사용하기 전 고려사항

일단 props로 시작하자.
컴포넌트가 너무 복잡하지 않다면 일단 props로 시작하는 것이다. props는 어떤 컴포넌트가 어떤 데이터를 사용하는지 매우 명확하게 표현되기 때문에 일단 데이터 흐름을 파악하기에는 props가 훨씬 적합하다.
컴포넌트를 추출하고 JSX를 children으로 전달하세요. 일부 데이터를 해당 데이터를 사용하지 않는 중간 컴포넌트의 여러 레이어를 거쳐 전달한다면(그리고 더 아래로만 전달한다면), 이는 종종 그 과정에서 일부 컴포넌트를 추출하는 것을 잊었다는 것을 의미합니다. 예를 들어, posts과 같은 데이터 props를 직접 사용하지 않는 시각적 컴포넌트에 <Layout posts={posts} /> 와 같은 방법 대신, Layout이 children을 prop으로 사용하도록 만들고 <Layout><Posts posts={posts} /></Layout>를 렌더링합니다. 이렇게 하면 데이터를 지정하는 컴포넌트와 데이터를 필요로 하는 컴포넌트 사이의 레이어 수가 줄어듭니다.(?)

→ Composition Component!! 합성 컴포넌트!

Composition vs Inheritance – React

A JavaScript library for building user interfaces

legacy.reactjs.org

컴포넌트에 props 전달하기 – React

The library for web and native user interfaces

ko.react.dev

Context API 주의사항

흔히 오해하는 부분은, Context API를 사용하면 중간에서 사용하지 않는 컴포넌트들은 리렌더링이 발생하지 않는다는 오해를 많이 한다. 하지만 Context API는 중간에 포함되어 있는 모든 컴포넌트들이 state가 변경되면, 모두 리렌더링된다. 따라서 리렌더링 때문에 Context를 사용하려는 생각을 했다면, 옳지 않은 생각이다.

Reducer와 Context 동시에 사용하기

1. Context 만들기

state, dispatch를 관리하는 context 두개를 생성한다.

import { createContext } from 'react';

export const TasksContext = createContext(null);
export const TasksDispatchContext = createContext(null);

2. State, Dispatch를 Context에 넣기

export default function TaskApp() {
  const [tasks, dispatch] = useReducer(tasksReducer, initialTasks);
  // ...
  return (
    <TasksContext.Provider value={tasks}>
      <TasksDispatchContext.Provider value={dispatch}>

이런식으로, state와 context가 한 파일에 있지 않게끔 context를 사용할 수 있지만 한 파일에 state와 context 모두를 관리하는 방법도 존재한다.

한 파일에서 state와 context를 관리하기

export function TasksProvider({ children }) {
  const [tasks, dispatch] = useReducer(tasksReducer, initialTasks);

  return (
    <TasksContext.Provider value={tasks}>
      <TasksDispatchContext.Provider value={dispatch}>
        {children}
      </TasksDispatchContext.Provider>
    </TasksContext.Provider>
  );
}

이런식으로 Context 컴포넌트 안에서 state까지 함께 관리한다면, context를 더 분리하거나, 함수들에 로직을 추가하기 훨씬 쉬워진다.

다른 사람들이 안 알려주는 리액트에서 Context API 잘 쓰는 방법

여러분, 리액트로 웹 애플리케이션 개발 하면서 Context API를 어떻게 사용하고 계신가요? 과거에도 관련 포스트를 작성한적이 있긴 하지만, 지난 몇 년간 Context를 사용하면서 습득하게된 팁들을

velog.io

위의 벨로퍼트님의 글은, Context API 사용하기에 관련한 글이다. 나중에 시간나면 정리해보겠다.

const useUserContext = () => {
	const user = useContext(UserContext);

	if (!user) {
		throw new Error('useUserContext should be used within UserContext.Provider');
	}

	return user;
};

아래의 내용은 실제 프로젝트를 진행하면서 Context를 사용할때 했던 고민이다. 이 고민에 대한 코드리뷰 답변을 살짝 남겨보겠다.

Context내에서 useReducer를 사용할때 state, dispatch Context 2개로 나누기

state, dispatcher에 관한 Context를 두개로 나눠서 진행하는게 일반적이라고 생각
왜냐면 dispatcher만 사용하는 컴포넌트들은 state가 변경되었다고 해서 리렌더링될 필요가 없기 때문!

리뷰 답변: useContext, 사용할 컨텍스트를 가져올 필요 없이 함수 하나만 가져오면 되고, 컨텍스트가 존재하지 않을 때나 추가로 필터링이 필요한 경우 등에 대한 처리를 커스텀 훅에서 해주면 되기 때문에 더 편하다고 생각해서 이렇게 쓰고 있습니다!

[ React ] State - 리액트의 useReducer() 사용하기

hoonding — Thu, 10 Aug 2023 12:59:36 +0900

아래 글은 React 공식문서를 기반으로 작성된 글입니다.

state 로직을 reducer로 작성하기 – React

The library for web and native user interfaces

ko.react.dev

여러개의 state 업데이트가 여러 이벤트 핸들러에 분산되어 있는 컴포넌트는 과부하가 걸릴 수 있다. 이때 reducer를 사용해서 모든 state 업데이트 로직을 통합할 수 있다.

useReducer() : 더 강력한 state관리가 필요한 경우 사용되는 HOOK

useState대신 쓸 수 있는 Hook이다.

useReducer는 state관리를 도와주는 훅으로, 복잡한 state관리를 할때 유용하게 쓰인다.
예를들어, 여러 state들이 함께 속해있는 경우라던지 여러 state들이 같이 바뀌거나 서로 관련될때 useState를 사용해서 state를 관리하면 종종 버그나 오류가 발생하기 쉽다.

useReducer()

const [state, dispatchFn] = useReducer(reducerFn, initialState, initFn);

state : useReducer()도 state를 관리하는 메서드이기에 최신 state의 스냅샷을 return한다.

dispatchFn : Action을 Dispatch하는 함수를 return한다. state를 업데이트하려면, 이 함수를 호출해야한다.

reducerFn : 최신 state 스냅샷을 자동으로 가져오는 함수. 리액트는 새로운 Action이 dispatch될 때마다, reducerFn을 실행시킨다. 그리고 reducerFn안에서 switch문이나 if문을 통해 해당하는 action이 trigger하는 state를 변화시킨다.

reducer로 state 로직 통합하기

컴포넌트가 복잡해지면, state가 업데이트되는 흐름을 한눈에 파악하기 어려워질 수 있다. 예를들어 한 state를 여러 이벤트 핸들러에서 업데이트 할 경우, 한눈에 보기 어렵다. 예를 들어보자

import { useState } from 'react';
import AddTask from './AddTask.js';
import TaskList from './TaskList.js';

export default function TaskApp() {
  const [tasks, setTasks] = useState(initialTasks);
  function handleAddTask(text) {
    setTasks([
      ...tasks,
      {
        id: nextId++,
        text: text,
        done: false,
      },
    ]);
  }
  function handleChangeTask(task) {
    setTasks(
      tasks.map((t) => {
        if (t.id === task.id) {
          return task;
        } else {
          return t;
        }
      })
    );
  }
  function handleDeleteTask(taskId) {
    setTasks(tasks.filter((t) => t.id !== taskId));
  }

reducer를 사용한 state 관리는 state를 직접 설정하는 것과는 살짝 다름. state를 설정하여 React에게 “무엇을 할지”를 지시하는게 아니라, 이벤트 핸들러에서 action을 전달해서 사용자가 한 action을 지정한다.

즉 이벤트 핸들러에서 task를 설정하는게 아니라 task를 추가/변경/삭제하는 action을 전달해서 state를 관리한다.

dispatch로 빼보기

dispatchFn

dispatchEmail({ type: 'USER_INPUT', val: event.target.value });

state를 update하고 싶을땐 dispatchFn을 호출한다.
dispatchFn에 인자는 당연히 Action 이다!

Action

객체로 전달하는게 일반적이고, Action은 항상!! 같은 구조(type)를 가져야한다. type 속성에 접근하려 할때 다른 구조를 가지면 당연히 type에 접근 못하기 때문이다.
{ type: ‘USER_INPUT’, val: event.target.value }

dispatch 함수에 넣어준 객체를 action이라고 한다.

action은 보통 무슨 일이 일어났는지에 대한 정보를 포함한다.

function handleAddTask(text) {
  dispatch(
	// action object.
	{
    type: 'added',
    id: nextId++,
    text: text,
  });
}

function handleChangeTask(task) {
  dispatch({
    type: 'changed',
    task: task,
  });
}
function handleDeleteTask(taskId) {
  dispatch({
    type: 'deleted',
    id: taskId,
  });
}

Action 객체

action 객체의 형식이 따로 정해진건 없다. 하지만 보통 어떤 action인지의 type정보와, 추가적인 정보는 다른 필드를 지정해서 작성하는 것이 일반적이다.

dispatch({
  // specific to component
  type: 'what_happened',
  // other fields go here
});

reducer 함수는?

reducer 함수에 state 로직을 둘 수 있다. reducer 함수는 두개의 매개변수를 가지는데, 하나는 현재 state, 하나는 action 객체이다. reducer함수는 다음 state를 return한다.

보통 reducer함수는 switch문을 사용해서 action마다의 state 변경을 관리한다.

reducer 잘 작성하기

1. reducer는 반드시 순수해야함.

setState와 비슷하게, reducer는 렌더링 중에 실행되고, action은 다음 렌더링까지 대기한다. reducer는 고로 순수해야한다. 순수하다는 것은 입력값이 같다면 결과값이 같다는 뜻이다. reducer는 절대로 컴포넌트 외부에 영향을 미치는 사이드 이펙트를 수행해서는 안된다. 그리고, 객체 및 배열을 immutable하게 업데이트 해야한다.

2. 각 action은 여러 데이터가 변경되더라도 하나의 user interaction을 설명해야한다.

이게 뭔소리냐면, 만약 form에 5개 필드가 있을때 reset이라는 action을 발생시키면, 하나하나의 필드의 reset action을 보내는 것이 아니라, all_reset 같은 action을 전송해야한다.

3. 컴포넌트 함수 바깥에서 만들어야함.

왜냐하면 리듀서 함수 내부에서는 컴포넌트 함수 내부에서 만들어진 어떤 데이터도 필요하지 않기 때문이다. 고로, 컴포넌트 함수 내부에서 정의된 그 어떤것과도 상호작용할 필요가 없다. 리액트가 useReducer 함수를 실행할때 useReducer함수 내부에서 요청되고 사용되는 모든 데이터는 reducerFn 로 전달된다.

const tasksReducer = (tasks, action) => {
  switch (action.type) {
    case 'added': {
      return [
        ...tasks,
        {
          id: action.id,
          text: action.text,
          done: false,
        },
      ];
    }
    case 'changed': {
      return tasks.map((t) => {
        if (t.id === action.task.id) {
          return action.task;
        } else {
          return t;
        }
      });
    }
    case 'deleted': {
      return tasks.filter((t) => t.id !== action.id);
    }
    default: {
      throw Error('Unknown action: ' + action.type);
    }
  }
}

Reducer’s Parameters

state : 최신 state 스냅샷
action : 디스패치된 액션

그래서 useReducer를 언제 사용한다고?

→ useState를 사용하면 너무 번거로운 경우, 너무 많은 일들을 처리해야 하는 경우.

→ 관련 state 스냅샷들이 서로 독립적이고 같이 업데이트가 잘 안되는 경우.

함께 속하는 state들이 있는 경우 ( 여기서는 입력된 값과 그 값에 대한 유효성 )
다른 state에 기반하여 state를 업데이트하는 경우 → useState 객체 state로 해결 가능하긴해!
하지만 state를 객체로 관리하게 되면 state가 복잡해지고 커진다!

useState() vs useReducer()

useState()	useReducer()
state를 관리하는 메인 툴	state를 관리할때 더 강력하게 관리하고 싶을때 쓰는 툴
개별 state 및 데이터들을 다루기에 적합	서로 연관된 state나 데이터를 관리하고 싶을때
state를 업데이트하기 쉽고 변경되는 경우가 적다면 useState를 사용	state update관련해서 복잡한 로직이나 서로 얽혀있을떄 사용.
	연관된 state 조각들로 구성된 state 관련 데이터를 다루는 경우 → 말이 어렵지만 Form input State 가 있는 경우.

useReducer가 강력한 이유

reducer 함수를 사용할 수 있기 때문.
reducer 함수는 복잡한 state 업데이트 로직을 포함한다.

[ React ] 리액트의 Key Props

hoonding — Wed, 2 Aug 2023 22:17:51 +0900

Key Warning

[ key warning 메세지는 왜 발생할까? ]

리액트는 데이터의 목록을 렌더링하는데 있어서 특별한 개념을 갖는데, 리액트에서 발생할 수 있는 성능 손실이나, 버그없이 효과적으로 목록들(li)를 업데이트하고 렌더링할 수 있도록 보장하기 위해 key 라는 개념이 존재한다.

key props를 쓰지 않았을때의 문제점

리액트는 새로운 아이템을 추가했을때 마지막 아이템으로 렌더링하고 모든 아이템을 업데이트해서 컨텐츠를 교체한다.

key props없이 배열을 추가해서 렌더링하면 생기는 일.

추가로 div를 넣어 렌더링해서 끝부분에 넣음.
이후 모든 아이템들을 지나면서 배열에 있는 컨텐츠와 다시 일치시키기 위해 안에 있는 컨텐츠를 업데이트.

→ 성능 측면에서 최악 + 버그까지 발생 가능!!!

왜냐면 모든 목록을 체크해서 업데이트 해야하며 버그를 만들 수 있음.

어떤 버그?

만약 추가한 div가 stateful한 컴포넌트였다면 새로운 아이템이 이전 아이템을 덮어쓴다. 이렇게 되면, 바뀌기 전의 아이템이 가지던 상태변화는 사라진다.

왜 리액트는 이렇게 작동하지?

다른 방법이 없기 때문이다.

간단히 배열의 길이를 체크하고 이미 렌더링된 아이템의 수만 확인한다.

리액트는 새로운 아이템이 어느 위치에 추가되어야하는지 모르는거야

그래서 key props를 사용함으로써 어디에 새로운 아이템이 추가되어야 하는지 알려줄 수 있다.

key props

리액트가 개별 아이템을 인식할 수 있도록 도와준다.
목록의 아이템별로 고유값(key)를 설정한다.
key 값을 설정하면 리액트는 아이템을 식별할 수 있고
배열의 길이 뿐만아니라 아이템이 위치해야할 곳까지 인식한다.
key는 배열 안에서 형제 사이에서 고유해야하고 전역에서는 고유할 필요 없음.
보통 key값은 DB에서 데이터를 받아와서 map이나 reduce로 생성하기에 DB에서 보내준 id 값으로 보통 key값을 설정한다.

리액트 공식문서에서의 key 설명

Key는 React가 어떤 항목을 변경, 추가 또는 삭제할지 식별하는 것을 돕습니다. Key는 엘리먼트에 안정적인 고유성을 부여하기 위해 배열 내부의 엘리먼트에 지정해야 합니다.

항목의 순서가 바뀔 수 있는 경우 Key에 인덱스를 사용하는 것은 권장하지 않습니다. 이로 인해 성능이 저하되거나 컴포넌트의 state와 관련된 문제가 발생할 수 있습니다.

Robin Pokorny’s가 작성한 글인 인덱스를 key로 사용할 경우 부정적인 영향에 대한 상세 설명을 참고하시길 바랍니다. 리스트 항목에 명시적으로 key를 지정하지 않으면 React는 기본적으로 인덱스를 key로 사용합니다.

더 자세히 알고 싶다면 왜 key가 필요한가에 대한 더 자세한 설명을 읽어보세요.

key는 반드시 변하지 않고, 예상 가능하며, 유일해야 합니다. 변하는 key(Math.random()으로 생성된 값 등)를 사용하면 많은 컴포넌트 인스턴스와 DOM 노드를 불필요하게 재생성하여 성능이 나빠지거나 자식 컴포넌트의 state가 유실될 수 있습니다.

Key값으로 index를 사용하면 안되는 이유

먼저 Key는 React가 DOM요소를 식별하는데 사용하는 유일한 것이다.

Key가 배열을 조작하기 전과 동일하면 React는 DOM 요소가 이전과 동일한 구성요소를 나타낸다고 가정한다.

Key는 렌더링 간에 변경되지 않는 안정적인 식별자여야 하지만 Index는 반드시 안정적일 수 없고 배열의 요소 순서가 변경될 때 바뀔 수 있기 때문에 Index를 사용한 Key는 안정적이지 않은 식별자이다.

고로 필자는 Hash를 이용해서 안정적인 키를 생성한다.

function stableHash(value) {
  let hash = 0;
  for (let i = 0; i < value.length; i++) {
    hash = ((hash << 5) - hash) + value.charCodeAt(i);
    hash |= 0; // Convert to 32bit integer
  }
  return hash;
}

function MyList() {
  return (
    <ul>
      {items.map((item, index) => (
        <li key={stableHash(`${index}-${item}`)}>{item}</li>
      ))}
    </ul>
  );
}

[ React ] State - 리액트의 State 관리 방법, 리액트 UI Tree

hoonding — Wed, 2 Aug 2023 21:56:22 +0900

아래 글은 React 공식문서를 기반으로 작성된 글입니다.

State를 보존하고 초기화하기 – React

The library for web and native user interfaces

ko.react.dev

React는 UI 트리에서 어떤 컴포넌트가 어떤 state에 속하는지 추적한다. 또한 state를 언제 보존하고 언제 초기화할지 제어한다.

React UI Tree

브라우저에서는 UI를 렌더링하기 위해 많은 Tree를 사용한다. DOM 트리는 HTML, CSSOM 트리는 CSS, 접근성 트리까지 사용한다.

React 또한, 트리구조를 사용해서 UI를 관리하고 모델링한다. React는 JSX로부터 UI 트리를 생성한다. 이후 React DOM은 해당 UI 트리와 일치하도록 브라우저 DOM 엘리먼트들을 업데이트한다.

출처: https://react-ko.dev/learn/preserving-and-resetting-state

state는 트리의 한 위치에 묶인다.

컴포넌트에 state를 선언할때 우리는 보통 state가 컴포넌트 내부에 존재한다고 생각한다.(아니였어?)

하지만 state는 실제로 React 내부에서 유지된다. React는 UI 트리에서 해당 컴포넌트가 어디에 위치하는지에 따라 React가 관리하는 state를 그 컴포넌트와 연결짓는다.

import { useState } from 'react';

export default function App() {
  const counter = <Counter />;
  return (
    <div>
      {counter}
      {counter}
    </div>
  );
}

function Counter() {
  const [score, setScore] = useState(0);
  const [hover, setHover] = useState(false);
  
  ...

위의 App 컴포넌트의 <Counter /> JSX 태그가 하나만 있지만 서로 다른 위치에서 렌더링된다.

출처: https://react-ko.dev/learn/preserving-and-resetting-state

각 Counter 컴포넌트는 완전히 독립적인 state를 갖는다.

만약 두번째 Counter 컴포넌트의 Rendering을 중지하는 순간, 그 Component가 가지는 state까지 모두 삭제된다. React는 컴포넌트가 렌더링되는 동안 컴포넌트의 state를 유지하고, 컴포넌트가 제거되거나 그 위치에 다른 컴포넌트가 렌더링되면 state를 삭제해버린다.

동일한 위치의 동일한 컴포넌트는 state를 유지한다.

export default function App() {
  const [isFancy, setIsFancy] = useState(false);
  return (
    <div>
      {isFancy ? (
        <Counter isFancy={true} /> 
      ) : (
        <Counter isFancy={false} /> 
      )}

이런식으로 같은 위치에 같은 컴포넌트가 props만 다르게 렌더링된다면, 리액트는 Tree에 같은 위치에 있는 같은 컴포넌트라고 판단하기에 state가 초기화되지 않는다.

React에서 중요한 것은 UI 트리에서의 위치이다.

React에서 중요한것은 JSX 마크업이 아니라, UI 트리에서의 위치이다. React는 우리가 작성한 코드를 알지 못하고, 그저 UI 트리만 확인하고 판단하는 것이다. 따라서 위의 예제와 같이 같은 위치에 같은 컴포넌트가 렌더링된다면, 다른 컴포넌트라고 판단하지 않고, 같은 컴포넌트라고 판단한다.

동일한 위치의 다른 컴포넌트는 state를 초기화한다.

같은 위치에서 만약 컴포넌트가 아예 다른 컴포넌트로 교체된다면, state는 리액트에 의해 삭제된다. 이후 다시 같은 위치에 첫번째 컴포넌트를 다시 렌더링한다면 이미 state는 리액트에 의해 삭제됐기 때문에 새로 initial된 state를 가진 컴포넌트가 렌더링된다.

이처럼 리렌더링 사이에 state를 유지하려면, UI 트리의 구조가 일치해야한다.

이는 React가 트리에서 컴포넌트를 제거할때 state도 같이 제거하기 때문이다.

동일한 위치에서 state 재설정하기

이제 위에서 계속 알아봤듯이, 리액트는 컴포넌트가 같은 위치에 있는동안엔 state를 유지하고 관리하는것을 알 수 있었다. 하지만 같은 위치에 있는 컴포넌트의 state를 reset하고 싶으면 어떻게 해야할까?

export default function Scoreboard() {
  const [isPlayerA, setIsPlayerA] = useState(true);
  return (
    <div>
      {isPlayerA ? (
        <Counter person="Taylor" />
      ) : (
        <Counter person="Sarah" />
      )}
      <button onClick={() => {
        setIsPlayerA(!isPlayerA);
      }}>
        Next player!
      </button>
    </div>
  );
}

위와 같은 컴포넌트에서는 Counter 컴포넌트가 같은 위치에서 렌더링되기 때문에 state가 계속 유지된다. 만약 person이 바뀌면 state를 바꾸고 싶으면 어떻게 해야할까?

컴포넌트를 다른 위치에 렌더링 시키기.
각 컴포넌트에 key 로 컴포넌트를 구분시켜주기.

Option1. 컴포넌트를 다른 위치에 렌더링 시키기.

export default function Scoreboard() {
  const [isPlayerA, setIsPlayerA] = useState(true);
  return (
    <div>
      {isPlayerA &&
        <Counter person="Taylor" />
      }
      {!isPlayerA &&
        <Counter person="Sarah" />
      }
      <button onClick={() => {
        setIsPlayerA(!isPlayerA);
      }}>
        Next player!
      </button>
    </div>
  );
}

위와 같이, 선언한다면 리액트 트리에서는 서로 다른 위치라고 판단한다.

출처: https://react-ko.dev/learn/preserving-and-resetting-state

Option2. key로 state 재설정하기

리액트의 key는 list에서만 사용되는 것이 아니다. key를 이용해서 React가 모든 컴포넌트를 구분하게 할 수 있는데, React는 기본적으로 순서를 이용해서 컴포넌트를 구분한다. 하지만 key를 사용한다면 각 컴포넌트에 id를 부여하는 것이라고 생각하면 된다.

export default function Scoreboard() {
  const [isPlayerA, setIsPlayerA] = useState(true);
  return (
    <div>
      {isPlayerA ? (
        <Counter key="Taylor" person="Taylor" />
      ) : (
        <Counter key="Sarah" person="Sarah" />
      )}
      <button onClick={() => {
        setIsPlayerA(!isPlayerA);
      }}>
        Next player!
      </button>
    </div>
  );
}

리액트의 key prop

key를 지정하면 React가 순서로 컴포넌트를 판단하는 것이 아닌, key 자체로 컴포넌트를 판단하게끔 한다. 따라서 같은 위치에 같은 컴포넌트를 렌더링해도, key값이 다르다면 React 관점에서는 다른 컴포넌트로 대체되었다고 판단하고 state를 초기화한다.

그리고 key를 사용할때 주의할 점은, key가 전역적으로 사용되지 않는다는 점이다. key는 오직 부모 내에서만 컴포넌트를 식별하는데 도움을 준다.

제거된 컴포넌트에 대한 state 보존하기.

1. CSS로 숨기기

css로 컴포넌트는 유지한 채, 보이지 않게끔 하는 방법

2. 부모 컴포넌트에서 관리하기

부모 컴포넌트로 state를 끌어올려 보관하는 방법. 가장 일반적인 방법이다.

3. localStorage 사용하기

React state로 관리하는 것이 아닌 localStorage로 저장하고 불러오는 방법이다.

[ React ] State - 컴포넌트 간 state 공유하기, 제어/비제어 컴포넌트

hoonding — Wed, 2 Aug 2023 17:37:40 +0900

아래 글은 React 공식문서를 기반으로 작성된 글입니다.

컴포넌트 간 State 공유하기 – React

The library for web and native user interfaces

ko.react.dev

state 끌어올리기 - Lifting State Up

두 컴포넌트의 state가 항상 함께 변경되는 것을 구현하려면 두 컴포넌트에서 state를 따로 관리하면 안되고, 부모 컴포넌트에서 state를 만든뒤, props를 통해 state를 각각 전달한다.

이 방법을 우리는 Lifting State Up, state 끌어올리기라고 한다.

function Panel({ title, children }) {
  const [isActive, setIsActive] = useState(false);
  return (
    <section className="panel">
      <h3>{title}</h3>
      {isActive ? (
        <p>{children}</p>
      ) : (
        <button onClick={() => setIsActive(true)}>
          Show
        </button>
      )}
    </section>
  );
}

export default function Accordion() {
  return (
    <>
      <h2>Almaty, Kazakhstan</h2>
      <Panel title="About">
        Panel 1 
      </Panel>
      <Panel title="Etymology">
        Panel 2
      </Panel>
    </>
  );
}

이런식으로 Panel 컴포넌트에서 isActive state를 따로따로 관리하고 있다면, 두개의 Panel이 독립적으로 움직일 것이다.

이때, 우리는 state를 아래와 같은 단계로 부모로 끌어올려 공유할 수 있다.

자식 컴포넌트에서 state를 제거합니다.
공통 부모 컴포넌트에 하드 코딩된 데이터를 전달합니다.
공통 부모 컴포넌트에 state를 추가하고 이벤트 핸들러와 함께 전달합니다.

Step1: 자식 컴포넌트에서 state 제거

function Panel({ title, children, isActive }) {

위와 같이 Panel에서의 isActive state는 삭제한 뒤, props로 isActive를 받는다.

Step2: 부모 컴포넌트에 state 추가하기

export default function Accordion() {
  const [activeIndex, setActiveIndex] = useState(0);

Step3: 자식 컴포넌트에 handler 함수 전달하기

export default function Accordion() {
  const [activeIndex, setActiveIndex] = useState(0);
  return (
    <>
      <h2>Almaty, Kazakhstan</h2>
      <Panel
        title="About"
        isActive={activeIndex === 0}
        onShow={() => setActiveIndex(0)}
      >
				Panel 1					
      </Panel>
      <Panel
        title="Etymology"
        isActive={activeIndex === 1}
        onShow={() => setActiveIndex(1)}
      >
       Panel 2
      </Panel>
    </>
  );
}

Panel에서 클릭이벤트가 발생했을 때, 부모 컴포넌트인 Accordion의 state를 변경할 수 있는 setState 함수를 전달해 준다.

Controlled Component vs. Uncontrolled Component

Controlled Component: 자체적으로 state를 가지는 컴포넌트

실시간으로 값이 필요할때에는 제어 컴포넌트를 사용
Input을 Controlled Component로 만든다면, 매 입력마다 리렌더링이 일어난다.
Ex) 유효성 검사를 Input에 적용할때 사용해야함!

Uncontrolled Component: 자체적으로 state를 가지지 않고, props에 의해 동작하는 컴포넌트

불필요한 렌더링을 줄이고자 할 때, 특히 form 양식을 사용할때 많이 사용한다.
주로 useRef 를 사용해서 값들을 관리하며, state로 관리하지 않기에 불필요한 리렌더링이 일어나지 않는다.
Ex) 일반적인 Form 컴포넌트에서 사용!

SSOT(A Single Source of Truth for Each State)

단일 진실 공급원이라는 뜻인데, 이는 모든 state가 한곳에 있다는 뜻이 아니라, 각 state마다 해당 정보를 소유하는 특정 컴포넌트가 있다는 뜻.

컴포넌트마다 공유하는 state들을 각자 다 생성하는 것이 아닌, 부모(단일 책임)에서 state를 생성해, 자식에게 전달하는 것을 말한다.

[ React ] State - State 구조 선택

hoonding — Wed, 2 Aug 2023 15:54:34 +0900

아래 글은 React 공식문서를 기반으로 작성된 글입니다.

Choosing the State Structure – React

The library for web and native user interfaces

ko.react.dev

state를 잘 구조화하면 수정과 디버깅이 편한 컴포넌트를 만들 수 있다.

자 그러면 state를 어떻게 구조화하는지 알아보자.

state 구조화 원칙

state를 가지는 컴포넌트를 만들때, 얼마나 많은 state 변수를 사용할지, state 구조를 어떻게 최적화할지 고민해야한다.

[ 원칙 5가지 ]

관련된 state들을 그룹화하기
- 만약 어떤 이벤트가 발생했을때 두개 이상의 state들을 동시에 업데이트 한다면, 하나의 state로 합치자.
state의 모순을 피하기
불필요한 state를 피하기
state 중복을 피하기
깊게 중첩된 state는 피하기.
- 깊게 계층화된 state는 업데이트하기 어렵다. 가능하게 flat한 object로 구성하자.

결국 state를 구조화한다는 것은 state를 쉽게 업데이트 할 수 있게 하는것이다. 불필요하거나 중복된 데이터를 제거한다면 데이터가 동기화 상태를 유지하는데 도움이 된다.

1. Group related state: 관련 state들을 그룹화하기.

// X
const [x, setX] = useState(0);
const [y, setY] = useState(0);

// O
// 두 개의 state가 항상 함께 변경되는 경우에는 하나의 state 변수(객체)로 통합하자.
const [position, setPosition] = useState({ x: 0, y: 0 });

아래의 방식으로 state를 그룹화한다면 객체의 변이(mutation)을 걱정할 필요가 없어진다. 결국 불변성을 신경 쓸 필요가 없어지는 것이다!

만약 state 변수가 객체인 경우, 다른 필드를 복사하지 않으면 하나의 필드만 변경할 수 없다.

setPosition({ x: 100 }) // X

// spread 연산자로 복사한뒤 하나의 필드만 바꿔주자.
setPostion({ ...position, x: 100 }) // O

2. Avoid contradictions in state: state의 모순을 피하기

export default function FeedbackForm() {
  const [text, setText] = useState('');
  const [isSending, setIsSending] = useState(false);
  const [isSent, setIsSent] = useState(false);
...

}

이런 컴포넌트가 있을때, isSending과 isSent State는 모순된 상황이 있을 수 있는것이다.

예를들어, setIsSending이나 setIsSent 둘중 하나만 호출해서 상태를 바꾼다면, isSending이나 isSent모두 true나 false가 되는 상황이 발생할 수 있다.

export default function FeedbackForm() {
  const [text, setText] = useState('');
  const [status, setStatus] = useState('typing');

    const isSending = status === 'sending';
  const isSent = status === 'sent';

...
}

이처럼, 모순된 상태들을 올바르게 관리할 수 있다.

3. Avoid redundant state: 불필요한 state들은 피하기

렌더링중에, 컴포넌트의 props나 기존 state변수의 정보에서 뽑아낼 수 있는 state인 경우, state로 관리하면 안된다.

export default function Form() {
  const [firstName, setFirstName] = useState('');
  const [lastName, setLastName] = useState('');
  const [fullName, setFullName] = useState('');

...
}

위의 컴포넌트에서 불필요한 state는 없을까?

그렇다 fullName은 언제든지 firstName과 lastName으로 fullName을 만들 수 있기 때문에 state에서 제거하는것이 맞다.

:: props와 state가 같을 순 없을까?

function Message({ messageColor }) {
  const [color, setColor] = useState(messageColor);

위의 컴포넌트에서는 props와 state가 초기상태에는 같다.

하지만, props가 변경되어서 내려왔을땐, color는 변경되지 않는 문제점이 발생한다. 결국은 따로 동기화하는 코드를 작성해줘야 한다.

function Message({ messageColor }) {
  const [color, setColor] = useState(messageColor);

    useEffect(() => {
        setColor(messageColor);
    }, [messageColor]);

위와 같은 방식은 너무 비효율적이니! 따로 상수를 선언하거나 구조분해할당을 해줘서 사용하면 된다.

function Message({ messageColor }) {
  const color = messageColor;

    // or

function Message({ messageColor: color }) {

4. Avoid duplication in state: state의 중복 피하기

const initialItems = [
  { title: 'pretzels', id: 0 },
  { title: 'crispy seaweed', id: 1 },
  { title: 'granola bar', id: 2 },
];

export default function Menu() {
  const [items, setItems] = useState(initialItems);
  const [selectedItem, setSelectedItem] = useState(
    items[0]
  );

위와 같은 컴포넌트에서 items와 selectedItem은 items 목록 내의 항목 중 하나와 동일한 객체이다.

결국 중복된 정보가 두 state에 존재하는 것이다.

이런경우, 배열의 id를 상태로 관리하는 것이 더 좋은 방법이다.

const initialItems = [
  { title: 'pretzels', id: 0 },
  { title: 'crispy seaweed', id: 1 },
  { title: 'granola bar', id: 2 },
];

export default function Menu() {
  const [items, setItems] = useState(initialItems);
  const [selectedId, setSelectedId] = useState(0);

  const selectedItem = items.find(item =>
    item.id === selectedId
  );

5. Avoid deeply nested state: 깊게 중첩된 state는 피하기.

export const initialTravelPlan = {
  id: 0,
  title: '(Root)',
  childPlaces: [{
    id: 1,
    title: 'Earth',
    childPlaces: [{
      id: 2,
      title: 'Africa',
      childPlaces: [{
        id: 3,
        title: 'Botswana',
        childPlaces: []
      }, 
...
}

이렇게 깊은 depth를 가진 state가 있다면 최대한 flat하게 만드는 것이 중요하다.

export const initialTravelPlan = {
  0: {
    id: 0,
    title: '(Root)',
    childIds: [1, 43, 47],
  },
  1: {
    id: 1,
    title: 'Earth',
    childIds: [2, 10, 19, 27, 35]
  },
  2: {
    id: 2,
    title: 'Africa',
    childIds: [3, 4, 5, 6 , 7, 8, 9]
  },

중첩된 depth를 가진 state를 업데이트 할때에는, 너무 많은 노력이 필요하다. 따라서 state는 최대한 flat하게 만들어서, 쉽게 업데이트하고, 중복된 부분을 최대한 줄이는 것이 중요하다!

[ React ] State - React의 State란?

hoonding — Wed, 2 Aug 2023 13:06:43 +0900

아래 글은 React 공식문서를 기반으로 작성된 글입니다.

State를 사용해 Input 다루기 – React

The library for web and native user interfaces

ko.react.dev

State로 입력에 반응하기

React는 UI를 조작하는 선언적인 방법을 제공 → UI를 개별적으로 직접 조작X, 컴포넌트의 상태를 관리.

리액트는 사용자 입력에 반응해서 각 state를 switching함.

Declarative(선언형) UI Vs. Imperative(명령형) UI

명령적 vs 선언적

명령적(Imperative)

바닐라 JS에서 작성한 방법
JS와 브라우저가 무엇을 해야하는지 단계별로 정확하게 지시해야함
너무 지루하고 복잡한 사용자 인터페이스가 될 수록 너무 어려워짐. → 이미 많이 경험해봤지? ㅋㅋ

선언적(Declarative)

리액트로 작업하는 방법.
React.js를 사용할 때는 목표, 즉 화면에 무엇이 표시되어야 하는지를 정의하고 React가 거기까지 도달하는 방법을 알아내도록 만들어야 합니다.
그저 최종 상태를 정의하기만 하면 리액트는 이런것들을 화면에 불러오기 위한 지시사항들을 뒷단에서 생성해줌.

명령형은?

Vanila JS로 짠 UI 코드들.
하나하나 직접 다 지정해서 이벤트 조작해줘야함.
개발자들이 신경써야할게 왕 많아지는 거임.
순서대로 해야할 일을 개발자가 직접 하나씩 다 지정해줘야함.

복잡한 시스템에서는 UI를 관리하기가 기하급수적으로 어려워짐. - 새로운 인터렉션, 새로운 UI를 추가하기 위해서는 모든 코드들을 일일이 확인하면서 버그의 발생여부를 파악해야함.

리액트의 선언형

위의 명령형(Vanila) 방식 문제들을 해결하기 위해서 리액트가 만들어졌다. React에서는 직접 UI 조작하지 않고, 화면에 표시할 내용을 그저 선언하기만 하면 React가 UI를 업데이트 해준다.

UI를 선언적인 방식으로 생각해보기

Identify: 컴포넌트의 다양한 시각적 상태를 식별합니다.
Determin: 상태 변화를 trigger하는 요소를 파악합니다.
Represent: useState를 사용하여 메모리의 상태를 표현합니다.
Remove: non-essential(비필수적)한 state 변수를 제거합니다.
Connent: 이벤트 핸들러를 연결하여 state를 설정합니다.

Step1. 컴포넌트의 다양한 시각적 상태 식별하기

먼저 리액트에서 state는 CS의 “state machine”에서 나온 state라고 보면 됨.

React는 디자인과 CS의 교차점에 있기에 두 분야에서의 개념들이 섞여있음.

위의 예시의 Form state들을 모두 시각화 해보자.

[ 디자이너의 관점 ]

Empty: form의 “Submit”버튼은 비활성화되어 있습니다.
Typing: form의 “Submit”버튼이 활성화되어 있습니다.
Submitting: form은 완전히 비활성화되어있고 Spinner가 표시됩니다.
Success: form 대신 “Thank you”메세지가 표시됩니다.
Error: ‘Typing’ state와 동일하지만 추가로 오류 메세지가 표시됩니다.

→ 상태들에 따라 어떤 동작을 하게끔 정의해놓은 state machine이 있다고 생각하자.

export default function Form({
  status = 'empty'
}) {
  if (status === 'success') { // success 상태일땐 이 아래걸 렌더링할거고.
    return <h1>That's right!</h1>
  }

    // success 상태가 아니면 이 아래걸 렌더링 할거다!
  return (
    <>
      <h2>City quiz</h2>
      <p>
        In which city is there a billboard that turns air into drinkable water?
      </p>
      <form>
        <textarea />
        <br />
        <button>
          Submit
        </button>
      </form>
    </>
  )
}

한번에 여러 시각적 상태를 표시하기 → storybook, living styleguide라고 한다!

→ state가 여러개가 있을때, 그냥 모든 state에 대한 모든 UI를 다 보여주는 거임!

→ UI 확인할때 좋을 수 있다!

Step2. 상태 변경을 촉발하는 요인 파악하기

입력(Input) 이라는 것엔 두가지로 나눌 수 있다.

사람의 입력: 버튼 클릭, 필드 입력, 링크 이동…
컴퓨터 or 브라우저의 입력: 네트워크에서 응답 도착, 시간 초과, 이미지 로딩, 브라우저의 이벤트 등
→ 두 입력 모두 state 변수를 설정해야 UI를 업데이트 할 수 있음!!

네트워크 Response 성공시, 성공 state로 전환
Submit 버튼을 클릭시, 제출중 state로 전환

[ 흐름을 시각화하기 ]

Step3. 메모리의 상태를 `useState`로 표현하기

[ state 사용하기 ]

state는 단순함이 핵심이다!!
가능한 적은 수의 state를 사용해야한다. 만약 많은 state를 사용한다면 버그 확률이 올라간다!
따라서 state를 사용할때는 무조건 필요한 state부터 시작해야한다!
하지만 줄이는 방법이 생각이 안들면 일단~ 필요한거 다 써봐~

const [answer, setAnswer] = useState('');
const [error, setError] = useState(null);
const [isEmpty, setIsEmpty] = useState(true);
const [isTyping, setIsTyping] = useState(false);
const [isSubmitting, setIsSubmitting] = useState(false);
const [isSuccess, setIsSuccess] = useState(false);
const [isError, setIsError] = useState(false);

Step4. 필요없는 state 삭제하기

위에서 그냥 생각나는대로 다 적은 state들 중에 필요없는 state를 없애는 것이다.

[ state 줄이는 방법 ]

state의 모순점을 찾아보기
- 동시에 true일 수 없다거나, boolean 조합이 4가지가 가능해야하는데, 3가지가 가능하다거나!Ex 2) isSuccess, isError
- Ex 1) isTyping, isSubmitting
다른 state에 이미 정보가 포함되어 있는지 찾아보기
- 다른 state로 그 state를 검사하고, 확인할 수 있다면 없애버려~
- Ex2) 다른 state를 뒤집어서 정보를 얻을 수 있을때
- isError 는 !error 하면 나오는 값임! 없애!
Ex1) isEmpty는 answer.length === 0 으로 대체 가능!!

const [answer, setAnswer] = useState('');
const [error, setError] = useState(null);
const [status, setStatus] = useState('typing'); // 'typing', 'submitting', or 'success'

Step5. 이벤트 핸들러를 연결해서 state 설정하기

async function handleSubmit(e) {
    e.preventDefault();
    setStatus('submitting');
    try {
      await submitForm(answer);
      setStatus('success');
    } catch (err) {
      setStatus('typing');
      setError(err);
    }
  }

그저 handler 함수에서 state를 변경만 해준다.

위의 명령형 방식(Vanlia JS)와 비교한다면 정말 엄청나게 코드가 줄어들고, 한눈에 보이는 것을 알 수 있다.

[백준 1052] 물병 (JS)

hoonding — Wed, 4 Jan 2023 21:42:51 +0900

1052번 - 물병

삽질을 많이한 문제. 이전에 구현했던 10진수를 2진수로 바꾸는 방법과 2진수를 10진수로 바꾸는 방법을 활용하여 풀이를 진행하려고 했지만 결국 필요한 것은 10진수 → 2진수 하나 뿐이였음.

아이디어

1. 주어진 물병의 개수(N)을 이진수로 만든다.

2. 만든 이진수에서 1의 개수가 K보다 작거나 같다면 K개의 물병으로 한 번에 옮길 수 있음

K가 2이고 N이 10이면 → 1010(2)
10 = 8 + 2로 2개의 물병으로 표현 가능!

3. 따라서 주어진 N에 1씩 더하면서 1의 개수를 계속 count해주며 1의 개수와 K값을 계속 비교하여 count ≤ K 를 만족할 때 반복문을 종료하고 그 값을 정답으로 return.

function dec2bin(decimal) {
  let count = 0;
  while (decimal > 0) {
    if (decimal % 2 === 1) count++;
    decimal = Math.trunc(decimal / 2);
  }
  return count;
}

function findBottleNumber(bottleNum, canMove) {
  let answer = 0;
  while (true) {
    let count = dec2bin(bottleNum);
    if (count <= canMove) {
      return answer;
    }
    bottleNum++;
    answer++;
  }
}

console.log(findBottleNumber(input[0], input[1]));

2진수로 바꾸며 1의 개수를 바로바로 count
한 번 반복문을 돌고 조건에 만족하지 않으면 바로 주어진 수를 1씩 더해줌

주의

조건 중 K는 1000보다 작걱나 같은 수
10^7를 이진수로 바꾸면 24자리로 표현 가능
24 < 1000 이기에 정답이 없는 경우는 없음!!

숫자, 문자열

되도록이면 문자열과 숫자를 치환하는 작업은 적게 해야함.
문자열로 접근할거면 문자열로만, 숫자로 접근할거면 숫자로만!
왜냐하면 문자열과 숫자사이의 치환과정은 메모리가 상당히 많이든다!
그리고 문자열을 처리하는 속도와 숫자를 처리하는 속도는 평균 10배 정도 차이난다!! 만약 시간초과가 나온다면
이 부분 한번 고려해보자!

[백준 10757] 큰 수 A + B(JS)

hoonding — Wed, 4 Jan 2023 21:36:52 +0900

BigInt를 처리하는 문제.

먼저 언어에서 지원하는 BigInt 관련된 메서드를 사용하지 않고 이전에 구현해봤던 이진수 덧셈 방식을 채택하여 진행하였다.

아이디어

두 수의 길이가 다르면 index로 접근하였을 때 index 초과가 날 수 있기 때문에 길이를 먼저 맞춰주었다.
이후 제일 아래 자리부터 더해주며 carry(올림수)를 함께 더하는 형식으로 진행하였다.

코드

[ fitLength() 함수 ]

function fitLength(a, b) {
  const distance = a.length - b.length;
  for (let i = 0; i < distance; i++) {
    b.push(0);
  }
  return b;
}

이때 b가 길이가 더 적은 숫자다. 길이를 맞추기 위해 0을 배열에 넣어주었다.

[ bigIntAdd() 함수 ]

function bigIntAdd(a, b) {
  let arrayA = numberToString(a).reverse();
  let arrayB = numberToString(b).reverse();

  const arrayALength = arrayA.length;
  const arrayBLength = arrayB.length;

  if (arrayALength > arrayBLength) arrayB = fitLength(arrayA, arrayB);
  else if (arrayALength < arrayBLength) arrayA = fitLength(arrayB, arrayA);

  let carry = 0;
  let resultArray = [];

  arrayA.forEach((_, index) => {
    aItem = parseInt(arrayA[index]);
    bItem = parseInt(arrayB[index]);
    sum = aItem + bItem + carry;
    resultArray.push((sum % 10) + "");
    sum >= 10 ? (carry = 1) : (carry = 0);
  });
  if (carry !== 0) resultArray.push(carry + "");
  resultArray.reverse();
  return resultArray.join("");
}

두 숫자를 String으로 바꾼 뒤 길이를 맞춰주었다.
이후 carry와 각 자리수를 더해가며 BigInt 덧셈을 구현하였다.

전체코드

const input = require("fs")
  .readFileSync("/dev/stdin")
  .toString()
  .trim()
  .split(" ");

function bigIntAdd(a, b) {
  let arrayA = numberToString(a).reverse();
  let arrayB = numberToString(b).reverse();

  const arrayALength = arrayA.length;
  const arrayBLength = arrayB.length;

  if (arrayALength > arrayBLength) arrayB = fitLength(arrayA, arrayB);
  else if (arrayALength < arrayBLength) arrayA = fitLength(arrayB, arrayA);

  let carry = 0;
  let resultArray = [];

  arrayA.forEach((_, index) => {
    aItem = parseInt(arrayA[index]);
    bItem = parseInt(arrayB[index]);
    sum = aItem + bItem + carry;
    resultArray.push((sum % 10) + "");
    sum >= 10 ? (carry = 1) : (carry = 0);
  });
  if (carry !== 0) resultArray.push(carry + "");
  resultArray.reverse();
  return resultArray.join("");
}

function numberToString(number) {
  return (number + "").split("");
}

function fitLength(a, b) {
  const distance = a.length - b.length;
  for (let i = 0; i < distance; i++) {
    b.push(0);
  }
  return b;
}

console.log(bigIntAdd(input[0], input[1]));

[백준 1076] 저항(JS)

hoonding — Wed, 4 Jan 2023 21:33:46 +0900

색깔 3개를 입력받은 뒤 각 색깔에 해당하는 값을 구하여 저항의 값을 구하는 문제.

처음 2개는 저항의 값, 마지막 1개가 곱해야 하는 값.

풀이

const resistance = {
  black: 0,
  brown: 1,
  red: 2,
  orange: 3,
  yellow: 4,
  green: 5,
  blue: 6,
  violet: 7,
  grey: 8,
  white: 9,
};

문제에서 주어진 색깔별 정보를 Object에 저장하여 진행.
이후 문제에서 주어진 규칙으로 값을 구함.

전체 코드

const input = require("fs")
  .readFileSync("/dev/stdin")
  .toString()
  .trim()
  .split("\n");

const resistance = {
  black: 0,
  brown: 1,
  red: 2,
  orange: 3,
  yellow: 4,
  green: 5,
  blue: 6,
  violet: 7,
  grey: 8,
  white: 9,
};

let result = 1;

const firstColor = resistance[input[0]];
const secondColor = resistance[input[1]];
const thirdColor = resistance[input[2]];

result = (firstColor * 10 + secondColor) * 10 ** thirdColor;
console.log(result);

[백준 1009] 분산처리(JS)

hoonding — Wed, 4 Jan 2023 21:32:18 +0900

1009번 - 분산처리

a^b개의 데이터를 몇 번 컴퓨터가 처리하는지 구하는 문제.

결국 일의 자리만 신경쓰면 문제는 쉽게 풀린다.

풀이

const [a, b] = item.split(" ");
  let firstDigit = 1;
  for (let j = 0; j < b; j++) firstDigit = (firstDigit * a) % 10;
  return firstDigit === 0 ? console.log(10) : console.log(firstDigit);

제곱을 하면서 일의 자리 이외에는 신경쓰지 않고 b번 곱해준다.
곱해주며 일의자리만 % 10 연산을 통해 구해주고 일의자리에 맞추어 몇번 컴퓨터가 담당하는지 출력한다.

전체코드

const fs = require("fs");
let input = fs.readFileSync("/dev/stdin").toString().trim().split("\n");

input.shift();

input.forEach((item) => {
  const [a, b] = item.split(" ");
  let firstDigit = 1;
  for (let j = 0; j < b; j++) firstDigit = (firstDigit * a) % 10;
  return firstDigit === 0 ? console.log(10) : console.log(firstDigit);
});

점대점 링크의 하드웨어 구성요소(Data Link Layer)

hoonding — Wed, 4 Jan 2023 21:24:55 +0900

1, 2계층의 역할

- 하나의 링크로 연결(점대점 연결)된 노드 사이의 Frame 교환

- 점대점 연결에서의 통신의 실체

비트 교환 : 신호 인코딩, 디지털 전송
비트 묶음 교환 : 프레이밍 → 프레임
오류 검출 및 복구

노드(Node)

- 단말, 호스트, 스위치, 라우터 모두 노드임!

스위치 VS 라우터

스위치(2계층) : 이더넷, ATM 등을 기반으로 전송받은 패킷을 다시 다음 노드로 전송해주는 역할

라우터(3계층) : 네트워크를 다른 네트워크로 연결. 네트워크 트래픽 포워딩과 라우팅 기능 제공

- 하드웨어 구성

- 메모리 : Store & Forward 할 때 메모리를 사용

메모리는 유한하다(제한된 버퍼공간)

따라서 메모리가 병목 구간이 된다(프로세서와 NIC는 빠르기 때문)

- 네트워크 어뎁터(NIC) : Network Interface Card(중요!!)

Modem, 오류 검출 및 복구 등을 지원하는 하드웨어적 구성요소.

헤더, CRC, HDLC, 모듈레이션 모두 다 NIC에서 진행!

링크(Link)

데이터(및 신호) 전달을 위한 물리적 매체

- 논리적 통로 관점에서는 하나의 케이블에 여러 링크를 형성할 수 있음

- 하나의 케이블에 링크가 여러개 있을수도 있음.

전송모드

Simplex (단방향)
Half-duplex (반이중) : 양방향 통신을 동시에 지원
Full-duplex (전이중) : 동시에는 양방향 통신 불가, 무전기처럼 교대로

모듈레이션 (데이터 → 신호)

- 데이터를 신호화하는 것을 모듈레이션이라고 한다.

- 데이터를 링크를 통해서 전달하기 위해서 신호로 바꾸는 것이다.

Modulation : 데이터 → 신호

Demodulation : 신호 → 데이터

Modem : NIC의 오른쪽(링크와 만나는 지점)에 위치

모뎀은 NIC와 Link가 만나는 지점에 존재한다.

전자기 스펙트럼과 매체 특성

전송 특성

- 고주파는 전송 특성이 좋지 않다. → 그래서 작은 신호라도 잡으려고 접시안테나 쓴다!!!

- 저주파일수록 전송 특성이 좋다! → 장애물을 잘 통과한다.

통신 속도

- 고주파일수록 통신 속도가 빠르다.

- 대역폭이 크기 때문

유선링크

케이블 종류

UTP < 50옴 구리선 < 75옴 구리선 < MMF < SMF

구리선 : 굵을수록 빠름

광케이블 : 코어(빛이 흐르는 중심부), 클래딩(전반사 시키는 바깥쪽)

SMF(광케이블의 한 종류) : 빛이 여러 파장으로 퍼지는 것을 막기 위해서 코어를 좁게 만든 것

고주파일수록 퍼짐이 더 크기 때문에, SMF를 사용하면 MMF보다 높은 대역폭을 지원할 수 있음
먼 거리, 높은 트래픽에서는 SMF 사용하면 된다.

서비스에서 공급하는 회선 종류

대역폭에 따라 명칭이 다르며, 각 사용처에 맞는 것을 골라서 쓰면 된다.

ex) ISDN : 64Kbps → 음성 전화 (PCM 참조)

무선링크

장점 : 고정된 링크가 없다.

1. 이동성이 좋다.

2. 링크 설치 따로 필요 없이 바로 사용 가능하다.

단점 : 공중으로 퍼져나간다 (신호 통제가 안됨)

1. 인접한 링크 사이에 간섭이 일어날 수 있음

2. 전파 사용에 규제가 필요 (라이센스 제도)

단거리 무선 통신 ( 블루투스, WIFI, ZigBee )

License-Free하다.

적외선 통신 → 라이센스 없어도 사용 가능!

용도

무선 LAN : 유선 LAN을 대체

블루투스 : 휴대기기 - 주변기기 연결 (작고, 가격이 싸고, 전력소비 적어야함)

ZigBee : IoT 기기 제어 (블루투스보다 대역폭은 적어도 거리가 넓고, 매우 저전력)

네트워크 성능(Performance)

hoonding — Sun, 1 Jan 2023 16:25:10 +0900

1. 대역폭(Bandwidth) : 처리량 / 처리속도(Throughput)

- 단위 시간당 전송될 수 있는 데이터의 양

- 10Mbps Mega bit per second

- 표기방법 : KB, Mbps...

KB : 2^10 bytes
Mbps : 10^6 bit per second

대역폭은 비트폭과 반비례 관계.

- 속도가 높아지면 비트폭은 작아진다 → 비트간격이 좁아진다.

- 속도가 높아지면 멀리 퍼지기 힘들다 → 통신이 잘 안된다.

(a) AM , (b) FM

- 비트폭이 크면 당연히 시간당 한번에 보내는 비트수가 줄어들고 처리량(대역폭)은 줄어든다

최대용량 VS 실제처리속도

- 최대용량 : 이론적 용량 → 링크에서 측정.

- 실제처리량 : 최대용량만큼 안나온다. b/c 종단(End)로 가면 실제처리속도는 떨어진다. → 종단에서 측정

2. 소요시간 / 지연시간 ⇒ 거리가 중요한 영향

- Latency( t1 - t0 )/ Delay

- A지점에서 B지점으로 메세지를 송신하는데 걸리는 시간 - 편도!!

- 때로는 왕복지연시간(Round-Trip Time)RTT가 중요할 수 있다.

시간 소요 항목

- 소요시간 = Propagation + Transmit + Queue [ + Switching ]

- Propagation(전파지연시간) = Distance / SpeedOfLight

- Transmit(전송시간) = Size(데이터 크기) / Bandwith (파이프 용량 - 1초당 얼마나 보낼수 있나?)

- 서킷스위칭(point-to-point)에서는 큐잉지연시간이 없음

- 패킷스위칭에는 큐잉지연시간 있다!

서킷 스위칭

위 그림에서의 서킷스위칭의 소요시간 순서

1. 회선 설정 시간(서킷 만드는 시간) : (서킷만드는 헤더 보내는 시간 + 서킷 만드는 시간 ) * 3 , 선투자 시간이라고 생각!

2. 다시 헤더가 Host2에서 Host1으로 돌아가는 시간.

3. 데이터를 보내는 시간 : 전파지연시간 + (데이터 Size / 대역폭)

데이터가 Host2에 다 도착한 순간을 종료시점으로 본다.

서킷 스위칭은 언제 좋을까?

- 데이터를 보낼게 많으면 서킷스위칭이 유리!

패킷 스위칭

- Set Up(사전준비) 시간이 필요 X

- Store & Forward : 사전 준비를 하지 않기 때문에 Packet이 다 올때까지 기다리다가 패킷이 다 도착하면 도착지 Address를 참조해서
합쳐서 보낸다

- 큐잉지연시간(Queueing Delay) : 마지막 비트가 도착하면 그제서야 Address(목적지)를 찾는다!

패킷스위칭(Pipelining)

패킷스위칭 with 파이프라이닝

- 패킷으로 보낼때 패킷 하나당 Header가 한개씩 무조건 필요하다!

- 파이프라이닝을 하지 않으면 패킷 하나 올떄까지 기다리는것은 너무 비효율적

- 패킷 사이즈를 줄여서 하나의 패킷을 여러 패킷으로 보내게 되면 위의 그림처럼 파이프라이닝으로 패킷을 보낼 수 있다.

네트워크 성능에 대한 정리

대역폭과 소요시간의 상대적 중요성

- 작은 메세지 : 소요시간이 중요 ⇒ 어차피 Bandwidth로 나눠도 엄청 작아서 기본적으로 소요시간이 중요해짐

- 큰 메세지 : 대역폭이 중요 ⇒ 데이터가 크면 보내는게 더 중요해서 헤더 붙이고 전파지연시간 조금 있는거 크게 안 중요함

네트워크 구조 - OSI 7계층 + Internet 구조

hoonding — Mon, 26 Dec 2022 20:01:40 +0900

프로토콜( Protocol )

통신에 사용되는 약속

- 수신호, 언어

- 양쪽이 같아야 함. 반드시 대칭 관계

다양한 컴퓨터통신 시스템/응용

- 프로토콜의 복잡화( 기능이 많아지면 프로토콜 양이 ⬆️ )

- 불명확한 해석

- 변경 등 관리의 어려움

- 새로운 프로토콜이 필요할 때마다 반복

복잡성을 해결하는 구조적인 기법이 필요하다!!

⇒ 프로토콜을 일반화해서 구조적인 기법을 도입하여 해결해야한다.

계층화( Layering )

복잡한 문제를 한번에 풀 수 없음

- 복잡한 문제를 숨겨서 문제를 단순화 → 추상화 ( Abstractions )

- 추상화된 문제의 해결→ 추상화를 Recursive하게 적용

추상화는 자연히 계층화를 유도

추상화의 장점

1. 확장, 수정을 할 때 편하다. (갈아끼기 쉽다)

2. 재사용이 가능하다!

통신 프로토콜 : 여러 계층으로 정의됨(b/c 너무 프로토콜이 복잡하기 때문)

각 계층은 하나의 기능을 하는 부품/개체로서 다른 프로토콜에서 재사용 가능

프로토콜 계층 / 개체

- 프로토콜을 구성하는 계층(전체), 프로토콜의 구성요소(일부) 둘 다 프로토콜이라고 부른다.

각 프로토콜 개체는 두 개의 다른 인터페이스를 갖는다.

1. 서비스 인터페이스(Service Interface) : 해당 프로토콜의 작업을 정의 (상위 계층에게 자신을 어떻게 쓰는지 알려주기)

2. 동료 인터페이스(Peer-to-Peer Interface) : 동료(Peer)간에 교환되는 메시지를 정의 ( 자신과 대칭인 상대방과의 통신 약속)

Interface

( 전체 ) 프로토콜 정의 : 프로토콜 그래프

프로토콜 그래프 or 스택

- 유사성이 있는 경우 하위 계층을 공유 가능

- 2 in 1 out ⇒ Mux

프로토콜 그래프 예시

- 그래프는 프로토콜의 모음(Collection)과 그들 사이의 의존관계(Depedency)로 구성된다.

- Peer간의 통신(Logical)은 간접적으로 통신된다( Peer통신 → Logical한 통신 )

- 실제(Physical) 통신은 하위 계층을 사용하여 이루어짐 ( Send Down to Low )

- 하드웨어 수준(1계층)에서만 동료간 통신이 직접적으로 이루어짐.

- 하위 프로토콜을 공유 ⇒ 계층화 돼있음!

Logical 통신 vs Physical 통신

- Logical : Peer-to-Peer Interface

- Physical : Service Interface

- 위의 그림에서 실질적으로 사장은 비서에게 넘기지만 왼쪽 사장은 같은 위치의 직무를 가진 오른쪽의 사장에게 보낸것을 생각해보면 됨.

사장 → 비서 : Service Interface

사장 → 사장 : Peer-to-Peer Interface

Logical Communication

Physical Communication

( 계층적 ) 프로토콜 : 동작 원칙

- 포장/캡슐화(Encapsulation) - 헤더(Header) / 바디(Body)

- 프로토콜은 무조건 대칭이어야함!!

헤더(Header)

→ 밑으로 내릴 땐 헤더(Header)를 하나씩 붙인다.

→ 자기에게 맞는 Header를 붙여야한다 ( b/c 상대 Peer의 의미를 해석하기 위해! )

→ Header의 크기는 각기 다르다. 만약 하는일이 많다면 헤더의 크기가 크고 복잡도도 크다!

→ 프로토콜마다 헤더가 다 다르다.

→ 상위 계층으로 올라갈땐 헤더(Header)를 하나씩 떼서 데이터를 본다!

→ 결국 헤더는 Peer-to-Peer 통신을 하기 위한 수단!!

추상화와 계층화는 왜 하는 걸까?

추상화

- 추상화 : 기능이 있다고 가정하자!

- 혼자 기능에 대한 구상을 다 할 필요가 없어짐.

- 기능이 하위 계층에서 제공된다고 가정하고 기능을 구현

계층화

- 계층화 : 여러 계층으로 나우어 각 계층이 각각의 기능을 담당한다.

- 하위 계층을 이용하고 자신의 기능을 포함해서 상위계층에 제공한다.

표준구조 : 7계층 모델 ( OSI Architecture)

OSI : Open Systems Interconnection Reference Model

표준 구조( 7계층 모델 )

7계층의 기능 및 정의

하위 계층이 문제 중 일부를 해결해주면 자신은 해결한 것을 받아서 다른 문제를 해결해서 또 그걸 상위 계층으로 보낸다.

1계층 : Physical(물리) 계층 → 신호, 비트

- 물리적인 신호 교환과 관련된 사항

- 신호 → 0, 1을 의미! 비트하나, 신호하나!

2계층 : Link(링크) 계층 → 프레임, 비트묶음

- 하나의 링크로 직접 연결된 노드 사이의 비트묶음(프레임) 교환

- 하나의 노드 & 하나의 노드에서는 각각의 2계층을 사용하면 된다!

- 1계층의 비트를 사용한다.

- 비트묶음 == 비트스트림을 교환!

- 스위치는 목적지를 정해야한다. → 3계층이 필요!

3계층 : Network(네트워크) 계층 - 패킷

- 네트워크를 통해 연결된 호스트 사이의 데이터(패킷) 교환

- Address를 붙여줘야함!! 그래야 스위치에서 어디로 보낼지 정할 수 있다.

4계층 : Transport(트렌스포트 )계층 → 중요한 계층!!

- Network Transparncy를 제공하는 계층.

- Process-Process간 Channel을 제공! → 믿을만 해야한다!

- End-Point(종단)과 종단 사이의 메시지 교환.

- 통신 응용 사이의 신뢰성 있는 메시지 교환 (검토)

- App - App 사이 ⇒ 신뢰성있는 메세지인지?

- App - A 사이의 연결부위 : End

- 종단(ex : 카카오)이 서로가 받은 데이터가 믿을만한가를 검토하는 계층.

- 스위치에 4계층이 있으면 안된다!!

→ 만약 스위치에 4계층이 있다면 우체국 아저씨가 편지뜯어서 맞춤법검사하는거랑 똑같은거임.

5계층 : Session(세션) 계층

- 대화 패턴과 관련된 사항 담당

- 회의를 하다보면 회의의 주체자가 필요

- 요청 ~ 응답 할때 응답하는 놈이 요청을 해버리면 안된다.

- 그래서 지금 누가 말하세요~~이런 느낌이 필요하다! 그걸 담당하는 것이 5계층!!

6계층 : Presentation 계층

- 데이터 표현 방법과 관련된 사항

- 응용(Application)에서의 데이터 표현 방법.

- A → B 로 보냈는데 A의 표현방식이 1이고 B의 표현방식이 2면 안된다!

- 그래서 데이터의 표현방식을 맞춰야한다.

7계층 : 응용 계층

- 응용 자체와 관련된 사항만

표준구조2 : Internet 구조 ⇒ 7계층을 따르는 것이 X

7계층 : 전화를 위해 만들어진 계층 구조.

Internet : 컴퓨터를 위해 만들어진 계층 구조.

응용 및 응용 프로토콜(FTP, HTTP) : IP의 경우 Network에 가깝다.

Internet 구조

Internet 구조의 특징

1. 7계층 모델을 그대로 따르지는 않음

2. 모래시계 형태의 모양

3. 설계와 구현을 병행해서 진행

4. 보통 IP 계층은 3.1계층이라고도 불림 ( 나중에 설명! )

IP : Internet Protocal

IP는 네트워크 여러개 사이를 연동하는 프로토콜이다.

그래서 4 & 3 사이다. 3.1정도 된다.

Host-to-Host에 가깝다. ↔ 4계층은 End to End(종단 종단)

OSI(7계층) 모델에 대해 설명하시오

1. 컴퓨터네트워크 설계/구현의 구조 체계 표준
- 실제 구현 X, 문제인식/설계에 참조하는 모델

2. 통신에 필요한 모든 기능/기술 요소를 7계층 구조로 배분

3. 각 계층의 설명
- 물리 계층 : 직접 연결된 노드 사이의 비트 전송
- 링크 계층 : 직접 연결 노드 사이의 프레임(비트묶음)을 전송
- 네트워크 계층 : 스위치로 간접 연결된 호스트 사이의 패킷 전송
- 트랜스포트 계층 : 종단간의(end-to-end)신뢰성 있는 전송 ( End(종단) : 응용이 연결되는 지점. )

네트워크의 요구사항(2)

hoonding — Sun, 25 Dec 2022 20:19:35 +0900

이전글 - 네트워크의 요구사항(1)

네트워크의 요구사항(1)

기본 개념 네트워크의 요구 사항 네트워크가 제공해야 하는 것 결국, 네트워크에 대한 기능적 정의 네트워크 요구사항 - 1번 연결(Connection) - 신호가 가기 위한 선행 단계. → 통신하려는 주체(Host

hoongding.tistory.com

어드레싱 및 라우팅(Addressing & Routing)

상대방 지정 : ID(=Address)를 지정
주소(Address): 노드를 식별하는 바이트열
라우팅(Routing) : 목적지 노드를 향해 메세지를 어떤식으로 포워딩할지를 주소에 입각해서 결정하는 작업.
라우팅 → 대충 목적지까지 어떤식으로 갈지 찾아본다.

어드레싱 VS 라우팅

어드레싱 : 상대방을 지정하는 것

라우팅 : 경로를 찾는 것(길을 찾는 것)

주소의 종류

유니캐스트(Unicast) : 특정 노드를 지정 (1 : 1)

브로드캐스트(Broadcast) : 네트워크의 모든 노드 (1 : N)

멀티캐스트(Multicast) : 네트워크의 일부 노드 집합을 지정 (N : N)

비용 효율적인 자원 공유(Resource Sharing)

여러 사용자들이 자원(노드 & 링크)을 공유하도록 해야함 ⇒ Multiplexing(다중화 지원)

- 데이터는 섞이면 안됨

- 분리를 완벽하게 해야함

다중화 정책 종류

TDM과 FDM

1. TDM(Time Division Multiplexing)

시분할 다중화
각 유저마다 돌아가면서 사용
모든 주파수를 사용
주파수 다중화보다 Gap이 훨씬 작다.

2. FDM(Frequency Division Multiplexing)

주파수 분할 다중화
각 유저마다 다른 영역의 주파수를 할당.
특정 주파수를 사용.
주파수 사이에 Gap이 있다!(효율 살짝 떨어짐)
하지만 요즘 주파수 사이의 공백을 매울 수 있게끔 기술이 발달했음.

3. 통계적 다중화(Statistical Multiplexing)

Async TDM(비동기식 시분할 다중화) : 각각의 시간에 할당된 것이 아니라 필요한 놈만 동적으로 할당을 한다.
시분할 방법의 일종
각각의 시간에 할당된 것이 아님.
필요한 놈만 Timeslot에 배치
요구에 따라 동적으로 할당(고정분할이 아님!!)

위가 동기식 아래가 비동기식(통계적 다중화)

통계적 다중화에서의 중간에 있는 빈칸

DMUX에서 Select, Key가 필요한데 DMUX KEY를 통계적 다중화에서는 추가해야한다.
Data를 보낼때 Key 설정시간 == Overhead 발생!!!
Scheduling Time을 소모해서 선택하도록 함 ⇒ Overhead 발생
동기식(Synchronous TDM)에서는 Key가 그냥 시간이라 KEY를 추가하는 시간은 필요없다.

동기식 다중화(TDM) : 데이터가 Burty하게 들어오니까 Traffic이 없을때 논다! -> 비효율적.

통계적 다중화는 언제 안좋을까?

1. 데이터가 끝없이 들어오면 Overhead 때문에 계속 빈공간이 생긴다. … 동기식이면 Overhead없다.

2. 하지만 데이터가 끝없이 들어오는건 일반적인 상황이 아니니까 보통 비동기식, 통계적 다중화가 더 좋다!!

MUX vs Splitting

MUX

- 링크에서 TDM/FDM 사용해서 한번에 보내준다.

- N inputs -> Link -> N outputs

- 작은 Input을 Merge 후 하나의 통로로 보냄.

Splitting

- MUX와 반대의 경우

- Point to Point 연결에서 대용량 데이터를 보낼때 사용함

- 여러 주파수에 데이터를 병렬적으로 보내서 수신하는 측에서 데이터 합치는 방법

- 복수개의 Link(Channel)을 사용한다.

EX) 유튜브 같이 큰 데이터… 이 방식으로 전송.

통계적 다중화 & 패킷 스위칭

통계적 다중화 : 링크를 어떻게 공유하는지에 대한 기술

패킷 스위칭 : 데이터 & 패킷을 어디로 보내는지에 대한 기술

- 노드가 목적지를 향해 데이터를 전달하는 방법

- 패킷 단위로 링크 사용을 재스케쥴링

- 링크에서는 거의 대부분 통계적 다중화가 일어남.

- 링크에서 통계적 다중화를 하려면 노드에서는 패킷 스위칭이 필요!

- 스케쥴링이 필요 : Store & Forward에서 저장한 후 스케줄링이 필요

- 버퍼링이 필요.

다른 출발지/소스(Source)로부터의 패킷들이 링크에서 섞이게 됨.

버퍼링 : 링크로 나가기 위해 경쟁하는 패킷들을 저장하는 것, 서킷방법에서는 버퍼링 필요X

통신 서비스 제공

통신의 주체

통신의 주체 : 응용 프로그램(Application)

따라서 네트워크는 응용 프로그램끼리 원활히 통신할 수 있는 기능을 제공해야함

- 통신기술을 기반으로 응용 프로그램이 요구하는 기능을 구현/제공

- 호스트 간의 연결을 프로세스 간의 통신 형태로 변환

결론 - 네트워크의 역할

1. Application 끼리의 연결을 지원해야함.

2. 링크 자원을 공유해야함.

3. 사용자에게 연결 그 이상의 서비스, 즉 응용프로그램이 원할히 통신할 수 있는 서비스를 제공해야함.

네트워크의 요구사항(1)

hoonding — Sun, 25 Dec 2022 19:16:56 +0900

기본 개념

네트워크의 요구 사항

네트워크가 제공해야 하는 것
결국, 네트워크에 대한 기능적 정의

네트워크 요구사항 - 1번

연결(Connection) - 신호가 가기 위한 선행 단계.

→ 통신하려는 주체(Host)들을 연결해야한다!

통신의 첫 단계!
통신의 주체
- 전화기 등의 단말기(= Host)
- 통신의 처음과 끝을 담당하면 단말기라고 한다!통신주체로 작용하는 휴대폰 → 단말기 역할.
- Ex)
  핫스팟을 킨 휴대폰 → 노드역할.
- 좀 더 일반적으로 통신 응용 : 카톡, 브라우져
  …최종목적지는 결국 통신응용(App)이다!

연결 방법 : 유선 vs 무선
통신망 구성 요소(물리적 연결 제공을 위한)
- Nodes(노드) : 단말기, 라우터, 범용 워크스테이션, 공유기, 스위치 → 여기서 단말기를 포함하는 이유 : 핫스팟 같은 일을 하기때문에 단말기까지 포함했다
- Links(링크) : 동축 케이블, 광케이블, 무선채널 링크는 Active한 일을 하지 않는다. 전달만!

직접 연결 : Direct Links

점대점 연결(Point to Point Network)

가장 간단한 네트워크
링크가 하나!
단점) O(n^2) - 단말기가 많아지면 링크가 너무 많이 필요하다.

다중 접근(Multiple Access Network)

장점) 점대점 네트워크보다 링크가 적게 필요!
단점) A-C가 통신중이면 B-D는 통신 불가!
→ 따라서 누가 누구랑 얼마나 사용할건지 정해놓고 써야한다

간접 연결 ( Indirect Connectivity ) : Switched Networking

1. 스위칭 네트워크 ( Switching Networks )

2. 인터네트워킹 ( Internetworks )

간접 연결 방법 : 스위칭 정책

서킷 스위칭 ( Circuit Switching ) : 전화 네트워크
- 스위치가 사전(데이터 보내기 전)에 Output Link에 전용 회선(용량) 확보
- 스위치가 링크-링크를 연결시켜준다.
- 비트스트림을 중단/간섭 없이 송/수신
- 기본적으로 point-to-point

패킷 스위칭 ( Packet Switching ) : 인터넷 / 우편
- 데이터를 묶음으로 전송 : 패킷
- 스위치 동작 : Store-and-Forward

사용자 입장 vs 네트워크 입장

사용자 입장 : 전용회선이 보장되는 Circuit을 사용하고 싶어함.

네트워크 입장 : 많은 사용자가 사용 가능하게 해주고 싶기때문에 Packet방식을 사용하고 싶어함.

Bursty Traffic 처리에 적합한 것은?

인터넷의 Data는 Bursty Traffic이니까 전용회선(Circuit) 만드는것은 너무 낭비다.

따라서 Packet사용하는게 굳.

트래픽의 특징? Bursty하다. 있다가 없다가 있다가 없다가 한다.

서킷 vs 패킷

	서킷(Circuit)	패킷(Packet)
스위치	1. 사전에 설정 → 간섭이 없다. 2. 트래픽이 없을 때 일을 하지 않고 논다(남이 못쓴다.) 3. 간섭/중단이 없다. 4. 쉬는시간 O (Bursty Traffic) 5. 성능이 일정	1. 사전에 아무런 설정을 하지 않는다. 2.매번 보내려는 데이터마다 스위치가 움직인다. 3. 중단/간섭에 대한 보장 X 4. 쉬는 시간 X 5. 성능이 일정하지 않음.
데이터 전송 형태	비트스트림이 물 흐르듯이 멈추지 않고 쭉 들어온다.	1. 데이터가 패킷형식으로 뚝뚝 끊겨서 잘려서 들어온다. 2. 이후 목적지(주소) 판별 후 보내준다.
관점	사용자 관점에서 Good. - 전용회선이 생겨서 간섭도 없고 좋다!	네트워크 관점에서 Good. - 많은 사용자가 사용할 수 있게끔 함.

다음 글 보러가기

네트워크의 요구사항(2)

이전글 - 네트워크의 요구사항(1) 네트워크의 요구사항(1) 기본 개념 네트워크의 요구 사항 네트워크가 제공해야 하는 것 결국, 네트워크에 대한 기능적 정의 네트워크 요구사항 - 1번 연결(Connecti

hoongding.tistory.com