인생은 단 한 번뿐, 대충 살아서는 행복할 수 없어!

제어 컴포넌트, 비제어 컴포넌트

정니정은니 — Tue, 5 Dec 2023 13:06:27 +0900

input같이 form 관련된 컴포넌트를 다룰 때 사용되는 개념

각각의 개념을 요약하자면,

제어 컴포넌트는 React로 폼 데이터를 관리하는 방식(useState)이고,
비제어 컴포넌트는 React의 상태를 사용하지 않고 폼 데이터를 관리하는 방식(useRef)이다.

useState로 불필요한 렌더링이 필요없는 경우에는 useRef를 사용하는 것이 더 좋으니
각각의 상황에 따라 선택하여 사용해보자!

제어 컴포넌트 VS 비제어 컴포넌트

<제어 컴포넌트> (useState)

사용자 입력을 기반으로 자신의 state를 관리하고 업데이트한다.

즉, 사용자의 입력을 받는 컴포넌트에 event 객체를 이용해 setState()로 값을 저장하는 방식이다.

사용자가 입력한 값과 저장되는 값이 실시간으로 동기화된다.

제어 컴포넌트의 값은 항상 최신값을 유지한다. 새로운 입력 값이 생길때 마다 상태를 새롭게 갱신한다.
이는 데이터와 UI에서 입력한 값이 항상 동기화됨을 알 수 있다.

  const [input, setInput] = useState("");
  const onChange = (e) => {
    setInput(e.target.value);
  };

  return (
    <div className="App">
      <input onChange={onChange} />
    </div>
  );
}

<비제어 컴포넌트> (useRef)

기존의 바닐라 자바스크립트와 크게 다르지 않은 방식이다.

우리는 바닐라 자바스크립트를 사용할 때 폼을 제출할때 (submit button)을 클릭할 때 요소 내부의 값을 얻어왔다.
비제어 컴포넌트 또한 이와 유사한 방식으로 사용된다.

비제어 컴포넌트는 값이 실시간으로 동기화 되지 않는다.

필드에서 값을 트리거 해야 값을 얻을 수 있다. 사진에선 [전송] 버튼을 클릭하면 console에 값이 찍힌다.
[전송]버튼을 클릭해 트리거 하기 전까지의 값은 변경되지 않는다.

export default function App() {
  const inputRef = useRef(); // ref 사용
  const onClick = () => {
    console.log(inputRef.current.value);
  };

  return (
    <div className="App">
      <input ref={inputRef} />
      <button type="submit" onClick={onClick}>
        전송
      </button>
    </div>
  );
}

제어 컴포넌트 ⇒ 사용자가 입력을 하는 액션을 취할때마다 리렌더링을 발생시킴
비제어 컴포넌트 ⇒ 사용자가 직접 트리거 하기 전까지는 리렌더링을 발생시키지도 않고 값을 동기화 시키지도 않음(클릭을 해야함)

1. 즉각적으로 값에 대한 피드백이 필요하다. => 제어 컴포넌트 사용 (useState)
ex) 즉각적인 유효성 검사, 버튼 disable처리, input에 숫자만 입력가능한 상황

2. 즉각적인 피드백이 불필요하고 최종적인 값만 필요하다. 불필요한 렌더링 필요없다. => 비제어 컴포넌트 사용 (useRef)
ex) [전송]버튼 클릭 후, 값 체크

- 참고

https://velog.io/@yukyung/React-제어-컴포넌트와-비제어-컴포넌트의-차이점-톺아보기

Map()과 Set(), iterable 객체

정니정은니 — Mon, 4 Dec 2023 13:13:17 +0900

순회 가능한 객체 = iterable 객체

내부 요소를 하나씩 차례로 반환할 수 있는 객체이다.

for of 루프를 통해 각 요소를 차례로 순회할 수 있다.

ex) 배열(Array), 문자열(String), Map, Set

일반객체는 iterable 객체가 아니다.

일반객체는 각 요소를 순회하려면 Object.keys / Object.values / Object.entries 사용하고 그 다음에 for of 루프를 적용하면 된다.

Map = 키-값 쌍을 저장하는 자료 구조

순회 가능한(iterable)객체여서 for...of문을 사용하여 Map의 내용을 순회할 수 있다.

- 특징

키의 타입 유연성: 어떤 타입의 키도 허용한다. 객체나 함수 등도 키로 사용할 수 있다.

순서 보장: 원소를 추가한 순서대로 순회된다. 이는 객체가 키의 순서를 보장하지 않는 것과 대조적이다.

크기 측정: size 프로퍼티를 통해 저장된 항목의 개수를 쉽게 알 수 있다. ⇒ console.log(userMap.size); // 2

가독성과 성능면에서 이점을 얻을 수 있다.
다만, 단순한 키-값 저장이 목적이라면 여전히 객체를 사용하는 것도 유효한 선택일 수 있다.

// 키-값 쌍을 저장할 때
const myMap = new Map();
myMap.set('key1', 'value1');
myMap.set('key2', 'value2');

// 키의 타입 유연성
const objKeyMap = new Map();
const keyObj = { id: 1 };
objKeyMap.set(keyObj, 'Value associated with an object key');
console.log(objKeyMap.get(keyObj)); // Value associated with an object key

// 순서 보장
const orderedMap = new Map([
  ['three', 3],
  ['one', 1],
  ['four', 4],
  ['two', 2],
]);

for (const [key, value] of orderedMap) {
  console.log(key, value);
}
// three 3
// one 1
// four 4
// two 2

Set = 중복없이 유일한 값을 저장하는 자료 구조

순회 가능한(iterable)객체여서 for...of문을 사용하여 Set의 내용을 순회할 수 있다.

Set 내의 값은 모두 유일해야한다.

Set은 순서가 있는 열거 가능한 요소의 집합이다.

- Set으로 배열에서 중복을 제거할 때

const array = [1, 2, 3, 1, 2, 4, 5];
const uniqueArray = [...new Set(array)];

Set을 이용하여 중복을 제거한 후, 전개 연산자(...)를 사용하여 다시 배열로 변환한다.
결과적으로 uniqueArray는 중복이 제거된 배열이 저장된다.

- Set 생성하기

const uniqueNumbers = new Set();

- 값 추가하기 (add 메서드)

uniqueNumbers.add(1);
uniqueNumbers.add(2);
uniqueNumbers.add(3);
uniqueNumbers.add(1); // 이미 존재하는 값을 추가해도 무시됨 (중복 허용 X)

- 값이 존재하는지 확인하기 (has 메서드)

console.log(uniqueNumbers.has(2)); // true
console.log(uniqueNumbers.has(4)); // false

- 값 삭제하기 (delete 메서드)

uniqueNumbers.delete(2);

- Set 비우기 (clear 메서드)

uniqueNumbers.clear();

- Set의 크기 확인하기 (size 프로퍼티)

