
### 제목: 리액트에서 비동기 상태 업데이트 이해하기

리액트 개발을 하다 보면, 비동기 작업과 상태 업데이트의 상호작용에 대해 깊이 이해할 필요가 있습니다. 특히, _**setTimeout**_ 과 같은 JavaScript의 타이머 함수와 리액트의 상태 업데이트가 어떻게 연결되는지를 아는 것은 중요합니다. 이번 포스트에서는 _**handleSend**_ 함수를 예로 들어 이 과정을 자세히 살펴보겠습니다.

#### 1\. _**handleSend**_ 함수의 실행

_**handleSend**_ 함수는 사용자가 메시지를 전송할 때 호출되는 함수입니다. 이 함수 내에서 우리는 먼저 _**setIsSending(true)**_ 를 호출하여 메시지 전송 중임을 UI에 표시합니다.

```js
function handleSend() {
  setIsSending(true);
  timeoutID = setTimeout(() => {
    alert('Sent!');
    setIsSending(false);
  }, 3000);
}
```

#### 2\. 상태 업데이트와 비동기 콜백

_**setIsSending(true)**_ 는 리액트의 내부 업데이트 큐에 상태 변경을 예약합니다. 이 상태 변경은 _**handleSend**_ 함수가 종료되고 나서 콜 스택이 비워지면 리액트에 의해 처리됩니다. 이렇게 하면 리액트는 가능한 한 효율적으로 UI를 업데이트할 수 있습니다.

한편, _**setTimeout**_ 은 지정된 지연 시간(여기서는 3000 밀리초) 후에 콜백 함수를 실행합니다. 이 콜백 함수는 타이머가 완료되면 이벤트 루프에 의해 콜 스택으로 이동되어 실행됩니다.

#### 3\. 이벤트 루프와 리액트의 업데이트 처리

콜백 함수가 실행되면, 사용자에게 'Sent!'라는 알림을 보여준 후, _**setIsSending(false)**_ 를 호출하여 메시지 전송이 완료되었음을 UI에 업데이트합니다. 이 상태 업데이트 또한 리액트의 내부 업데이트 큐에 추가되고, 콜백 함수 실행이 완료된 후 콜 스택이 비워지면 처리됩니다.

#### 4\. 결론

이 예에서 볼 수 있듯이, 리액트의 상태 업데이트와 JavaScript의 이벤트 루프는 밀접하게 연결되어 있으며, 리액트는 이를 통해 비동기 상태 업데이트를 효과적으로 관리합니다. 이 과정을 이해함으로써, 우리는 리액트 애플리케이션에서 발생할 수 있는 비동기 처리 문제를 더 잘 해결할 수 있습니다.


이벤트 루프와 리액트


G-Check라고 이름 지은 프로젝트의 중간 회고를 작성하고자 한다.
중간 회고인 이유는 이 프로젝트를 앞으로 더 발전시키고, 리펙토링 하고 싶기 때문이다.

_(배포를 했지만 NextAuth 인증 이슈로 인해 지금은 이용이 불가능하다..)_

### **NextJS를 잘 활용했는가?**

사용하려는 목적에 사용했지만 정말 잘 활용했는가 물어본다면 긍정적으로 답은 못할 거 같다.
이유는 nextjs라는 도구를 완전히 나의 도구로 만들지 못하고 약간 끌려다니는 듯한 느낌도 받았다. 이번 프로젝트를 시작하기전에 SSR, CSR 에 대해서 학습을 했지만 실제로 사용할때 제일 많이 했던 고민은 이걸 서버사이드에서 돌리는게 맞나? 클라이언트 사이드에서 이 작업을 수행하는게 효율적인가? 이런 고민을 제일 많이 했던거 같다.

---

### **그러면 언제 SSR, CSR을 사용하면 좋을까?**

> #### 이때는 SSR을 생각해보자

