리액트로 웹페이지를 만들때, 최대한 작은 단위로 쪼개서 이를 개별 컴포넌트로 만들고 조립하는 방식을 택한다. 그런 방식을 택하다 보면, 십중 팔구 아래와 같은 구조로 구성하게 된다.

```javascript
function App() {
  return (
    <div>
      <MainNav />
      <Homepage />
    </div>
  )
}
function MainNav() {
  return (
    <div>
      <GitHubLogo />
      <SiteSearch />
      <NavLinks />
      <NotificationBell />
      <CreateDropdown />
      <ProfileDropdown />
    </div>
  )
}
function Homepage() {
  return (
    <div>
      <LeftNav />
      <CenterContent />
      <RightContent />
    </div>
  )
}
function LeftNav() {
  return (
    <div>
      <DashboardDropdown />
      <Repositories />
      <Teams />
    </div>
  )
}
function CenterContent() {
  return (
    <div>
      <RecentActivity />
      <AllActivity />
    </div>
  )
}
function RightContent() {
  return (
    <div>
      <Notices />
      <ExploreRepos />
    </div>
  )
}
```

위 구조는 실제 깃헙 홈페이지를 React로 구성한다고 했을 때의 모습이다. 매우 일반적인 구조고, 작동하는데 문제는 없지만, 아래와 같은 구조를 사용해본다면 어떨까?

```javascript
function App() {
  return (
    <div>
      <MainNav>
        <GitHubLogo />
        <SiteSearch />
        <NavLinks />
        <NotificationBell />
        <CreateDropdown />
        <ProfileDropdown />
      </MainNav>
      <Homepage
        leftNav={
          <LeftNav>
            <DashboardDropdown />
            <Repositories />
            <Teams />
          </LeftNav>
        }
        centerContent={
          <CenterContent>
            <RecentActivity />
            <AllActivity />
          </CenterContent>
        }
        rightContent={
          <RightContent>
            <Notices />
            <ExploreRepos />
          </RightContent>
        }
      />
    </div>
  )
}
function MainNav({ children }) {
  return <div>{children}</div>
}
function Homepage({ leftNav, centerContent, rightContent }) {
  return (
    <div>
      {leftNav}
      {centerContent}
      {rightContent}
    </div>
  )
}
function LeftNav({ children }) {
  return <div>{children}</div>
}
function CenterContent({ children }) {
  return <div>{children}</div>
}
function RightContent({ children }) {
  return <div>{children}</div>
}
```

이렇게 코드를 바꾼 구조적인 아이디어는, 대부분의 구성요소가 단순히 레이아웃만 담당한다는 것이다. 이들은 상태를 스스로 관리하기 위해 무언가 일을 하는 코드는 적고 (물론 자체적인 상태관리가 필요할 수도 있지만) 단순히 상태를 받아서 이를 나타나야 하는 페이지에 표시하는 역할만 한다.

만약 첫번째 예제와 같은 구조를 가지고 있다면, `prop-drilling`이 발생하게 된다. `<App/>` 에서 `<HomePage />`로 다시, `<CenterContent />`에서 `<AllActivity />`로 가는 등, prop을 넘기고 넘기는 과정이 반복된다. 이런 구조를 보게 되면 사람들은 아마도 React API인 `context` 를 사용하여 해결하려 할 것이다. 하지만 그러기 전에, 좀더 간단하게 생각해볼 필요가 있다. 자체적인 상태관리가 필요없고, 단순히 레이아웃인 컴포넌트라면 `prop`을 직접적으로 넘기면 된다. `<App />` 에서 `<AllActivity/>`로.

너무 많은 사람들이 `prop-drilling`에서 `context`로 섣불리 넘어가버리려고 한다. 더 많은 컴포넌트를 염두에 두고, 구성요소를 구조화 한다면 더 유지 보수가 쉬워지고, 성능및 관리 문제가 줄어들 것이다.

출처: https://epicreact.dev/one-react-mistake-thats-slowing-you-down


처음부터 구조를 잘 생각해 둔다면 성능상 에 이점을 가져갈 수 있다.

Prop drilling 해결을 위해 context를 사용하기 전에 구조를 생각해보자.