console.log(uniqueNumbers.size); // 2 (삭제된 값이 반영되지 않은 크기)

- Set 순회하기 (for...of문 또는 forEach 메서드 사용)

for (const number of uniqueNumbers) {
  console.log(number);
}

// 또는 forEach 메서드 사용
uniqueNumbers.forEach((number) => {
  console.log(number);
});

리액트 렌더링 최적화

정니정은니 — Tue, 14 Nov 2023 21:43:20 +0900

리액트 랜더링 최적화에 대해 알아보기 전에 알아야할 사전지식을 먼저 정리하고 시작한다.

- 리액트에서의 렌더링 = 함수를 호출하는 것

App 컴포넌트가 호출되고 -> 내부 로직들이 싱행되고 -> return문의 리액트 element 반환하는 것
이것이 리액트에서의 렌더링이다.

- 리렌더링 되는 조건

1. state가 바뀌었을 때

2. props가 바뀌었을 때

3. 부모컴포넌트가 바뀌었을 때

- 불필요한 렌더링 발생 확인 지표

1. console.log

2. React Developer Tools → Profiler

: 웹사이트의 컴포넌트들이 어떻게 렌더링되고 있는지를 보여주는 도구
: 어디 부분에서 렌더링이 오래 걸리고 불필요한 렌더링이 걸리는지 확인해야 한다면 용이!

- 리액트에서의 렌더링 과정

1. render phase = 재조정

컴포넌트를 호출하여 React Element를 반환하고 새로운 Virtual DOM을 생성한다.

만약, 이번이 첫번째 렌더링이 아니라면!!
이전 Virtual DOM과 현재 Virtual DOM을 비교하는 재조정 과정을 거친 후,
Real DOM에 변경이 필요한 목록들을 체크해둔다.

2. commit phase

render phase에서 체크해놓았던 변경이 필요한 부분들을 Real DOM에 반영해주는 단계!!!
만약, 변경이 필요한 부분들이 없다면 commit phase는 skip 된다.

불필요한 렌더링 방지하기

여기 세개의 컴포넌트가 있다.

부모요소인 Parent 컴포넌트, 자식요소인 FirstChild 컴포넌트, SecondChild 컴포넌트이다.

valueForFirstChild state에게 변경이 생기면
Parent 컴포넌트와 FirstChild 컴포넌트는 본인들이 사용하는 값(state, props)에 변경이 생겨서
변경이 된 값을 보여줘야하므로 리렌더링이 되는 것이 당연하다!

그런데 SecondChild 컴포넌트 입장에서는 변경된 값(state, props)도 없는데
똑같은 정보를 보여주기 위해 리렌더링 되는 게 불필요해 보인다.
더불어서 SecondChild 컴포넌트가 리렌더링이 되면 약 1000개의 GrandChild 컴포넌트들도 리렌더링이 될 것이다.

SecondChild 컴포넌트는 Parent 컴포넌트의 변경된 state가 아닌 함수만을 props로 받고 있기 때문에
리렌더링이 안될 것도 같지만 리렌더링이 되고있다.
왜냐하면 Parent 컴포넌트가 매번 리렌더링 될 때마다 handleClick이라는 함수도 재생성이 되고
이전 handleClick과 현재 handleClick 함수는 서로 다른 참조값을 가지게 되며 이 둘은 서로 다른 함수이다.
즉, handleClick도 props이니 달라지면서 컴포넌트가 리렌더링 되는 것이다.

handleClick 함수의 참조값이 바뀌지 않도록 해주면 불필요한 리렌더링을 방지해 줄 수 있지 않을까?
어떻게 매번 리렌더링 될 때마다 함수의 참조값을 유지할 수 있을까?

함수를 메모이제이션 해주는 useCallback 사용하자!!

근데.. console.log를 찍어보니 여전히 리렌더링이 되고있다.
그렇다면 효과가 전혀 없는 것일까? 아니다. 그래도 효과는 있다.
render phase는 실행되지만 commit phase는 실행되지 않는다.

더 자세히 설명하자면
리액트에서 렌더링이 일어날 때마다
render phase와 commit phase의 렌더링 프로세스를 거치게 되는데
render phase는 실행되지만
useCallback을 활용해서 props 값을 이전과 같게 유지해주었기 때문에
render phase의 재조정과정에서 Real DOM에 변경이 필요하지 않다고 판단을 해준다.
그래서 commit phase는 실행되지 않는다.

render phase도 막아줄 수는 없을까? 아직도 SecondChild 컴포넌트가 리렌더링 되고있는데..

React.memo도 사용하자!!!!

React.memo는
전달받은 props가 이전 props와 비교했을 때 같으면 컴포넌트의 리렌더링을 막아주고
마지막으로 렌더링된 결과를 재사용하는 고차 컴포넌트이다.

이 과정에서 props를 비교할 때 기본적으로 얕은 비교를 통해서 진행한다.
얕은 비교란 원시타입은 값이 다른지 비교하고 참조타입은 참조값이 같은지 비교하는 것이다.
(콜스택만 비교한다. 메모리힙은 비교하지 않는다.)

SecondChild 컴포넌트에 React.memo를 적용하면
SecondChild 컴포넌트가 렌더링 과정에 진입하기 전에
props 값인 onClick에 대해서 이전 값과 현재 값이 다른지를 비교해준다.
서로 같은 값이면 SecondChild 컴포넌트의 렌더링 과정은 진행이되지 않는다.

그렇다면.. 함수가 아닌 객체를 props로 넘겨주게 된다면 리렌더링이 발생할까?

리렌더링이 발생한다..!! 왜 그럴까..?

SecondChild 컴포넌트 입장에서는 Parent 컴포넌트로부터 매번 다른 item을 전달받기 때문이다.

Parent 컴포넌트가 리렌더링 될 때마다
item 객체가 새로 생성이 되고 매번 다른 참조값을 가지게 되는 것이다.
그래서 React.memo가 정상적으로 작동되지 않는다.

객체 props에 React.memo가 정상적으로 작동되게 하기 위해서는

⇒ 값을 메모이제이션해주는 useMemo를 사용하자!

이렇게 useCallback, React.memo, useMemo로 렌더링 최적화하는 방법에 대해 알아보았다.

그렇지만.. 이를 남발하는 것은 좋지 않다...!!!!

이 또한 하나하나가 메모리를 차지하고 비용이 드는 것이다.

잘못 사용한다면 최적화가 아니라 오히려 더 성능을 망칠 수가 있다.

리렌더링이 자주 되는 컴포넌트라고 해서 컴포넌트 내부의 함수를 무작정 useCallback으로 감싸주는 경우,
부모로부터 전달받은 props가 매번 바뀔 수 밖에 없는 상황에서 자식 컴포넌트에 React.memo를 적용해주는 경우에서는
최적화를 시도하기 전보다 웹 사이트 성능이 더 안 좋아질 수도 있다.