- **SEO 최적화**: SSR은 페이지의 초기 로딩 시 모든 콘텐츠가 서버에서 렌더링되므로, 검색 엔진이 페이지 콘텐츠를 쉽게 크롤링하고 인덱싱할 수 있습니다. 동적인 데이터를 다루는 페이지나, 콘텐츠 기반의 사이트에서 SEO 접근성이 중요할 때 SSR을 사용하는 것이 유리합니다.
- **향상된 퍼포먼스**: 초기 페이지 로드 시 사용자에게 보여질 컨텐츠가 미리 준비되어 있기 때문에, 클라이언트 사이드에서 추가적인 데이터를 기다릴 필요가 없어 사용자 경험이 개선됩니다. 특히 네트워크 속도가 느린 환경에서 사용자가 첫 페이지를 빠르게 볼 수 있습니다.
- **초기 로드 시 데이터가 필요한 페이지**: 사용자가 처음 방문했을 때 바로 필요한 정보를 보여줘야 하는 서비스에서 SSR을 활용하면 유리합니다. 예를 들어, 상품 목록이나 기사 콘텐츠 등을 바로 보여줘야 하는 경우가 해당됩니다.

> #### 이런 상황에는 CSR을 사용해보자

- **리치 인터랙션**: 싱글 페이지 애플리케이션(SPA)처럼 동적인 상호작용이 많고, 페이지 간의 빠른 전환을 요구하는 웹 애플리케이션에 적합합니다. CSR을 사용하면, 서버로부터 한 번에 필요한 데이터를 로드한 후, 사용자와의 상호작용에 따라 클라이언트 사이드에서 즉각적으로 화면을 업데이트할 수 있습니다.
- **프론트엔드 성능 최적화**: 클라이언트의 리소스를 활용하여 서버의 부하를 줄일 수 있습니다. 사용자의 기기에서 스크립트를 실행하여 페이지를 렌더링하기 때문에 서버는 API 데이터 제공에 집중할 수 있으며, 사용자 경험을 더 부드럽게 만듭니다.
- **초기 로드 시간 민감하지 않은 애플리케이션**: 사용자가 앱의 초기 로딩 시간에 민감하지 않거나, 일단 애플리케이션이 로드되면 그 후의 상호작용이 매우 빠르게 이루어져야 하는 경우 CSR을 사용하는 것이 좋습니다.

---

_위 내용은 GPT가 알려준 내용이고 나의 프로젝트에서 사용했던 경험을 가지고 한번 작성해보겠다._

### SSR

```js
// pages/dashboard/index.js
export async function getServerSideProps() {
  const emails = await getEmails(); // 이메일 데이터를 서버에서 미리 가져옵니다.
  return {
    props: {
      emails,
    },
  };
}
```

**사용 이유**

- **빠른 초기 로딩**: G-Check에서 이메일 목록은 프로젝트에서 굉장히 중요했다. SSR을 통해 이메일의 초기 목록을 서버에서 미리 렌더링함으로써, 빠른 초기 로딩을 기대했다.

_초기 로딩이 빨라진다면 G-Check 사용자가 처음 페이지에 접속했을 때 바로 이메일을 볼 수 있고. 이로 인해 사용자 경험이 개선될거라고 생각했다._

### CSR

```js
// components/EmailList.js
useEffect(() => {
  const fetchData = async () => {
    const result = await fetchEmails();
    setEmails(result);
  };
  fetchData();
}, []);
```

**사용 이유**

- **동적인 상호작용 지원**: G-Check 사용자의 인터랙션에 따라 실시간으로 이메일 목록을 업데이트할 필요가 있었다. CSR을 통해 사용자의 요청에 따라 새로운 데이터를 불러오고, 이를 페이지에 동적으로 반영할 수 있었다.

### 결론

G-Check 프로젝트에서는 SSR과 CSR을 혼합하여 사용하고 있다. SSR은 주로 초기 페이지 로드 성능 향상을 위해, CSR은 사용자 경험을 개선하고 페이지의 동적 기능을 지원하기 위해 사용되고 있다.

#### **백엔드 시스템 구축은 성공적이었을까?**

이 부분은 GPT에게 많은 도움을 받았다 지금 나의 코드가 적절하다고 스스로 판단 할수는 없을 것 같다. 다만 작성된 코드를 수정하고 리펙토링 해보면서 간단한 백엔드 시스템 구축에 대한 이해는 어느정도 된거같다.

#### **무한 스크롤, 페이징 처리?**

이 부분은 프로젝트에서 제일 완벽하지 않은 부분중에 하나이다 앞으로 계속 리펙토링 하면서 보완한 후에 작성하도록 하겠다.