요즘 대부분의 리액트 코드는 함수형 컴포넌트와 리액트 hooks의 조합으로 개발된다. 그러나 여전히 [higher-order components(이하 HOC)](https://ko.reactjs.org/docs/higher-order-components.html)는 클래스형, 그리고 함수형 모두에 적용할 수 있다. 따라서 HOC는 레거시와 모던한 리액트 컴포넌트 사이에서 재사용 가능성을 높이며 쓸 수 있는 훌륭한 다리 역할을 하고 있다.

그러나 때때로 HOC의 사용은 자제해야하며, 몇몇 문제들은 hooks만으로도 해결할 수 있다.

## HOC와 HOOKS: Prop에서 오는 혼동

조건부 렌더링 기능을 적용하기 위해 HOC를 사용한다고 가정해보자.

```javascript
import * as React from 'react'

const withError = (Component) => (props) => {
  if (props.error) {
    return <div>Something went wrong ...</div>
  }

  return <Component {...props} />
}

export default withError
```

에러가 없는 경우, HOC가 어떻게 모든 props를 넘기는지 보자. 에러가 없는 경우에 정상적으로 작동할 것이지만, 다음 컴포넌트에 전달해야 하는 props 들이 굉장히 많으며, 이 props를 모두 신경쓰기는 어렵다.

```javascript
import * as React from 'react'

const withError =
  (Component) =>
  ({ error, ...rest }) => {
    if (error) {
      return <div>Something went wrong ...</div>
    }

    return <Component {...rest} />
  }

export default withError
```

위 코드 또한 `error` prop을 제거하고도 정상적으로 작동한다. 그러나 위 버전 또한 HOC를 사용하는 경우 오는 Props의 혼동을 피할 수는 없다. 전개 연산자를 사용하여 HOC에 props를 넘겨주었지만, 이 props들이 어디에 필요한지 명확히 하기가 굉장히 어렵다.

이는 HOC의 첫번째 약점이다. HOC가 어떤 컴포넌드들과 합성되어 있는지 빠르게 알 수 없기 때문에, 어떤 컴포넌에 어떤 것을 넘겨야 할지 예측이 어렵다. 예를 들어, loading 인디케이터가 있는 HOC를 하나더 만들어 보자.

```javascript
import * as React from 'react'

const withLoading =
  (Component) =>
  ({ isLoading, ...rest }) => {
    if (isLoading) {
      return <div>Loading ...</div>
    }

    return <Component {...rest} />
  }

export default withLoading
```

이제 두개의 HOC를 사용해야 한다면, 아래와 같이 써야할 것이다.

```javascript
const DataTableWithFeedback = compose(
  withError,
  withLoading,
)(DataTable);

const App = () => {
  ...

  return (
    <DataTableWithFeedback
      columns={columns}
      data={data}
      error={error}
      isLoading={isLoading}
    />
  );
};
```

HOC에 대해 세세히 알고 있지 않다면, 어떤 props가 어떤 HOC에 넘어가는지 알수 없다. 한단계 더 나아가 이제 데이터를 가져오는 HOC까지 있다고 가정해보자.

```javascript
const DataTableWithFeedback = compose(
 withFetch,
 withError,
 withLoading,
)(DataTable);

const App = () => {
 ...

 const url = 'https://api.mydomain/mydata';

 return (
   <DataTableWithFeedback
     url={url}
     columns={columns}
   />
 );
};
```

갑자기 `withFetch`를 사용하면서 `error`와 `isLoading`이 필요 없게 되었다. 정확히는, 아래와 같이 props가 흘러가게 된다.

```bash

App     withFetch   withError   withLoading   DataTable

        data->      data->      data->        data
url->   error->     error
        isLoading-> isLoading-> isLoading
```

`withFetch`는 내부적으로 `error`와 `isLoading`을 처리하고, 이를 위해 `withLoading`과 `withError`를 필요로 하게 된다. 이에 대한 이해가 부족할 경우 버그를 만들어낼 가능성이 존재한다.

결과적으로, HOC를 통해서 넘어가는 props는 블랙박스로 남게 되어 이를 이해하기 위해서는 꽤나 많은 주의를 기울여야 한다. HOC에 대한 자세한 이해가 없이는, HOC 들 사이에서 무슨일이 일어나고 있는지 알기 어렵다.

반면에 리액트 hook 에서는 어떻게 처리하는지 살펴보자.

```javascript
const App = () => {
  const url = 'https://api.mydomain/mydata'
  const { data, isLoading, error } = useFetch(url)

  if (error) {
    return <div>Something went wrong ...</div>
  }

  if (isLoading) {
    return <div>Loading ...</div>
  }

  return <DataTable columns={columns} data={data} />
}
```

리액트 hooks을 사용하면, 블랙박스 안으로 들어가는 `url`과 이를 통해 나오게 되는 `data`, `isLoading`, `error`를 모두 볼수 있다. `useFetch`가 어떻게 구현되어 있는지는 몰라도, 이 함수를 통해 들어가는 input과 output을 명확하게 볼 수 있다. `useFetch`가 다른 HOC와 같이 블랙박스처럼 취급 된다하더라도, 복잡했던 HOC와는 다르게 단 한줄로 모든 것을 표현하고 있다. 그러나 HOC를 합성해서 사용하는 경우 input과 output이 명확하지 않았다.

## HOC와 HOOKS: 이름 간의 충돌

만약 컴포넌트에서 두개의 prop이 사용된다면, 후자가 전자를 엎어버리게 된다. (그전에 에러가 나겠지만)

```javascript
<Headline text="Hello World" text="Hello React" />
```

만약 HOC에서 다음과 같은 일이 벌어진다면 어떻게 될까?

```javascript
const UserWithData = compose(
  withFetch,
  withFetch,
  withError,
  withLoading,
)(User);

const App = () => {
  ...

  const userId = '1';

  return (
    <UserWithData
      url={`https://api.mydomain/user/${userId}`}
      url={`https://api.mydomain/user/${userId}/profile`}
    />
  );
};
```

위 예제는 두 번의 fetch를 위해서 HOC를 합성한 예제다. 그러나 앞서 언급한 것처럼, 동일한 prop이 존재한다면 후자만 유효하게 된다. 이를 위해서, `withFetch`의 `url`을 배열로 만들었다고 가정해보자. 그렇다고해서 문제가 해결되는 것이 아니다.

- 모든 요청이 끝났을 때 `loading` 인디케이터가 사라져야 하는가?
- 하나만 실패해도 에러 페이지를 보여줘야 하는가?
- 만약 한 요청이 다른 요청에 의존하면 어떻게 되는가?

이 문제를 HOOKS로 풀어보도록 하자.

```javascript
const App = () => {
  const userId = '1';

  const {
    data: userData,
    isLoading: userIsLoading,
    error: userError
  } = useFetch(`https://api.mydomain/user/${userId}`);

  const {
    data: userProfileData,
    isLoading: userProfileIsLoading,
    error: userProfileError
  } = useFetch(`https://api.mydomain/user/${userId}/profile`);

  if (userError || userProfileError) {
    return <div>Something went wrong ...</div>;
  }

  if (userIsLoading) {
    return <div>User is loading ...</div>;
  }

  const userProfile = userProfileIsLoading
    ? <div>User profile is loading ...</div>
    : <UserProfile userProfile={userProfileData} />;

  return (
    <User
      user={userData}>
      userProfile={userProfile}
    />
  );
};
```

앞선 HOC 예제에 비해 복잡도도 줄어들고, 조건별로 처리할 수 있는 여지도 많아졌다.

HOC를 사용할 때는, 내부적으로 같은 prop 명을 사용하고 있는 컴포넌트가 있는지 조심해야 한다.

## HOC와 HOOKS: 의존성

HOC는 강력하지만, 때로는 너무 강력할 때가 있다. HOC는 부모로 부터 props를 받거나, 혹은 컴포넌트 내부에서 처리하는 방법으로 변수를 받을 수 있다. 아래 예제를 살펴보자.

```javascript
const withLoading =
  ({ loadingText }) =>
  (Component) =>
  ({ isLoading, ...rest }) => {
    if (isLoading) {
      return <div>{loadingText ? loadingText : 'Loading ...'}</div>
    }

    return <Component {...rest} />
  }