제대로 이해를 하고 써야하는데 사실 복잡한 로직 속에서 이를 제대로 쓰기란 쉽지 않을 것이다.

그래서 useCallback, React.memo, useMemo를 사용하기 전에,

코드적으로 개선할 수 있는 방법은 리팩토링을 해서 개선하도록 해야한다.

예를들어, 불필요하게 리렌더링이 되는 자식요소는 children으로 주입하자!
이렇게 리팩토링 해주면 리렌더링 되지 않는다.
왜냐하면 부모컴포넌트 return문에는 children에 대한 React.createElement가 존재하지 않기 때문에
부모 컴포넌트가 렌더링되더라도 자식 컴포넌트는 호출되지 않기 때문이다.

가장 중요한 것은..
미리 성급하게 최적화를 하지않고 정말 최적화가 필요할 때 최적화를 해주는 것이다.

너무나도 많은 도움이 된 테코톡 앨버님의 영상!! 너무 감사합니다

https://youtu.be/1YAWshEGU6g?si=sWHdyM1A4YhVvKjT

주소창에 google.com을 입력하면 일어나는 일

정니정은니 — Tue, 14 Nov 2023 16:42:20 +0900

주소창에 google.com을 입력하면 일어나는 과정을 공부했다.

생각보다 너무너무..!!!! 복잡했다..
10개 넘는 블로그, 5개 넘은 동영상을 시청하며 드디어 이 과정을 나름대로 이해하고 정리할 수 있었다.

일단은 비교적 간단하게 정리해보았지만 하나하나 더 깊게 들어가서 마스터 하고싶다.

1. 사용자가 웹 브라우저를 통해 www.google.com(URL)을 입력한다.

2. 브라우저는 먼저 4단계의 캐싱된 DNS 기록을 확인한다.

- 4단계

브라우저 캐시 → OS 캐시 → router 캐시(집에서 사용하는 공유기) → ISP 캐시(SK 브로드밴드)

- 왜 이런 캐시들이 있을까? 인터넷 스피드를 최대한 빨리 하기 위해서!

3. 있다면 DNS 서버로 연결하지 않고 IP 주소를 반환한다.

4. 없다면 ISP의 DNS 서버가 IP 주소를 찾기위해 DNS 쿼리를 날린다.

DNS Recursor(= DNS 서버)가 아래와 같은 순서로 com부터 역순으로 물어보며 IP 주소를 찾는다.
(이를 Recursive search라고 한다.)
: Root domain(.) → Top-level domains(com) → Second-level domains(google) → Third-level domains(www)

5. DNS 서버는 사용자가 입력한 URL 정보와 함께 IP 주소를 전송한다.

6. 브라우저가 서버와 TCP 연결을 한다.

: TCP 연결은 송신자와 수신자간의 연결에 신뢰성을 유지할 수 있도록 해준다.
: 즉, 클라이언트와 서버간 데이터 패킷들이 오가려면 TCP 연결이 되어야한다.
: TCP 연결 방법은 3 way handshaking으로 한다.
: 클라이언트와 서버가 SYN(연결요청)과 ACK(승인)로 3번의 프로세스를 거친 후 연결이 된다.

- 3 way handshaking
(1) 클라이언트가 SYN 신호보내며 연결 가능한지 묻고
(2) 서버가 SYN과 ACK를 응답하고
(3) 클라이언트가 서버에게 잘 받았다고 ACK를 보낸다.

이렇게 서로 안전하게 정보를 교환할 수 있는 길이 연결되는 것이다.

7. TCP 연결이 된 후, 브라우저가 웹 서버에게 HTTP 요청을 한다.

: 요청 헤더에 요청에 대한 정보(URL, Method)와 클라이언트에 대한 정보(accept, user-agent, cookie)를 담아서 함께 보낸다.
: 저는 헤더에 이러이러한 스택을 가진 클라이언트인데 구글 홈페이지를 get 하고 싶습니다. 라고 말하는 것이다.
: accept) 어떤 타입의 응답 컨텐츠를 수용할 수 있는지
: user-agent) 브라우저 버전 및 종류, 운영체제 종류
: cookie) 브라우저에서 얻은 쿠키 정보

8. 서버가 브라우저의 요청 헤더를 확인하고 HTTP 응답을 한다.

: 응답 헤더) 응답에 대한 부가적인 내용들
: 응답 바디) HTML 문서
: 상태 코드) 서버 요청에 따른 상태

- 상태 코드

1xx: (정보) 요청을 받았으며 프로세스를 계속한다.
2xx: (성공) 요청을 성공적으로 받았으며 인식해서 처리했다.
3xx: (리다이렉션) 요청 완료를 위해 추가 작업 조치가 필요하다.
4xx: (클라이언트 에러) 요청의 문법이 잘못되었거나 요청을 처리할 수 없다.
5xx: (서버 에러) 서버가 명백히 유효한 요청에 대해 충족을 실패했다.

9. 브라우저는 서버에게 응답받은 리소스로 파싱하여 화면에 렌더링을 한다.

기타 개념들

DNS 서버 (Domain Name System)

도메인 이름과 IP 주소에 대한 정보를 관리하는 시스템으로 DNS가 도메인 네임을 IP 주소로 바꿔줘서 인터넷 사용자는 어려운 IP 주소를 몰라도 이런저런 사이트에 쉽게 접근할 수 있다.

DNS 동작 과정

브라우저는 먼저 브라우저의 캐쉬에 해당 도메인의 IP 주소를 가지고 있나 확인한다. → 없으면 DNS 서버에게 IP를 요청한다.

DNS 계층 구조: 도메인을 계층적이게 관리하여 서버를 분리한다.

계층의 탐색 순서는 거꾸로 탐색한다.

뒤에서부터 해당 도메인 이름에 맞는 지역 DNS를 탐색하며, root DNS 서버가 나올때까지 거꾸로 탐색한다.

참고한 블로그 및 영상

https://youtu.be/YahjHM9UNCA?si=Mtx1Hk1jCsmoOysC

https://aws-hyoh.tistory.com/entry/TCPIP-쉽게-이해하기

TCP/IP 쉽게 이해하기

IT 분야에서 실무를 담당하시는 분들뿐만 아니라 학생, IT 쪽에 조금이라도 관심이 있는 분들이라면 TCP/IP에 대해 들어보셨을 겁니다. 저 또한 학부시절에 TCP/IP에 대해서 여러 번 들어보았는데요.

aws-hyoh.tistory.com

https://velog.io/@eassy/www.google.com을-주소창에서-입력하면-일어나는-일

'www.google.com'을 주소창에서 입력하면 일어나는 일

_개발자로서 웹이 어떤 과정으로 동작하게 되는지, 무슨일이 어떻게 일어나는지에 대해 제대로 이해하지 못한 채 그냥 만들고 보여지는데에만 집중했던 것 같다. 어느 정도 큰 그림으로라도 이

velog.io

https://youtu.be/0jV7xOUcKog?si=5fpGxzq1l1QkDlB2

