브라우저가 어떻게 스크립트를 스케쥴링 하고 실행하느냐에 따라서 웹페이지 성능에 큰 영향을 미친다. `<script defer />` `<link rel=preload>` 등등 스크립트 로딩에 영향을 미치는 다양한 기술들이 있으며 이러한 기술을 브라우저에서 어떤 순서로 처리하는지 이해하는 것도 중요하다.

### Table of Contents

### `<head />` 안에 있는 `<script />`

#### 로딩 우선 순위

중간, 높음

#### 실행 우선 순위

매우높음, 파서 실행을 멈춤

### 사용처

- First Meaningful Paint, First Contentful Paint 컨텐츠
- 다른 스크립트 이전에 실행해야 되는 스크립트

#### 예

- 프레임워크 런타임 (정적 렌더링이 아닌 경우)
- 폴리필
- 전체 페이지 DOM 구조에 영향을 미치는 A/B 테스트

### `<link rel=preload` + `<script async>` 또는 `<script type=module async />`

#### 로딩 우선 순위

중간, 높음

#### 실행 우선 순위

높음, 파서 실행을 방해함

#### 사용처

- 중요한 컨텐츠를 만드는 스크립트 (First Meaningful Paint)
- 그러나 페이지 상단 (above-the-fold)에는 영향을 미치지 않는 요소
- 동적으로 컨텐츠를 넣기 위해 네트워크 fetch를 실행하는 스크립트
- imports한 요소들이 모두 fetch된 이후 즉시 실행되어야 하는 스크립트는, `<script async type=module />`

#### 예

- `<canvas />` 에 그려야 하는 것

### `<script async />`

#### 로딩 우선 순위

제일 낮음, 낮음

#### 실행 우선 순위

높음, 파서를 방해함

#### 사용처

사용할 때 주의 해야 한다. (https://calendar.perfplanet.com/2016/prefer-defer-over-async/) 요즘 들어 중요하지 않은 스크립트를 로딩 할 때 많이 사용하고 있지만, 로딩 우선순위만 낮을 뿐 실행 우선순위는 높다는 것을 기억해야 한다.

### `<script defer />`

#### 로딩 우선 순위

제일 낮음, 낮음

#### 실행 우선 순위

매우 낮음, `<body />` 최하단에 있는 `<script />`가 실행된 이후에 실행

#### 사용처

- 중요하지 않은 컨텐츠를 만드는 스크립트
- 페이지 방문자의 50% 이상정도가 사용하는 중요한 상호작용 기능

#### 예

- 광고
- 프레임 워크 런타임 (클라이언트 또는 서버사이드 렌더링)

### `<body />` 최하단에 있는 `<script />`

#### 로딩 우선 순위

중간, 높음

#### 실행 우선 순위

낮음, 파서의 작업이 끝나기를 기다림

#### 사용처

이 방법은 생각만큼 낮은 우선순위로 실행되지 않는다.

### `<body />` 최하단에 있는 `<script defer />`

#### 로딩 우선 순위

가장 낮음, 낮음, 큐의 모든 작업이 끝난 후에 실행됨.

#### 실행 우선 순위

매우 낮음. `<body />` 최하단에 있는 `<script />` 보다도 낮음.

#### 사용처

- 사용자들이 가끔 사용하는 상호작용 기능

#### 예

- '연관된 기사들' 같은 컨텐츠 (중요도가 낮은)
- '피드백을 주세요' 같은 기능들 (역시 중요도가 낮은)

### `<link rel=prefetch />` + `<script/>`

#### 로딩 우선 순위

작업이 없을 때, 가장낮음

#### 실행 우선 순위

스크립트가 어떻게 작동하느냐에 따라 다름.

#### 사용처

다음 페이지 탐색을 위한 중요한 기능을 제공하는 스크립트

#### 예

- 다음 라우팅을 위한 자바스크립트 번들

### 마치며

- 브라우저 별로 동작이 통일되어 있지 않으므로 사용할 때 주의를 필요로 한다.
- 크롬에서 스크립트 우선순위를 알아내기 위해서는 네트워크 탭에서 Priority를 보면된다.

![priorities](https://addyosmani.com/assets/images/tweet-priorities@3x.png)

출처: https://addyosmani.com/blog/script-priorities/


크롬에서 자바스크립트를 로딩하는 순서

크롬에서 자바스크립트 로딩 순서

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

```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

[원문](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


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

Javascript 13

크롬에서 자바스크립트 로딩 순서

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

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

리액트의 useState와 lazy initialization

Create React App의 serviceWorker는 무엇일까