---

_그렇게 대단하고 큰 프로젝트는 아니다, 오히려 작고 간단한 프로젝트 이지만 완성하지 못한 부분이 제일 아쉬운 부분이다. 하지만 실패가 아닌 미완성이기 때문에 괜찮다._


실패가 아닌 미완성


리액트 훅은 컴포넌트 로직을 간소화하고 상태 관리를 직관적으로 만든다. 설정된 규칙을 따르고 배열 기반 시스템을 이해함으로써 개발자는 코드를 더 읽기 쉽고 유지 관리하기 쉬운 방식으로 훅을 효과적으로 사용할 수 있다.

# 리액트 훅 이해하기: 상태 관리 간소화

리액트 훅은 클래스를 사용하지 않고 함수형 컴포넌트에서 상태 관리를 할 수 있는 강력한 방법을 제공한다. _**useState**_ 와 같은 훅을 사용하여 개발자들은 컴포넌트에 상태와 행동을 더 직관적으로 연결할 수 있다. 여기서 훅의 작동 방식과 따라야 할 규칙을 설명한다.

## 훅의 마법 설명

훅은 배열을 통해 작동하며, _**useState()**_ 함수는 설정 함수와 현재 상태를 반환한다. 이 메커니즘은 각 컴포넌트가 독립적으로 자체 상태를 유지하도록 보장하여 원치 않는 부작용을 방지한다.

### 훅의 주요 규칙:

1. **루프, 조건문 또는 중첩된 함수 내에서 훅 호출 금지**: 이는 훅 호출과 상태 일관성의 순서를 유지한다.
2. **리액트 함수에서만 훅 호출**: 이는 훅이 리액트의 생명주기와 상태 관리 시스템에 연결되도록 보장한다.

## 예시: **useState()** 사용하기

다음은 _**useState()**_ 가 어떻게 구현될 수 있는지에 대한 간단한 예:

```js
let state = [];
let setters = [];
let firstRun = true;
let cursor = 0;

function createSetter(cursor) {
  return function setterWithCursor(newVal) {
    state[cursor] = newVal;
  };
}

// useState 구현 코드
export function useState(initVal) {
  if (firstRun) {
    state.push(initVal);
    setters.push(createSetter(cursor));
    firstRun = false;
  }

  const setter = setters[cursor];
  const value = state[cursor];

  cursor++;
  return [value, setter];
}

// react hooks를 사용하는 컴포넌트 코드
function RenderFunctionComponent() {
  const [firstName, setFirstName] = useState('Rudi'); // cursor: 0
  const [lastName, setLastName] = useState('Yardley'); // cursor: 1

  return (
    <div>
      <Button onClick={() => setFirstName('Richard')}>Richard</Button>
      <Button onClick={() => setFirstName('Fred')}>Fred</Button>
    </div>
  );
}

function MyComponent() {
  cursor = 0; // cursor 재설정
  return <RenderFunctionComponent />; // render
}

console.log(state); // 렌더링 전 : []
MyComponent();
console.log(state); // 첫 렌더링 후 : ['Rudi', 'Yardley']
MyComponent();
console.log(state); // 후속 렌더링 : ['Rudi', 'Yardley']

// 'Fred' 버튼 클릭

console.log(state); // 버튼 클릭 후 : ['Fred', 'Yardley']
```

이 컴포넌트는 버튼이 "React"에서 "Hooks"로 레이블을 업데이트하는 방법을 보여준다.