동기와 비동기, 자바스크립트에서 비동기 처리가 가능한 이유, 비동기 프로그래밍

정니정은니 — Sat, 11 Nov 2023 15:53:34 +0900

동기와 비동기

- 동기 처리: 반드시 코드가 작성된 순서대로 진행된다.

장점: 실행 순서 보장
단점: 블로킹 발생, 하나의 작업이 너무 오래 걸리게 되면 오래 걸리는 하나의 작업때문에 모든 작업이 올스탑되어 처리속도가 매우 느려져 성능 상에 문제가 발생하게 된다.

- 비동기 처리: 현재 실행중인 코드가 완료되지 않더라도 기다리지 않고 다음 코드를 실행하는 방식이다.

실행중인 태스크가 종료되지 않은 상태라 해도 다음 태스크를 곧바로 실행한다.

이벤트 핸들러, setTimeout, setInteraval, HTTP 요청은 비동기 처리 방식으로 동작한다.

장점: 블로킹 발생 X
단점: 실행 순서 보장 X

그런데 싱글스레드인 자바스크립트에서 어떻게 비동기 처리가 가능할까?

자바스크립트 엔진은 싱글스레드라서 실행 대기 중인 태스크가 쌓이는 콜스택(실행컨텍스트 스택)을 하나만 가지고 있다. 최상단부터 하나씩 실행되기 때문에 한번에 하나의 태스크만 실행 가능하다. 동시에 여러개의 함수를 실행할 수 없다!

브라우저 내부에는 자바스크립트 엔진의 싱글스레드의 한계를 극복하기 위해 비동기로 동작할 수 있도록 web APIs, 콜백큐, 이벤트 루프를 제공한다. 즉, 브라우저 내부에는 자바스크립트 엔진을 뿐만아니라 이벤트 리스너, setTimeout 같이 기다림이 필요한 비동기 함수들이 들어가는 Web APIs, 그러한 비동기 함수들이 차례차례 쌓이는 콜백큐, 콜스택이 비워질 때를 체크해서 콜백큐에 대기중인 비동기 함수를 콜스택에 보내주는 이벤트 루프가 있다. 이벤트 루프는 이 작업을 반복(loop)하고 이러한 브라우저의 동작원리 덕분에 자바스크립트가 싱글 스레드 언어여도 비동기 작업을 처리할 수 있도록 해주는 것이다.

비동기 프로그래밍이란?

비동기적으로 실행되는 것을 동기적으로 코딩하는 방법이다.

비동기 프로그래밍이 중요한 이유는
서버에 요청한 데이터가 도착하기 전에도 사용자와의 인터랙션을 유지할 수 있으므로 사용자 경험을 향상시킬 수 있게 된다.

예를 들어 이미지가 렌더링되는 동안 사용자는 또 다른 작업을 할 수도 있다.

비동기 프로그래밍 방법

1. Callback 함수 ex) 이벤트리스너, setTimeout

정의: 함수의 파라미터로 들어가는 함수

용도: 순차적으로 실행하고 싶을 때

단점

: 여러개의 비동기를 처리할 때 콜백지옥 발생

: 가독성 저하

: 에러핸들링 어려움

: 함수 안에서만 결과값 처리와 결과값을 알 수 있어서 매번 비동기함수를 싱행해야함

2. Promise 객체 (ES6)

비동기 작업의 결과값이 Promise 객체에 저장되기 때문에
로직 밖에서도 .then 메소드를 통해 저장되어 있는 성공(resolve 반환), 실패(reject 반환) 결과값을 원하는 때에 사용할 수 있다.

성공 시, then 메소드 실행
실패 시, catch의 메소드 실행
→ 하나의 catch만으로 상위에 체이닝되어있는 어떤 함수에서 에러가 나더라도 에러 핸들링이 가능하다.
성공 실패 여부 상관없이, finally 메소드 실행
→ 무조건 실행되어야 할 로직을 짜는 곳에 사용된다.

- Promise의 3가지 상태

pending : 비동기 처리 미완료(ful,rej 이전)
fulfilled: 비동기 처리 성공: resolve 호출, then에 비동기 처리 결과를 전달
rejected : 비동기 처리 실패, 오류: reject 호출, catch에 에러 결과를 전달

- 단점: 지나친 then의 사용은 콜백지옥과 비슷한 문제가 발생한다.

3. async/awail (ES8)

좀 더 쉽고 직관적으로 Promise를 이용할 수 있다. 가독성이 좋다.

Promise의 후속처리메소드 없이, 마치 동기적으로 Promise를 사용할 수 있다.

- 사용법

함수 앞에 async를 붙혀주면 그 함수는 자동적으로 Promise를 리턴하는 비동기 처리 함수가 된다.
await 키워드는 promise가 resolve한 결과값을 반환한다.
await을 비동기 함수의 호출 앞에 붙히면 await이 붙은 함수의 호출은 뒤에있는 함수가 끝나기 전까지 아래에 있는 코드를 수행하지 않는다.
Promise의 후속처리메소드 없이, 마치 동기적으로 Promise를 사용할 수 있다.
await는 실패하면 에러가 나고 코드가 멈추기때문에 try/catch를 사용하여 에러 처리를 할 수 있다.
then과 달리 어떤 지점에서 에러가 발생했는지 쉽게 찾을 수 있다.

리액트의 재선언, Virtual DOM 동작원리, Diffing 알고리즘

정니정은니 — Sat, 11 Nov 2023 12:11:09 +0900

리액트가 빠른 반응형 웹이 될 수 있었던 이유는 Virtual DOM 덕분이다.

Virtual DOM이 변화한 부분만 캐치하여 최소한의 변경사항만 Raal DOM에 업데이트 해주기 때문이다.

이는 맞는 말 이지만...
너무 겉햛기식으로만 Virtual DOM을 이해하고 있기에 이번에 더 깊게 Virtual DOM을 공부해보았다.

Virtual DOM 관련하여 테코톡에 세 개의 영상이 올라와 있었고
세 영상으로 더 깊게 알게된 Virtual DOM에 대해 정리해보려고 한다!

(테코톡 최고..)

Virtual DOM 등장이유

과거에 비해 현대의 웹 페이지는 UI/UX가 굉장히 매력적이고 복잡하다.
이러한 웹 페이지의 브라우저 렌더링 과정에서의 문제는
DOM에 변화가 발생할 때마다 렌더트리가 재생성되고 모든 요소들의 스타일을 다시 계산하고 Reflow, Rapaint 과정을 반복하게 된다는 것이다.
브라우저 렌더링 과정은 생각보다 복잡하고 비용이 큰 작업인데.. 이는 정말 비효율적인 방식이었다.
그래서 DOM 업데이트를 어떻게 더 효율적으로 할 수 있을까?라는 고민에서 Virtual DOM이 등장했다.

Virtual DOM 이란?