const withError =
  ({ errorText }) =>
  (Component) =>
  ({ error, ...rest }) => {
    if (error) {
      return <div>{errorText ? errorText : 'Something went wrong ...'}</div>
    }

    return <Component {...rest} />
  }
```

```javascript
const DataTableWithFeedback = compose(
  withError({ errorText: 'The data did not load' }),
  withLoading({ loadingText: 'The data is loading ...' }),
)(DataTable);

const App = () => {
  ...

  return (
    <DataTableWithFeedback
      columns={columns}
      data={data}
      error={error}
      isLoading={isLoading}
    />
  );
};
```

`errorText`와 `loadingText`를 각각 받아서, 에러와 로딩 문구를 커스터마이징 할 수 있도록 처리했다. 그러나 이제 props를 받는 곳이 한군데 가 더 늘어나서 혼란이 가중되었다. 만약 여기에서, `userId` 까지 필요하다면 어떻게 될까?

```javascript
const UserWithData = compose(
  withFetch(props => `https://api.mydomain/user/${props.userId}`),
  withFetch(props => `https://api.mydomain/user/${props.userId}/profile`),
)(User);

const App = () => {
  ...

  const userId = '1';

  return (
    <UserWithData
      userId={userId}
      columns={columns}
    />
  );
};
```

만약 여기서 더 나아가 두번째 요청이 첫번째 요청에 의존적이라고 한다면 어떻게 될끼?

```javascript
const UserProfileWithData = compose(
  withFetch(props => `https://api.mydomain/users/${props.userId}`),
  withFetch(props => `https://api.mydomain/profile/${props.profileId}`),
)(UserProfile);