참고: [React hooks: not magic, just arrays](https://medium.com/@ryardley/react-hooks-not-magic-just-arrays-cd4f1857236e)


리액트 훅 궁금증


Next.js는 다양한 렌더링 방식을 지원하여 개발자가 사용자 경험과 검색 엔진 최적화(SEO) 간의 최적의 균형을 찾을 수 있도록 도와준다. 이 글에서는 Next.js의 세 가지 주요 렌더링 방식인 CSR, SSR, 그리고 SSG에 대해 알아보고자 한다.

## CSR (Client-Side Rendering)

```text
CSR은 웹 페이지의 로딩 시 서버로부터 최소한의 HTML과 JavaScript를 전달받고, 모든 렌더링은 사용자의 브라우저에서 일어나는 방식이다. 이 방식은 특히 SPA(Single Page Applications)에서 널리 사용된다.
```

### CSR의 주요 특징과 장점

- **동적인 사용자 경험**: 사용자 인터랙션에 빠르게 반응하고, 페이지 간 전환 없이 UI를 업데이트할 수 있다.
- **브라우저 캐싱**: 한 번 로드된 자원은 브라우저에 캐시되어 추가 요청 시 빠르게 사용할 수 있다.

### CSR의 주요 단점

- **초기 로딩 지연**: 모든 자바스크립트 파일이 로드되고 실행될 때까지 사용자가 빈 화면을 볼 수 있다.
- **SEO 문제**: 웹 크롤러가 동적으로 렌더링된 콘텐츠를 제대로 수집하지 못할 수 있다.

## SSR (Server-Side Rendering)

```text
SSR은 각 페이지 요청마다 서버에서 HTML을 렌더링하여 전송하는 방식이다. 이는 콘텐츠가 서버에서 완성된 상태로 클라이언트에 전달되기 때문에 초기 로딩 시간을 단축할 수 있다.
```

### SSR의 주요 특징과 장점

- **SEO 최적화**: 검색 엔진이 콘텐츠를 쉽게 인덱싱할 수 있다.
- **빠른 초기 렌더링**: 사용자에게 초기 컨텐츠를 빠르게 표시할 수 있다.

### SSR의 주요 단점

- **서버 부하 증가**: 모든 페이지 요청이 서버에서 렌더링되어야 하므로 서버 부하가 증가할 수 있다.
- **페이지 전환 지연**: 새 페이지를 요청할 때마다 서버에서 렌더링 과정을 거쳐야 한다.

## SSG (Static Site Generation)

```
SSG는 빌드 타임에 모든 페이지를 HTML로 렌더링하여 생성한다. 생성된 각 페이지는 요청 시 서버에서 바로 제공되는 정적 파일로, 변경 사항이 있을 때마다 사이트를 다시 빌드해야 한다.
```

### SSG의 주요 특징과 장점

- **성능 향상**: 정적 파일을 제공하므로 서버 부담이 낮고, 로딩 시간이 매우 빠르다.
- **보안 강화**: 동적으로 데이터를 처리하는 서버사이드 로직이 없어 보안 위험이 줄어든다.

### SSG의 주요 단점

- **유연성 제한**: 사이트에 변경이 필요할 때마다 전체를 다시 빌드해야 한다.
- **동적 기능 제한**: 실시간으로 데이터를 업데이트하는 것이 어렵다.

---

Next.js는 이러한 렌더링 방식을 선택할 수 있는 유연성을 제공함으로써, 애플리케이션의 요구에 가장 잘 맞는 방식을 선택할 수 있게 해준다. 각 방식의 장단점을 이해하고 적절하게 적용하는 것이 중요하다.


Next.js 렌더링 방식 CSR, SSR, SSG


nextjs 공식문서에 있는 튜토리얼을 진행하면서 공부하다가 폴더구조에 관심이 생겨서 분석하게 되었다. 사실 여태까지 폴더구조에 관심이 크게 없어서 그런지 이게 좋은 구조인지는 잘 모르겠지만 공식문서 튜토리얼에서 이런 구조를 채택했다는건 이유가 있지 않을까 싶은 마음에 이걸 베이스로 공부하기로 결정했다.

## nextjs dashboard 폴더구조

```js
app
 ┣ dashboard
 ┃ ┣ (overview)
 ┃ ┃ ┣ loading.tsx
 ┃ ┃ ┗ page.tsx
 ┃ ┣ customers
 ┃ ┃ ┗ page.tsx
 ┃ ┣ invoices
 ┃ ┃ ┣ [id]
 ┃ ┃ ┃ ┗ edit
 ┃ ┃ ┃ ┃ ┣ not-fount.tsx
 ┃ ┃ ┃ ┃ ┗ page.tsx
 ┃ ┃ ┣ create
 ┃ ┃ ┃ ┗ page.tsx
 ┃ ┃ ┣ error.tsx
 ┃ ┃ ┗ page.tsx
 ┃ ┗ layout.tsx
 ┣ lib
 ┃ ┣ action.ts
 ┃ ┣ data.ts
 ┃ ┣ definitions.ts
 ┃ ┣ placeholder-data.js
 ┃ ┗ utils.ts
 ┣ login
 ┃ ┗ page.tsx
 ┣ ui
 ┃ ┣ customers
 ┃ ┃ ┗ table.tsx
 ┃ ┣ dashboard
 ┃ ┃ ┣ cards.tsx
 ┃ ┃ ┣ latest-invoices.tsx
 ┃ ┃ ┣ nav-links.tsx
 ┃ ┃ ┣ revenue-chart.tsx
 ┃ ┃ ┗ sidenav.tsx
 ┃ ┣ invoices
 ┃ ┃ ┣ breadcrumbs.tsx
 ┃ ┃ ┣ buttons.tsx
 ┃ ┃ ┣ create-form.tsx
 ┃ ┃ ┣ edit-form.tsx
 ┃ ┃ ┣ pagination.tsx
 ┃ ┃ ┣ status.tsx
 ┃ ┃ ┗ table.tsx
 ┃ ┣ acme-logo.tsx
 ┃ ┣ button.tsx
 ┃ ┣ fonts.ts
 ┃ ┣ global.css
 ┃ ┣ home.module.css
 ┃ ┣ login-form.tsx
 ┃ ┣ search.tsx
 ┃ ┗ skeletons.tsx
 ┣ layout.tsx
 ┗ page.tsx
```

> 이 폴더 구조는 어플리케이션의 다양한 부분을 구성하는 파일과 디렉토리를 보여준다. 크게 애플리케이션 로직(app, lib), 사용자 인터페이스(ui), 그리고 레이아웃 및 페이지 관련 파일(layout.tsx, page.tsx)로 구분할 수 있다.

### app 디렉토리

**_dashboard_** : 대시보드 관련 컴포넌트 및 페이지를 포함한다. 여기에는 _overview_, _customers_, _invoices_ 등 대시보드의 다양한 섹션이 포함됩니다. 각 섹션은 자신의 _page.tsx_ 파일을 가지고 있어 해당 섹션의 메인 페이지를 정의한다.

- **_overview_** : 대시보드의 개요 부분을 나타낸다. _loading.tsx_ 와 _page.tsx_ 를 포함하여 로딩 상태와 개요 페이지를 관리한다.
- **_customers_** : 고객 정보와 관련된 페이지를 포함한다.
- **_invoices_** : 인보이스 관련 페이지를 포함한다. 여기에는 인보이스 생성(create), 편집([id]/edit), 오류 처리(error.tsx) 등이 포함된다.

### lib 디렉토리

- 애플리케이션에서 사용되는 다양한 라이브러리 함수, 유틸리티, 정의 등을 포함한다. 예를 들어, _action.ts_, _data.ts_, _definitions.ts_ 등이 있으며, 이들은 데이터 처리, 타입 정의 등의 기능을 제공한다.

### login 디렉토리

- 로그인 페이지와 관련된 컴포넌트 및 로직을 포함한다. _page.tsx_ 파일이 로그인 페이지를 정의한다.

### ui 디렉토리

- 사용자 인터페이스 요소를 포함한다. 버튼, 테이블, 폼, 네비게이션 링크 등과 같은 재사용 가능한 UI 컴포넌트가 이 디렉토리 안에 정의되어 있다.
- _dashboard_, _customers_, _invoices_ 등의 서브 디렉토리는 특정 애플리케이션 영역에 대한 UI 컴포넌트를 포함한다.

### 최상위 파일들

- **_layout.tsx_** : 애플리케이션의 전반적인 레이아웃을 정의하는 컴포넌트이다.
- **_page.tsx_** : 애플리케이션의 기본 페이지 또는 메인 페이지를 정의할 수 있는 컴포넌트이다.

> 이 폴더 구조는 _app_, _lib_, _ui_ 와 같은 폴더들이 특정 기능이나 관심사에 따라 그룹화되어 있어 기능별 폴더 구조의 특성을 많이 담고 있는 거 같다.


이벤트 루프와 리액트

실패가 아닌 미완성

리액트 훅 궁금증

Next.js 렌더링 방식 CSR, SSR, SSG

NEXT.JS 튜토리얼 폴더 구조 분석