오른쪽의 이미지가 바로 Virtual DOM 이다.
Virtual DOM은 DOM 트리를 복제하여 메모리에 저장시킨 자바스크립트 객체이다.
DOM 정보인 tagName, attributes, 자식들에 대한 정보는 가지고 있지만
DOM 조작 메서드인 innerHTML, replaceChildren 같은 거는 없다.
즉, Real DOM을 경량화 시킨 것이다.
자바스크립트 객체이기에 브라우저에서 직접 수정되지 않는다.
메모리 상에서 변경사항을 계산하고 Virtual DOM을 통해 변경된 것들만 식별하여 DOM 업데이트를 한 번 시킨다.
즉, Reflow를 한번 시켜서 연산비용을 줄여 성능이 개선된다.

Virtual DOM 동작과정 = 재조정

JSX를 Babel을 이용하여 JS코드로 변환하면 React.createElement 함수를 호출하게 된다.
호출되어 결과적으로 자바스크립트 객체가 나오는데 이 자바스크립트 객체가 Virtual DOM이다.
이렇게 생성된 Virtual DOM을 ReactDOM 라이브러리의 render 메서드를 통해 실제 DOM에 반영한다.
변경이 되면 React가 컴포넌트의 변화를 감지하고 상태가 변경된 컴포넌트의 Virtual DOM을 업데이트 시킨다.
이후 업데이트 전과 후의 Virtual DOM을 비교하는 과정을 거치게 된다.
업데이트 후와 전의 Virtual DOM을 비교하는 과정은 Diffing 알고리즘을 통해 거친다.
Diffing 알고리즘은 type부터 확인을 한다.
1. type이 같다면, 두 Virtual DOM의 엘리먼트 속성을 확인하여 동일한 내역은 유지하고 변경된 속성들만 갱신한다. 이어서 해당 노드의 자식들도 처리힌다.
2. type이 다르다면, 이전 Virtual DOM을 버리고 완전히 새로운 Virtual DOM을 생성한다.
이러한 과정을 통해 변경된 내용만 Virtual DOM에 반영하여
그 Virtual DOM을 다시 ReactDOM 라이브러리를 이용해 render 메서드를 통해서 변경된 것이 보이게 된다.

- 참고영상

1. 테코톡 엽토님

https://youtu.be/Bdk7QzbbcEI?si=MMAOzqMYAmSHpeih

2. 테코톡 지그님

https://youtu.be/PN_WmsgbQCo?si=LPOcRBJCEc_bSNyt

3. 테코톡 돔하디님

https://youtu.be/6rDBqVHSbgM?si=t_S-xZmPdg317IWQ

호이스팅, 호이스팅 원인, 호이스팅 종류

정니정은니 — Sun, 5 Nov 2023 14:30:33 +0900

첫 콘솔을 보면 var는 undefined가 찍힌다.
이처럼 선언 라인 전에도 변수를 참조할 수 있는 현상을 '호이스팅' 이라고 한다.

var 키워드는 선언과 함께 undefined로 초기화되어 메모리에 공간을 확보한다.
let과 const 키워드는 선언만 되고 초기화되지 않은 상태로 선언만 환경레코드(메모리)에 등록된다. (선언 라인에 도달하기 전에는 메모리에 공간을 확보하지 못한다.)

자바스크립트의 모든 선언에는 호이스팅이 일어나지만 let, const를 이용한 선언문을 호이스팅이 발생하지 않는 것처럼 동작한다.
let, const 키워드로 선언된 변수를 선언문 이전에 참조하면 참조 에러(ReferenceError)가 발생하는데
이는 let과 const에도 호이스팅이 일어나기 때문에 에러를 일으키는 것이다.

let, const 키워드로 선언된 변수는 스코프의 시작에서 변수를 위한 메모리 공간이 확보되기(초기화 단계)까지 일시적 사각지대(Temporal Dead Zone; TDZ)에 빠진다.

- 원인

자바스크립트 엔진이 먼저 전체 코드를 스캔하면서 변수같은 정보를 실행컨텍스트의 환경레코드에 미리 등록해놓는다.

환경레코드: 식별자와 식별자에 바인딩된 값을 기록해두는 객체

- 변수는 어떻게 생성될까?

변수는 3단계에 걸쳐 생성된다. (선언: 실행컨텍스트의 레코드에 등록 → 초기화: 메모리 공간 확보 → 할당)

1. var

var는 선언과 초기화가 한번에 이루어진다.
즉, 스코프에 변수를 등록하고 메모리에 변수를 위한 공간을 확보한 후, undefined로 초기화한다.
따라서 변수 선언문 이전에 변수에 접근하여도 스코프에 변수가 존재하기 때문에 에러가 발생하지 않는다.
다만 undefined를 반환한다. 이후 변수 할당문에 도달하면 비로소 값이 할당된다.

2. const, let

const, let은 선언과 초기화가 따로 이루어진다.
즉, 스코프에 변수를 등록하지만 초기화 단계는 변수 선언문에 도달했을 때 이뤄진다.
초기화 이전에 변수에 접근하려고 하면 참조 에러가 발생한다.
변수를 위한 메모리 공간이 아직 확보되지 않았기 때문이다.
따라서 스코프의 시작 지점부터 초기화 시작 지점까지는 변수를 참조할 수 없다.
스코프의 시작 지점부터 초기화 시작 지점까지의 구간을 ‘일시적 사각지대(Temporal Dead Zone; TDZ)’라고 부른다.

- 호이스팅 종류

1. 변수 호이스팅 (var VS const, let)

- var 호이스팅

변수를 생성할 때, 환경레코드에 선언과 초기화를 동시에 한다. 그래서 선언 라인 전에 접근해도 undefined가 찍힌다.

- const, let 호이스팅

변수를 생성할 때, 선언만하고 초기화는 하지 않는다. 그래서 선언 라인 전에 접근(참조)하면 Reference Error가 발생한다.

- 일시적 사각지대

let, const로 선언한 식별자는 선언 라인 이전에 참조할 수 없는데, 이 구역을 '일시적 사각지대'라고 부른다.

즉, var는 선언과 초기화가 동시에 이루어진다.
let, const는 선언만하고 초기화는 하지 않는다. 그래서 선언 라인 전에는 변수를 참조할 수 없다.

2. 함수 호이스팅: 함수 표현식(var VS const, let), 함수 선언문

- 함수 표현식

: 함수를 변수에 담을 수 있다. 변수 호이스팅과 동일하게 동작한다.

(1) var 함수 표현식: 선언문 이전에 실행하려고 하면 환경레코드에 메모리 공간이 확보되어 있는 값이 undefined이고 undefined라는 데이터 타입은 함수와 달리 호출될 수 없어서 타입에러가 발생한다.

(2) const, let 함수 표현식: 아직 환경레코드에 메모리 공간이 확보되어 있는 값이 없어 Reference Error가 발생한다.

- 함수 선언문