const App = () => {
  ...

  const userId = '1';

  return (
    <UserProfileWithData
      columns={columns}
      userId={userId}
    />
  );
};
```

HOC간에 강한 연결을 만들어 문제를 해결했지만, HOC간에 강결합을 통해서 문제를 해결하는 것은 굉장히 어렵고 혼란이 가중된다.

그러나 Hooks을 쓰면 더 쉽게 해결할 수 있다.

```javascript
const App = () => {
  const userId = '1';

  const {
    data: userData,
    isLoading: userIsLoading,
    error: userError
  } = useFetch(`https://api.mydomain/user/${userId}`);

  const profileId = userData?.profileId;

  const {
    data: userProfileData,
    isLoading: userProfileIsLoading,
    error: userProfileError
  } = useFetch(`https://api.mydomain/user/${profileId}/profile`);

  if (userError || userProfileError) {
    return <div>Something went wrong ...</div>;
  }

  if (userIsLoading || userProfileIsLoading) {
    return <div>Is loading ...</div>;
  }

  return (
    <User
      user={userData}>
      userProfile={userProfileData}
    />
  );
};
```

Hook은 오직 함수형 컴포넌트에서만 직접적으로 쓰이기 때문에, 데이터를 넘기기 유용하다. 또한 블랙박스가 존재하지 않고, custom hook간에 데이터를 넘기는 것 또한 명확하게 볼 수 있다. 의존성이 있는 경우에는, hook을 쓰는 것이 더 코드에 많은 이점을 가져올 수 있다.


HOC는 좋지만, hooks을 사용하는 습관을 기르자.

리액트의 Hooks과 HOC, HOC의 사용이 복잡해지는 경우

흔히 쓰고 있는 `useState`를 다시 살펴보자.

```javascript
const [count, setCount] = useState(
  Number.parseInt(window.localStorage.getItem(cacheKey)),
)
```

```javascript
const [count, setCount] = useState(() =>
  Number.parseInt(window.localStorage.getItem(cacheKey)),
)
```

두 코드의 차이는, useState에 직접 변수를 넣는가와 즉시실행 화살표 함수를 넣느냐의 차이다.

`useState`에 직접적인 값 대신에 함수를 넘기는 것을 [게으른 초기화(lazy)](https://reactjs.org/docs/hooks-reference.html#lazy-initial-state)라고 한다. react 공식 문서에서는, 이러한 게으른 초기화를 초기 값이 복잡한 연산을 포함할 때 사용하라고 되어 있다. 게으른 초기화 함수는 **오직 state가 처음 만들어 질 때만 실행된다.** 이 후에 다시 리렌더링이 된다면, 이 함수의 실행은 무시된다.

다시 말해, `useState`는 그 함수가 처음 렌더링 될 때 작동하며, 이는 `count` state의 초기값을 만든다. `setCount`가 실행되면, 전체 함수가 다시 실행되며, `count`의 값을 업데이트 한다. 이는 `count`의 값이 변경될 때 마다 리 렌더링을 발생시킨다. 다시말해, 이 초기 값은 다시 쓰일 일이 없게 된다.

따라서, 리 렌더링이 발생할 때 마다 `localStorage`의 값을 읽지만, 오직 우리는 딱 최초 렌더링 시에만 해당 값이 필요하므로, 이는 필요없는 계산을 계속해서 하게 되는 것이다. 두 번째 예제에서는 게으른 초기화를 하기 때문에 불필요한 계산을 막게된다.

말이 조금 어렵다면, 아래 예제를 살펴보자.

예제1

```javascript
const Counter = () => {
  const initialValue = Number.parseInt(window.localStorage.getItem(cacheKey))
  const [count, setCount] = useState(initialValue)
  // ...
```

이제 매번 리렌더링 하여 `Counter`함수가 호출 될 때 마다, `localStorage`의 값을 계속해서 가져오는 것을 볼 수 있다.

예제2

```javascript
// Example 2
const Counter = () => {
  const [count, setCount] = useState(function() {
    return Number.parseInt(window.localStorage.getItem(cacheKey)),
  })

  // ...
}
```

이 더분째 예제에서는 이전 예제와는 다르게 딱 한번 초기화 할 때 한 번만 우리가 원하는 대로 호출하는 것을 볼 수 있다.

그렇다면 모든 값들을 게으른 초기화로 처리하면 어떨까?

```javascript
// 원시 값 리턴
const Counter = () => {
  const [count, setCount] = useState(() => 0)

  // ...
}
```

```javascript
// prop 또는 이미 존재하는 변수의 값을 리턴
const Counter = ({ initialCount }) => {
  const [count, setCount] = useState(() => initialCount)

  // ...
}
```

각각 초기 값이 간단한 값이거나 이미 계산된 값인 경우이다. 비록 함수가 게으른 초기화로 인해 한번만 호출되지만, 여전히 함수를 만드는 비용이 존재한다. 그리고 함수를 만드는 비용이 보통 변수를 생성하거나 단순히 값을 넘기는 비용보다는 크다. 이는 과한 최적화의 예다.

그렇다면 언제 게으른 최적화를 써야할까? 이는 상황에 따라 다르다. 문서에서는 '비싼 비용의 계산' 이 필요할 때 쓰라고 되어있다. 앞선 예와 같이 `localStorage` 의 접근, ` map`, `filter`,`find` 등의 배열을 조작하는 것들이 그 예가 될 수 있다. 일반적으로, 함수를 통해서 값을 구해야한다면, 이는 비싼 비용이 드는 계산이며, 게으른 초기화를 하는게 좋을 수도 있다. `new Date()`도 마찬가지로.


리액트 최적화의 길은 멀고도 험하다

리액트의 useState와 lazy initialization

## Table of Contents

예전부터 블로그는 내가 직접 만든 적이 없고, 사람들이 만들어 놓은 템플릿에 마크다운만 얹는 식으로 운영했었다. 그러다 보니 무언가 수정이 필요할 때 마다 코드를 잘모르니 땜빵식으로 수정하게 되고, 블로그에 대한 애정도 부족하지 않았나 싶다.

## 1. 나는 왜 Next.js로 갔나

이전까지 쓰던 블로그는 static site generator로 Gatsby 기반으로 운영되고 있었는데, 나 뿐 만 아니라 많은 사람들이 여러가지로 불편함을 느끼고 있는 분위기 였다. 🤔

https://cra.mr/an-honest-review-of-gatsby/

https://jaredpalmer.com/gatsby-vs-nextjs

나의 경험과 섞어서 gatsby가 안좋았던 경험을 이야기 하자면

- 정적 사이트를 만들 뿐인데 GraphQL은 너무 무겁고 쓸모가 없다. 개인적으로 블로그 운영하면서도 써본적이 없다.
- gatsby만의 생태계, gatsby-plugin-\*\*\*에 너무 의존적이다. 버그가 있어도 수정이 어렵고, 대부분의 플러그인이 관리도 잘 안되고 있었다.
- 디버깅이 어려웠다. Gatsby 내부의 graphql 및 webpack 등등으로 인해 추상화가 있는대로 되어 있어서 디버깅 하기가 정말 쉽지 않았다.
- GraphQL, 그리고 마크다운과 혼재되어 있는 이미지 빌드 등 각종 작업으로 인해 빌드가 너무 오래 걸렸다. (그래서 대부분의 경우에 나는 빌드 결과를 확인하지 않고 머지했다.)

## 2. 스펙

기존 개발 스택은 아래와 같다.

- gatsby
- graphql
- react
- javascript
- flow
- SCSS

바뀐 개발 스택은 아래와 같다.

- nextjs
- remark
- rehype
- react
- typescript
- styled component

굳이 혼자 쓰는 프로젝트에 타입스크립트가 필요가 있겠냐만은, 이제 자바스크립트 생태계 자체가 많이 타입스크립트 쪽으로 기우는 것 같아서 함께 썼다.

마크다운을 HTML로 만들기 위해 `remark`와 `rehype`를 썼고, `SCSS`는 그냥 별로 안좋아해서 (내 jsx 에 클래스명이 덕지덕기 붙어있는게 너무 보기 힘들다) `styled component`로 넘어갔다.

## 2. 이사 과정

### 1) nextjs

nextjs에서 정적 사이트를 만들기 위해서 중요한 것은 `getStaticProps` 와 `getStaticPaths`다.

https://yceffort.kr/2020/03/nextjs-02-data-fetching#2-getstaticprops

https://yceffort.kr/2020/03/nextjs-02-data-fetching#3-getstaticpaths

`getStaticPaths`는 빌드시에 가능한 다이나믹 path를 결정하고, `getStaticProps`는 페이지 로딩 시에 서버사이드에서 내려올 props를 결정한다.

### 2) 마크다운 파일 읽어오기

내 마크다운 파일은 `/content/posts/articles`에 존재하고 있다. gatsby에서는 이것을 graphql로 처리하지만, nextjs에서는 그런 것이 없기 때문에 직접 파일시스템에 접근해서 재귀적으로 모든 `.md`파일을 찾아와서 [frontMatter](https://github.com/jxson/front-matter)로 읽어 왔다. 그리고 이렇게 읽어 온 마크다운을 HTML로 변환해주어야 한다. 이를 위해 [unified](https://github.com/unifiedjs/unified), [remark](https://github.com/remarkjs/remark) [rehype](https://github.com/rehypejs/rehype) 를 사용했다.

### 3) flow를 타입스크립트로 변환하기

이 과정이 젤 쉬웠다.

### 4) SCSS를 styled component로 변환

워낙 디자인 감각이 없는 대다가, SCSS에 postCss에 lostGrid 까지 사용되어 있어서 개인적으로 제일 고통스러운 과정이었다. 일일이 CSS를 보면서 적용했다.

## 3. 난관

### 1) Dynamic Path

내 블로그 글들을 nextjs dynamic path 문법으로 작성하면 다음과 같다.

```bash
- /[year]/[month]/[day]/[title]
- /[year]/[month]/[title]
```

그래서 아래와 같이 pages 디렉토리를 설정해주었는데

```bash
- /[year]/[month]/[day]/[title].tsx
- /[year]/[month]/[title].tsx
```

`day`와 `title`이 겹치면서 빌드가 되지 않았다. koa를 쓰면 라우팅 순서대로 타기 때문에 상관없지만, 여기까지 와서 koa를 쓰고 싶지 않아서 (...) 결국 아래와 같이 만들었다.

```bash
- /[year]/[month]/[day]/[title].tsx
- /[year]/[month]/[day]/index.tsx
```

이렇게 하면 세번째 path가 `day`로 동일해지기 때문에, 더 이상 에러가 나지 않는다. 다만 `index.tsx`에서 `day`가 아니라 `title`이라는 사실을 염두해두고 개발에 해야한다.

### 2. 마크다운 파서

내 마크다운은 다음과 같은 기능을 반드시 제공 해야만 했다.

- toc 자동생성
- latex 문법 지원
- heading link
- raw html 지원 (iframe 등). 어차피 글은 나만 쓰기 때문에 상관없다.
- 코드 하이라이팅

이를 완벽하게 지원하기 위하여 참으로 많은 삽질을 거쳤다. 특별한 노하우가 있는게 아니고 그냥 삽질의 과정이 었다. 약간의 시간을 거친 끝에, 잘 만들었다.

https://yceffort.kr/2020/07/math-for-programmer-chapter2-3-rational-irrational-real-number

### 3. 사이트맵

사이트맵도 gatsby에서는 graphql로 잘 만들어줬지만, 여기서는 내가 다 만들어야 했다.

### 4. 리다이렉트

`/categories` url이 존재하는지도 몰랐는데, 있긴 있더라. 그래서 이것들을 다 리다이렉트 시켰다. `next.config.js`에서 다 처리할 수 있다.

```javascript
module.exports = {
  async redirects() {
    return [
      {
        source: '/tag/:tag',
        destination: '/tag/:tag/page/1',
        permanent: true,
      },
      {
        source: '/category/:tag',
        destination: '/tag/:tag/page/1',
        permanent: true,
      },
      {
        source: '/categories',
        destination: '/tags',
        permanent: true,
      },
    ]
  },
}
```

## 3. 결과

일단 빌드 시간이 엄청나게 빨라졌다.

![gatsby](./images/gatsby-build.png)

7분 가까이 빌드에 소요되었었다. ㅠㅠ

```bash
16:54:32.265  	Running "npm run build"
...

16:56:13.131  	success Rewriting compilation hashes - 0.006s
16:59:23.076  	success Building static HTML for pages - 7.784s - 655/655 84.15/s
16:59:24.034  	success Generating image thumbnails - 275.708s - 2434/2434 8.83/s
```

정적파일 빌드 하는데 3분이 넘게 걸렸고, 쓸데 없이 이미지 썸네일 만드는데에 5분까지 걸렸다.

![nextjs](./images/nextjs-build.png)

빌드도 빨라지고, 빌드 결과물도 기존 232.34mb에서 29.02mb로 다이어트 할 수 있었다. (nextjs는 다이나믹 path에 대해서 모두 빌드해두는 것이 아니라, 최초 페이지 접근 요청이 올 때만 빌드하고, 이 후 접근엔 이전에 빌드해둔 페이지를 보여준다.)

또한 기존에 찾기가 너무 어려웠던 mathjax 문법 오류도 다 고칠 수 있었다.

### github issue & board

https://github.com/yceffort/yceffort-blog-v2/projects/1

https://github.com/yceffort/yceffort-blog-v2/issues?q=is%3Aissue+is%3Aclosed+label%3A%22%F0%9F%91%B7%E2%80%8D%E2%99%82%EF%B8%8F+Next.js%22

(볼 때 마다 느끼지만, 깃헙 라벨링 정말 이쁘다)

## 4. 아쉬운점

- CSS를 옮기면서 약간 생각 없이 그냥 가져온 부분들이 많다. CSS에 대해 더 분석할 필요가 있을 듯
- nextjs는 정적이미지를 `public`디렉토리에서 서빙해야되는데, 이거 때문에 이미지를 다 이 디렉토리로 옮겨 왔다. 그러다 보니 글 쓰는 과정 마크다운 프리뷰에서 이 이미지들을 제대로 볼 수 가 없었다. dev 환경에서 볼 수 는 있지만, dev 에서 .md 파일에 대해서는 HMR이 안되었다. 향 후 아이디어가 필요해 보인다.
- 일부 type이 없는 패키지가 있었는데, 맘이 급해서 `@ts-ignore` 로 무시하고 갔다. `@mapbox/rehype-prism` `remark-slug` 시간 나는대로 만들어야겠다.

## 5. 개선 예정 사항

- 글 오른쪽 하단 플로팅 버튼으로 글 최상단에 올라갈 수 있는 기능
- algolia를 활용한 검색 (디자인까지 건드려야 되서 매우 귀찮을 듯)
- 조금 더 예쁜 about, contact


어영부영했지만 보람은 있었다

블로그 gatsby에서 nextjs로 옮긴 이야기

[원문](https://blog.bitsrc.io/using-service-workers-with-react-27a4c5e2d1a9)

## 개요

```typescript
// This optional code is used to register a service worker.
// register() is not called by default.

// This lets the app load faster on subsequent visits in production, and gives
// it offline capabilities. However, it also means that developers (and users)
// will only see deployed updates on subsequent visits to a page, after all the
// existing tabs open on the page have been closed, since previously cached
// resources are updated in the background.

// To learn more about the benefits of this model and instructions on how to
// opt-in, read https://bit.ly/CRA-PWA

const isLocalhost = Boolean(
  window.location.hostname === 'localhost' ||
    // [::1] is the IPv6 localhost address.
    window.location.hostname === '[::1]' ||
    // 127.0.0.0/8 are considered localhost for IPv4.
    window.location.hostname.match(
      /^127(?:\.(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)){3}$/,
    ),
)

type Config = {
  onSuccess?: (registration: ServiceWorkerRegistration) => void
  onUpdate?: (registration: ServiceWorkerRegistration) => void
}

export function register(config?: Config) {
  if (process.env.NODE_ENV === 'production' && 'serviceWorker' in navigator) {
    // The URL constructor is available in all browsers that support SW.
    const publicUrl = new URL(process.env.PUBLIC_URL, window.location.href)
    if (publicUrl.origin !== window.location.origin) {
      // Our service worker won't work if PUBLIC_URL is on a different origin
      // from what our page is served on. This might happen if a CDN is used to
      // serve assets; see https://github.com/facebook/create-react-app/issues/2374
      return
    }

    window.addEventListener('load', () => {
      const swUrl = `${process.env.PUBLIC_URL}/service-worker.js`

      if (isLocalhost) {
        // This is running on localhost. Let's check if a service worker still exists or not.
        checkValidServiceWorker(swUrl, config)

        // Add some additional logging to localhost, pointing developers to the
        // service worker/PWA documentation.
        navigator.serviceWorker.ready.then(() => {
          console.log(
            'This web app is being served cache-first by a service ' +
              'worker. To learn more, visit https://bit.ly/CRA-PWA',
          )
        })
      } else {
        // Is not localhost. Just register service worker
        registerValidSW(swUrl, config)
      }
    })
  }
}

function registerValidSW(swUrl: string, config?: Config) {
  navigator.serviceWorker
    .register(swUrl)
    .then((registration) => {
      registration.onupdatefound = () => {
        const installingWorker = registration.installing
        if (installingWorker == null) {
          return
        }
        installingWorker.onstatechange = () => {
          if (installingWorker.state === 'installed') {
            if (navigator.serviceWorker.controller) {
              // At this point, the updated precached content has been fetched,
              // but the previous service worker will still serve the older
              // content until all client tabs are closed.
              console.log(
                'New content is available and will be used when all ' +
                  'tabs for this page are closed. See https://bit.ly/CRA-PWA.',
              )

              // Execute callback
              if (config && config.onUpdate) {
                config.onUpdate(registration)
              }
            } else {
              // At this point, everything has been precached.
              // It's the perfect time to display a
              // "Content is cached for offline use." message.
              console.log('Content is cached for offline use.')

              // Execute callback
              if (config && config.onSuccess) {
                config.onSuccess(registration)
              }
            }
          }
        }
      }
    })
    .catch((error) => {
      console.error('Error during service worker registration:', error)
    })
}

function checkValidServiceWorker(swUrl: string, config?: Config) {
  // Check if the service worker can be found. If it can't reload the page.
  fetch(swUrl, {
    headers: { 'Service-Worker': 'script' },
  })
    .then((response) => {
      // Ensure service worker exists, and that we really are getting a JS file.
      const contentType = response.headers.get('content-type')
      if (
        response.status === 404 ||
        (contentType != null && contentType.indexOf('javascript') === -1)
      ) {
        // No service worker found. Probably a different app. Reload the page.
        navigator.serviceWorker.ready.then((registration) => {
          registration.unregister().then(() => {
            window.location.reload()
          })
        })
      } else {
        // Service worker found. Proceed as normal.
        registerValidSW(swUrl, config)
      }
    })
    .catch(() => {
      console.log(
        'No internet connection found. App is running in offline mode.',
      )
    })
}

export function unregister() {
  if ('serviceWorker' in navigator) {
    navigator.serviceWorker.ready
      .then((registration) => {
        registration.unregister()
      })
      .catch((error) => {
        console.error(error.message)
      })
  }
}
```

서비스 워커란 브라우저에서 실행되는 스크립트 파일이다. 이 파일에서 직접적으로 DOM을 다뤄서는 안된다. 여기에는 별도 구성 없이 사용할 수 있는 네트워크 관련 기능들이 존재한다. 서비스 워커는 오프라인 경험을 제공하기 위해서 존재한다. 여기에는 푸쉬 알림, 백그라운드 동기화 등이 있다.

리액트에서 서비스 워커를 적절하게 구성할 수 있다면, 네트워크 요청을 가로채서 관리함으로써 다양한 작업등을 할 수 있다. `create-react-app`을 사용하면 서비스 워커는 `SWPrecacheWebpackPlugin`를 통해 자동으로 설치된다. 서비스 워커는 네트워크가 새로운 요청을 처리하기 위한 병목현상이 되지않도록 한다.

## 서비스워커: 유즈케이스

이는 개발자가 심리스한 연결성을 보여주기 위해서는, 가장 먼저 해결해야 할 문제가 바로 네트워크 연결 중단이다. 최근에는 좋은 사용자 경험을 제공하는 오프라인 어플리케이션의 개념이 인기를 끓고 있다. 서비스워커는 웹 개발자에게 다음과 같은 이점을 제공한다.

- 웹사이트의 성능향상. 웹사이트의 로딩 속도를 빠르게 하기 위해 사이트 일부를 캐싱할 수 있다.
- 오프라인 화면을 제공하여, 연결이 끊기더라도 정상적으로 애플리케이션을 계속 사용하도록 할 수 있다.
- 기존 웹 기술로는 불가능한 알림과 푸쉬 API를 활용할 수 있다.
- 백그라운드 동기화를 수행할 수 있게 해준다. 사용자에게 원활한 환경을 제공하기 위해, 네트워크 연결이 다시 복원될 때 까지 특정 작업을 연기할 수 있다.

## 서비스워커의 라이브사이클

서비스워커의 라이프 사이클은 웹 애플리케이션과 관련이 없다. 자바스크립트를 활용하여 서비스 워커를 등록하면 설치가 된다. 이는 브라우저가 백그라운드에서 설치를 시작하도록 지시한다. 또한 필요한 에셋을 이 기간 동안 캐시할 수도 있다. 설치가 끝나면 활성화 프로세스가 시작된다. 활성화되면, 서비스 워커는 해당 범위의 모든 페이지와 연결되며, 이벤트에 의해 호출되지 않는 한 프로세스가 종료된다.

서비스워커의 라이프 사이클은 일반적으로 개발자가 코딩해야 한다. 리액트의 서비스 워커의 경우, 리액트 자체로 라이프 사이클을 관리하여 개발자가 조금더 서비스 워커를 다루기 쉽게 했다.

![lifecycle of service worker](https://miro.medium.com/max/1400/1*HUnu3nbBSq2lDoOSllBkiA.png)

## 리액트 서비스 워커의 고려사항

- 서비스 워커는 브라우저에 의해 자체 글로벌 스크립트 컨텍스트에서 실행된다. 이는 즉, 페이지의 DOM 요소에 접근해서는 안된다는 것을 의미한다. 따라서, 페이지와의 통신이 필요하다면 간접적인 방식으로 처리해야 한다. 보통 [postMessage](https://developer.mozilla.org/en-US/docs/Web/API/Client/postMessage)를 사용한다.
- 서비스 워커는 HTTPS 프로토콜에서만 실행된다. `localhost`는 제외.
- 서비스 워커는 특정 페이지에 종속되어 있지 않으므로, 재사용이 가능하다.
- 서비스워커는 이벤트 중심으로 이루어져 있다 (event driven). 이는 서비스 워커가 종료되면 어떠한 정보도 얻을 수 없다는 것을 의미한다. 이전 상태의 정보에 접근하기 위해서는, [IndexedDB API](https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API)를 사용해야 한다.

## 리액트 서비스워커 활성화

`create-react-app`으로 리액트 어플리케이션을 만들면, 아래와 같은 구조를 띄고 있을 것이다.

```
├── README.md
├── node_modules
├── package.json
├── .gitignore
├── build
├── public
│   ├── favicon.ico
│   ├── index.html
│   └── manifest.json
└── src
    ├── App.css
    ├── App.js
    ├── App.test.js
    ├── index.css
    ├── index.js
    ├── logo.svg
    └── serviceWorker.js
```

`serviceWorker.js`가 `src` 밑에 존재한다. 이 파일은 디폴트로 생성된다. 이 단계에서는 서비스워커는 등록되지 않았으므로, 서비스 워커를 사용하기 위해서는 이를 등록해야 한다.

`src/index.js`의

```javascript
serviceWorker.unregister()
```

를

```javascript
serviceWorker.register()
```

로 바꾼다. 이렇게 딱 한줄만 바꾸면, 리액트 애플리케이션의 서비스 워커를 사용할 준비가 된다.

일반적인 웹 애플리케이션에서는, 서비스워커의 전체 라이프 사이클을 코딩해야 한다. 그러나 리액트는 기본값으로 이러한 개발을 할 준비를 해두었다. `src/serviceWorker.js` 파일을 확인해보면, 서비스워커와 관련된 코드가 준비되어 있는 것을 볼 수 있다.

## 개발환경에서 리액트 서비스 워커 작업하기

`serviceWorker.js`의 `register()` 함수를 보면, `process.env.NODE_ENV === 'production'` 때문에 프로덕션 모드에서만 실행된다는 것을 알 수 있다. 이를 수정할 방법이 몇가지 있다.

- 이조건을 삭제하여 development에서도 실행하는 방법. 그러나 잠재적인 이슈가 있을 수 있다.
- 리액트 애플리케이션을 프로덕션 버전으로 만들어서, 서빙하는 방법. 아래와 같은 방법으로 사용하면 된다.

```
$ yarn global add serve
$ yarn build
$ serve -s build
```

## 서비스 워커를 커스터마이징 하는법

CRA에서 `service-worker.js`는 기본적으로 모든 기본 에셋을 캐싱한다. 서비스 워커에 기능을 추가하기 위해서는, `custom-service-worker.js`를 만들고, `register()`를 수정해서 커스터마이징 하는 방법이 있다.

34번째 라인에 가서, 아래와 같이 수정하면 된다.

```javascript
window.addEventListener('load', () => {
  const swUrl = `${process.env.PUBLIC_URL}/custom-service-worker.js`;
  //
}
```

`package.json`을 아래와 같이 수정한다.

```json
"scripts": {
   "start": "react-app-rewired start",
   "build": "react-app-rewired build",
   "test": "react-app-rewired test",
   "eject": "react-app-rewired eject"
},
```

그리고, Google의 workbox plugin을 추가한다. [Google's Workbox plugin](https://developers.google.com/web/tools/workbox/guides/codelabs/webpack)

```
npm install --save-dev workbox-build
```

다음에, CRA에 커스텀 서비스 워커를 삽입하도록 지시하는 설정파일을 생성한다.

```javascript
const WorkboxWebpackPlugin = require('workbox-webpack-plugin')
module.exports = function override(config, env) {
  config.plugins = config.plugins.map((plugin) => {
    if (plugin.constructor.name === 'GenerateSW') {
      return new WorkboxWebpackPlugin.InjectManifest({
        swSrc: './src/custom-service-worker.js',
        swDest: 'service-worker.js',
      })
    }

    return plugin
  })
  return config
}
```

다음 아래와 같이 특정 디렉토리를 캐시하는 커스텀 서비스 워커를 만들 수 있다.

```javascript
workbox.routing.registerRoute(
  new RegExp('/path/to/cache/directory/'),
  workbox.strategies.NetworkFirst(),
)
workbox.precaching.precacheAndRoute(self.__precacheManifest || [])
```

변경사항을 적용하기 위해서는 애플리케이션을 다시 빌드하면 된다.

## 더 공부해보기

https://developers.google.com/web/fundamentals/primers/service-workers/

> 서비스 워커는 브라우저가 백그라운드에서 실행하는 스크립트로, 웹페이지와는 별개로 작동하며, 웹페이지 또는 사용자 상호작용이 필요하지 않은 기능에 대해 문호를 개방합니다. 현재 푸시 알림 및 백그라운드 동기화와 같은 기능은 이미 제공되고 있습니다. 향후 서비스 워커는 주기적 동기화 또는 지오펜싱과 같은 다른 기능을 지원할 수 있습니다. 이 가이드에서는 프로그래밍 방식의 응답 캐시 관리를 비롯하여 네트워크 요청을 가로채고 처리하는 핵심 기능에 대해 설명합니다.

https://github.com/facebook/create-react-app/pull/1728

https://developers.google.com/web/tools/workbox/modules/workbox-webpack-plugin#generatesw_plugin


가끔 봤지만 전혀 궁금해 하지 않았던 그 것

Page 33

Prop drilling 해결을 위해 context를 사용하기 전에 구조를 생각해보자.

리액트의 Hooks과 HOC, HOC의 사용이 복잡해지는 경우

리액트의 useState와 lazy initialization

블로그 gatsby에서 nextjs로 옮긴 이야기

Create React App의 serviceWorker는 무엇일까