: 선언과 동시에 함수가 생성되어 선언 전에도 함수를 사용할 수 있다.

: 선언과 동시에 완성된 함수 객체를 생성해서 환경레코드에 메모리 공간이 확보한다. 함수가 에러없이 실행된다. 그래서 사용을 지양해야한다!!!

- 함수 표현식과 함수 선언문의 차이점

1. 함수 표현식은 var 키워드 일 때는 환경레코드의 값을 undefined로 초기화해두는데 undefined를 호출하려해서 Type Error가 나고, let&const 일 때는 환경레코드에 값을 초기화해두지는 않아서 참조하려니까 Reference Error가 난다.

2. 함수 선언문은 선언과 동시에 함수 생성을 마치고 온전히 환경레코드에 메모리 공간을 확보해서 저장해두기에 선언 라인 전에도 함수를 호출할 수 있다.

참고
- 하나몬님: https://hanamon.kr/javascript-%ED%98%B8%EC%9D%B4%EC%8A%A4%ED%8C%85%EC%9D%B4%EB%9E%80-hoisting/

[JavaScript] 호이스팅(Hoisting)이란? - 하나몬

❗️호이스팅이란? 호이스팅은 코드를 실행하기 전 변수선언/함수선언을 해당 스코프의 최상단으로 끌어올리는 것이 아니다. 호이스팅은 코드가 실행하기 전 변수선언/함수선언이 해당 스코프

hanamon.kr

- 테코콕 하루님 : https://youtu.be/EWfujNzSUmw?si=ICfUnYVPczB2HqTh

실행컨텍스트, 호이스팅, 스코프체이닝 (feat. 테코톡 하루님)

정니정은니 — Sat, 4 Nov 2023 15:29:26 +0900

실행컨텍스트, 호이스팅, 스코프체이닝을 완벽하게 이해하고 싶은데
호이스팅, 생성 단계, 실행 단계, 선언, 초기화, 일시적 사각지대, 함수 표현식, 함수 선언문, 식별자 결정, 스코프 체인, 스코프 체이닝 등의 여러 개념들이 얽혀있어서 정리가 잘 안됐다.

그런데 테코톡에서 하루님께서 실행컨텍스트를 발표해주신 영상을 보고 속이 시원할정도로 이해가 쏙쏙 잘됐다. 너무 감사했다..ㅠㅠ
그래서 이 영상을 보며 개념을 정리해보았다!

https://youtu.be/EWfujNzSUmw?si=ICfUnYVPczB2HqTh

실행컨텍스트에는 Record가 있고 Outer가 있다. 이를 먼저 이해하면 최종적으로 실행컨텍스트를 더욱 이해할 수 있다!

1. Record로 JS 호이스팅 이해하기

이처럼 첫 콘솔을 보면 undefined가 찍히는데,
선언 라인 전에도 에러가 나지 않고 변수를 참조할 수 있는 현상을 '호이스팅'이라고 한다.

왜 이렇게 선언문이 마치 최상단에 끌어올려진 듯한 호이스팅 현상이 발생하는 것일까?

자바스크립트 엔진이 먼저 전체 코드를 스캔하면서 변수같은 정보를 실행컨텍스트의 'Record'에 미리 기록해놓기 때문이다.

- Record = Environment Record = 환경레코드

식별자와 식별자에 바인딩된 값을 기록해두는 객체이다.

다시 호이스팅으로 돌아가보자.

호이스팅에는

생성단계: 실행컨텍스트를 생성하고 선언문만 먼저 실행해서 환경레코드에 미리 기록해두는 단계,

실행단계: 선언문 외 나머지 코드 순차적으로 실행해서 환경레코드를 참조하거나 업데이트하는 단계가 있고

종류가 두가지가 있다.

호이스팅의 종류

1. 변수 호이스팅 : var VS const, let

< var >
- 1. 생성단계 : 선언과 초기화가 동시에 이루어진다.

var는 생선단계에서 실행컨텍스트를 생성하고 환경레코드에 undefined로 초기화도 같이한다.

- 2. 실행단계

코드 순차적으로 실행해서 TVChannel을 만나면 환경레코드 값을 업데이트 시켜준다.

< const, let >
- 1. 생성단계 : 선언만하고 초기화는 하지 않는다.

TVChannel 식별자를 기록해두긴 하지만 값을 초기화하지는 않는다. 따라서 선언문 이전에 TVChannel를 참조하려고 하면 Reference Error가 발생한다.

let, const로 선언한 식별자는 선언 라인 이전에 참조할 수 없는데, 이 구역을 ‘일시적 사각지대’라고 부른다.

- var와 let, const의 차이

var는 선언과 초기화가 동시에 이루어진다.

let, const는 선언만하고 초기화는 하지 않는다. 그래서 선언 라인 전에는 변수를 참조할 수 없다.
이는 자바스크립트도 선언 라인 이전에는 변수를 참조할 수 없다는 일반적인 프로그래밍 방식을 추구할 수 있도록
언어 차원에서 보완된 것이다.

2. 함수 호이스팅 : 함수 표현식(var VS const, let), 함수 선언식

- 함수 표현식 : 함수를 변수에 담을 수 있다. 변수 호이스팅과 동일하게 동작한다.

< var >

선언문 이전에 실행하려고 하면 환경레코드에 기록되어있는 값은 undefined이고 undefined라는 데이터타입은 함수와 달리 호출될 수 없기 때문에 타입 에러가 발생한다.

< const, let >

아직 환경레코드에 기록된 값이 없어 Reference Error가 발생한다.

- 함수 선언문

선언과 동시에 함수가 생성되어 선언 전에도 함수를 사용할 수 있다.

선언과 동시에 완성된 함수 객체를 생성해서 환경레코드에 기록해둔다. 함수가 에러없이 실행된다.

그래서 사용을 지양해야한다!!!

- 함수 표현식과 함수 선언문의 차이점

2. 함수 선언문은 함수 선언문은 선언과 동시에 함수 생성을 마치고 온전히 환경레코드에 저장해두기 때문에 선언 라인 전에도 함수를 호출할 수 있다.

2. Outer로 JS 스코프체이닝 이해하기

- outer

outer는 외부 환경을 참조할 수 있게 해준다.

이 흐름을 이해해보자.

1. 함수선언문이라 선언하는 동시에 환경레코드에 생성된 함수가 통째로 기록되고

2. 이 함수(goTo2F)를 실행하면 새로운 실행 컨텍스트가 생성된다.

3. goTo2F 함수의 lamp = true 를 기록한다. 그리고 lamp의 값을 출력하려고 환경레코드를 보니, 불이 꺼진 lamp와 불이 켜진 lamp가 두개가 있다. 자바스크립트 엔진은 둘 중 뭘로 결정해야하나 고민에 빠진다. 이런 상황에서 변수나 함수의 값을 결정해내는 것을 ‘식별자 결정’이라고 한다.

4. 콜스택 안에 동일한 식별자가 여럿일 때, 자바스크립트 엔진이 어떻게 outer를 활용해서 의사결정을 할까?

1. goTo2F 함수가 호출되는 시점으로 돌아가보자.

다시 goTo2F 함수가 호출되는 시점으로 돌아가보면, 함수의 실행 컨텍스트를 새로 생성하고, 이때 새로 생성된 실행 컨텍스트에 바깥 렉시컬 환경으로 돌아갈 수 있는 outer를 남겨놓는다. 이제 필요한 경우에 이전 실행 컨텍스트의 환경레코드에 저장된 식별자도 참조할 수 있게되었다.

2. goTo2F 함수가 실행됨

lamp를 기록하고 goTo3F 함수가 기록되고

3. goTo2F 함수 안에서 다시 goTo3F 함수가 호출된다.

또 실행컨텍스트가 새로 생성되고, 이전 렉시컬환경을 가리키는 outer를 현재의 실행컨텍스트에 저장한다.

4. goTo3F 함수를 실행한다.

3층에서 pet을 할당하고 원칙적으로 현재 활성화된 실행컨텍스트의 환경레코드를 먼저 보고
pet의 값이 puppy니까 puppy를 잘 출력해낸다.

5. goTo3F 함수의 lamp를 찾으려고 한다.

현재 활성화된 실행컨텍스트에는 lamp가 없어서 outer가 가리키는 바깥 렉시컬 환경으로 가서 lamp를 찾아서 값을 출력해낸다.

이미 2층에서 lamp로 찾아서 1층으로 내려가지 않는다.
이렇게 동일한 식별자로 인해 상위 스코프에서 선언된 식별자의 값이 가려지는 현상을 ‘변수 섀도잉’이라고 한다.

층층히 실행 컨텍스트가 쌓여있을 때, 현재 활성화된 실행 컨텍스트는 오직 하나이지만, 이전 렉시컬 환경을 가리키는 outer로 타고타고 갈 수 있다.
이렇게 식별자를 결정할 때 활용하는 스코프들의 연결리스트를 ‘스코프 체인’이라고 한다.
식별자를 결정하기 위해 타고타고 가서 찾는 과정 자체를 ‘스코프체이닝’이라고 한다.

3. 실행컨텍스트

실행하는데 필요한 환경을 제공하는 객체이다. 여기서 환경이란 코드 실행에 영향을 주는 조건이나 상태를 의미한다.
즉, 코드를 실행하는데 필요한 조건이나 상태를 모아둔 객체가 바로 실행컨텍스트이다.

자바스크립트 엔진은 실행컨텍스트만 보고도 값을 잘 결정해냈다.
만약 자바스크립트 엔진이 lamp와 같은 식별자의 값을 정할 때마다 실행컨텍스트 외에 바깥의 다른 메모리를 참조해야 했다면 자바스크립트 엔진의 퍼포먼스는 지금보다 떨어졌을거다!

즉, 실행컨텍스트는 식별자 결정을 더욱 효율적으로 하기 위한 수단으로, 필요한 정보를 한데 모아 제공하는 객체이다.

[리액트 공식문서 정독하기] 리액트 주요개념 - 3 (폼, 합성 vs 상속, React로 생각하기)

정니정은니 — Sat, 19 Aug 2023 22:13:19 +0900

폼

제어 컴포넌트와 비제어 컴포넌트

제어 컴포넌트(Controlled Component)와 비제어 컴포넌트(Uncontrolled Component)는
React에서 폼(form) 관련 컴포넌트를 다룰 때 사용되는 개념이다.

- 제어 컴포넌트(Controlled Component)

상태를 사용하여 폼 입력 요소들을 관리하는 방식
사용자가 입력할 때마다 상태가 업데이트되며, 화면에 보이는 값과 상태가 항상 일치함
React가 폼 데이터를 쉽게 다룰 수 있게 해줌
useState를 사용하여 상태를 정의하고, onChange이벤트를 사용하여 입력값이 변경될 때마다 상태를 업데이트하는 방식

<사용하는 경우>

복잡한 폼에서 여러 입력 요소들을 쉽게 관리하고 싶을 때
폼의 입력값을 바로 React 상태로 가져와서 다루고 싶을 때
유효성 검사 등의 로직을 통해 입력값을 제한하고 싶을 때

import React, { useState } from 'react';

function ControlledComponentExample() {
  const [inputValue, setInputValue] = useState('');

  const handleChange = (event) => {
    setInputValue(event.target.value);
  };

  return (
    <div>
      <input type="text" value={inputValue} onChange={handleChange} />
      <p>현재 입력값: {inputValue}</p>
    </div>
  );
}

- 비제어 컴포넌트(Uncontrolled Component)

React의 상태(state)를 사용하지 않고 폼 입력 요소를 관리하는 방식
사용자의 입력에 따라 React 컴포넌트의 상태를 직접 업데이트하지 않음
대신 ref를 사용하여 직접 입력값을 가져올 수 있음
상태를 관리하지 않기 때문에 코드가 더 간단하지만, 상태 관리를 직접 처리해야 하는 단점

<사용하는 경우>

간단한 폼에서 상태 관리를 최소화하고 싶을 때
상태를 사용하지 않고 직접 입력값을 읽어오는 방식이 편리한 경우
외부 라이브러리와의 통합 등에서 React 상태를 사용하지 않고 폼 데이터를 다루고 싶을 때

import React, { useRef } from 'react';

function UncontrolledComponentExample() {
  const inputRef = useRef(null);

  const handleButtonClick = () => {
    const inputValue = inputRef.current.value;
    console.log('입력값:', inputValue);
  };

  return (
    <div>
      <input type="text" ref={inputRef} />
      <button onClick={handleButtonClick}>입력값 확인</button>
    </div>
  );
}

비제어 컴포넌트는 상태를 관리하지 않기 때문에 코드가 간단해질 수 있지만,
상태 관리를 직접 처리해야 하므로 제어 컴포넌트보다 예측하기 어려울 수 있다.

다시 정리하자면
제어 컴포넌트는 React가 폼 데이터를 관리하는 방식이고, 비제어 컴포넌트는 React의 상태를 사용하지 않고 폼 데이터를 관리하는 방식이다. 어떤 방식을 선택할지는 폼의 복잡성과 상태 관리의 용이성 등을 고려하여 각각의 상황에 따라 선

택하여 사용하면 된다.

합성 vs 상속

합성

종종 컴포넌트에 여러 개의 “구멍”이 필요할 수도 있다. 이런 경우에는 children 대신 자신만의 고유한 방식을 적용할 수도 있다.

리액트 공식문서에서는 이런 코드로 합성을 설명해주고 있다.

App 컴포넌트 레이아웃

React로 생각하기

단일 책임 원칙

하나의 컴포넌트는 한 가지 일을 하는게 이상적이라는 원칙이다.

하나의 컴포넌트가 커지게 된다면 이는 보다 작은 하위 컴포넌트로 분리되어야 한다.

[리액트 공식문서 정독하기] 리액트 주요개념 - 2 (이벤트 처리하기, React에서 콜백 함수 사용 시 주의할 점)

정니정은니 — Wed, 9 Aug 2023 21:51:43 +0900

이벤트 처리하기

React 엘리먼트에서 이벤트를 처리하는 방식은 DOM 엘리먼트에서 이벤트를 처리하는 방식과 매우 유사하다.

비슷해도 크게 세가지의 차이점은 있다.

세가지 차이점

React의 이벤트는 소문자 대신 캐멀 케이스(camelCase) 사용
JSX를 사용하여 문자열이 아닌 함수로 이벤트 핸들러 전달

// HTML
<button onclick="activateLasers()">
  Activate Lasers
</button>

// React -> 캐멀 케이스, 함수로 이벤트 핸들러 전달
<button onClick={activateLasers}>
  Activate Lasers
</button>

3. React에서는 false를 반환해도 기본 동작을 방지할 수 없다. ~~반드시 preventDefault를 명시적으로 호출하여 폼을 제출할 때 가지고 있는 기본 동작을 방지해야한다.~~ => 공식문서에서 이 부분은 틀린 것 같다. React에서는 합성 이벤트를 사용하여 브라우저의 기본 동작을 막을 수 있다. 따라서 React의 이벤트 핸들러에서는 명시적으로 preventDefault()를 호출하지 않아도, 기본 동작이 막힌다.

따라서, React에서 폼을 제출할 때 기본 동작을 방지하려면 명시적으로 preventDefault()를 호출할 필요가 없다.
React는 이를 자동으로 처리하여 폼 제출 시 기본 동작인 페이지 새로고침을 막아준다.

// HTML
<form onsubmit="console.log('You clicked submit.'); return false">
  <button type="submit">Submit</button>
</form>

// React
function Form() {
  function handleSubmit(e) {
    console.log('You clicked submit.');
  }

  return (
    <form onSubmit={handleSubmit}>
      <button type="submit">Submit</button>
    </form>
  );
}

e는 합성 이벤트인데, React는 W3C 명세에 따라 합성 이벤트를 정의하기 때문에 브라우저 호환성에 대해 걱정할 필요가 없다.

* 합성 이벤트

합성 이벤트(Synthetic Event)는 React에서 이벤트 처리를 간편하게 하기 위한 개념이다.

우선, 이벤트란 사용자가 웹 페이지에서 어떤 동작(예: 클릭, 입력 등)을 하거나 브라우저에서 발생하는 일(예: 로딩 완료 등)을 의미하는데

React에서는 이벤트를 다루기 위해 합성 이벤트를 사용한다.
합성 이벤트는 React가 브라우저의 기본 이벤트를 추상화한 것으로, 브라우저 호환성과 관련된 문제를 해결하고, 다양한 브라우저에서 일관성 있는 이벤트 동작을 보장해준다.

예를 들어, 사용자가 웹 페이지의 버튼을 클릭하면 클릭 이벤트가 발생하는데 이 때, React는 해당 클릭 이벤트를 브라우저가 제공하는 기본 이벤트와 동일하게 다루는 것이 아니라, 합성 이벤트를 사용하여 브라우저 이벤트와 비슷하지만, React에서 정의된 방식으로 다룬다.

합성 이벤트를 사용하면 브라우저 호환성과 관련된 문제를 걱정할 필요가 없어지며, 모든 브라우저에서 동일한 방식으로 이벤트를 다룰 수 있다. 이렇게 함으로써 개발자는 다양한 브라우저 환경에서도 일관성 있는 이벤트 처리를 할 수 있다.

간단히 말하면, 합성 이벤트는 React에서 이벤트를 처리하기 위해 사용되는 도구로서, 브라우저 호환성과 이벤트 처리를 편리하게 해주는 개념이다. 이를 통해 React 개발자는 더욱 편리하고 일관성 있게 웹 애플리케이션을 개발할 수 있다.

그리고 위에서 말했듯이, React 이벤트는 브라우저 고유 이벤트와 정확히 동일하게 동작하지는 않는다.

폼 제출 시 기본적으로 페이지를 새로고침하는 것이 기본 동작이지만
React 이벤트는 e.preventDefault()를 호출하지 않아도 폼 제출 시 기본 동작인 페이지 새로고침을 막는 것이 그 예이다.
이렇듯 React로 폼을 제출할 땐 굳이 뭘 하지 않아도 페이지 전체가 새로고침되지 않고 부분적인 데이터 갱신이 가능하게 된다.

이러한 기본 동작의 차이로 React를 사용하면 더욱 유연하게 개발할 수 있는 것 같다.

React에서 콜백 함수 사용 시 주의할 점 : 성능 면에서의 차이를 알아보자!

1. <button onClick={handleClick}>

2. <button onClick={() => handleClick()}>

두 가지 방식은 둘 다 동작은 비슷하나 성능 면에서 차이가 있다.

나는 어쩔 때는 1번처럼, 어쩔 때는 2번처럼 썼다. 이유는 그냥이다.. 그냥 손으로 코드가 써지는 대로 썼었다.
두 방식에 이러한 성능적인 차이가 있는지 몰랐는데 충격이다.... 이젠 무조건 1번 방식을 사용하도록 해야겠다.

<button onClick={handleClick}>: 이 방식은 함수를 감싸지 않고 바로 콜백으로 사용한다. 이렇게 사용하면 함수를 새로 만들지 않고 기존의 함수를 그대로 재사용한다. 따라서 함수를 새로 만들 필요가 없기 때문에 성능이 좋아진다.
<button onClick={() => handleClick()}>: 이 방식은 콜백으로 사용할 때마다 새로운 함수를 만든다.. 화살표 함수(() => ...)를 사용해서 새로운 함수를 만들기 때문에 메모리에 새로운 함수가 계속해서 생성된다. 이렇게 하면 성능에 영향을 미칠 수 있다. 작은 규모의 애플리케이션에서는 큰 문제가 되지 않지만, 큰 규모의 애플리케이션에서는 불필요한 함수 생성이 많아져 성능에 영향을 줄 수 있다.

다시 설명하자면 2번의 문제점은 버튼이 클릭될 때마다 새로운 콜백 함수가 생성된다. 간단히 말하면, onClick={() => handleClick()} 방식은 버튼을 클릭할 때마다 함수가 계속 만들어진다. 일반적으로 이러한 콜백 함수 생성은 아주 큰 문제가 되지 않겠지만 만약 이 콜백 함수가 다른 하위 컴포넌트에 props로 전달된다면, 그 하위 컴포넌트들도 같이 다시 렌더링될 수 있다. 렌더링은 컴퓨터의 작업 중에서 비용이 큰 작업 중 하나이기에 따라서 불필요한 렌더링은 성능 저하로 이어질 수 있다.