next + react 로 서버사이드 렌더링 환경을 구축하면서 개발을 하고 있었는데 두 가지 문제에 부딪혔었다.

## 1. `window is not defined`, SSR 환경에서의 컴포넌트

먼저 원래 코드를 보자.

```javascript
import Calendar from '@toast-ui/react-calendar'

export default function Index() {
  return (
    <Calendar
      view="month"
      month={{
        narrowWeekend: true,
      }}
      onBeforeCreateSchedule={(e) => {
        setOpenCreatePopup(true)
        setSelectedDate(e.start.toDate())
      }}
      onClickSchedule={(e) => {
        console.log(e)
      }}
      scheduleView
      calendars={calendars}
      schedules={schedules}
    />
  )
}
```

```bash
Server Error
ReferenceError: window is not defined

This error happened while generating the page. Any console logs will be displayed in the terminal window.
Call Stack
Object.<anonymous>
file:///.../node_modules/tui-calendar/dist/tui-calendar.js (16:4)
```

```javascript
(function webpackUniversalModuleDefinition(root, factory) {
	if(typeof exports === 'object' && typeof module === 'object')
		module.exports = factory(require("tui-code-snippet"), require("tui-date-picker"));
	else if(typeof define === 'function' && define.amd)
		define(["tui-code-snippet", "tui-date-picker"], factory);
	else if(typeof exports === 'object')
		exports["Calendar"] = factory(require("tui-code-snippet"), require("tui-date-picker"));
	else
		root["tui"] = root["tui"] || {}, root["tui"]["Calendar"] = factory((root["tui"] && root["tui"]["util"]), (root["tui"] && root["tui"]["DatePicker"]));
})(window, function(__WEBPACK_EXTERNAL_MODULE_tui_code_snippet__, __WEBPACK_EXTERNAL_MODULE_tui_date_picker__) // 여기에서 에러가 난다.
```

해당 컴포넌트는 최초 시작시에 `window` 가 필요한데, 서버사이드 렌더링 시에는 `window`가 없는 환경이기 때문에 에러가 난다.

아래 코드를 넣고, 최초 페이지 접근시에 새로고침을 하면 이 모듈이 실행되는 환경이 node 임을 알 수 있다.

```javascript
console.log('node  >> ', globalThis === global) // true
```

결론적으로 이 컴포넌트는 서버사이드 렌더링을 지원하지 않고 있으며, 이를 해결하기 위해서는 `window`가 있는 브라우저 환경에서만 import 해서 사용해야 한다. 이를 nextjs에서 처리하기 위해서는 아래와 같이 하면 된다.

```javascript
// dynamic 만으로는 부족하다. 꼭 ssr을 꺼야 한다.
import dynamic from 'next/dynamic'
const Calendar = dynamic(() => import('@toast-ui/react-calendar'), {
  ssr: false,
})
```

## 2. Next SSR 환경에서의 ref

```javascript
export default function Index() {
  const cal = useRef()

  useEffect(() => {
    console.log(cal.current)
  }, [cal])

  return <Calendar ref={cal} />
}
```

위의 log 는 아래와 같이 찍힌다.

```bash
{retry: ƒ}
retry: ƒ ()arguments: (...)caller: (...)length: 0name: "bound retry"__proto__: ƒ ()[[TargetFunction]]: ƒ retry()[[BoundThis]]: LoadableSubscription[[BoundArgs]]: Array(0)__proto__: Object
```

> `useEffect`는 SSR에서 절대로 실행되지 않는다. 이를 해결하기 위해 [useServerEffect](https://www.npmjs.com/package/use-server-effect)라고 불리우는(?) 해괴한 effect가 있지만 , 굳이 그럴필요 없이 next의 `getServerSideProps`를 사용하면 된다.

왜 `useRef`는 정상적으로 동작하지 않는 것일까?

> `useRef` returns a mutable ref object whose `.current` property is initialized to the passed argument (initialValue). The returned object will persist for the full lifetime of the component.
>
> ...
>
> This works because useRef() creates a plain JavaScript object. The only difference between useRef() and creating a {current: ...} object yourself is that useRef will give you the same ref object on every render.

https://reactjs.org/docs/hooks-reference.html#useref

`useRef`는 순수한 자바스크립트 객체이며, 컴포넌트가 아무리 렌더링이 된다고 해도 같은 `ref`객체를 반환한다. 그런데 현재 `ref.current`에는 `retry`만 존재한다. 이것은 무엇일까?

https://github.com/vercel/next.js/blob/f06c58911515d980e25c33874c5f18ade5ac99df/packages/next/next-server/lib/loadable.js#L219-L260

https://github.com/vercel/next.js/blob/f06c58911515d980e25c33874c5f18ade5ac99df/packages/next/next-server/lib/loadable.js#L161-L173

위 두 코드에 정답이 나와있다. `useImperativeHandle`를 통해서 `ref`를 노출하고 있기 때문에, current에는 현재 세팅되어 있는 `retry`만 보이고 있었던 것이다. `useImperativeHandle`는 [`forwardRef`](https://ko.reactjs.org/docs/react-api.html#reactforwardref)와 사용해야 한다.

> `useImperativeHandle` customizes the instance value that is exposed to parent components when using `ref`. As always, imperative code using refs should be avoided in most cases. useImperativeHandle should be used with `forwardRef`:

https://.reactjs.org/docs/react-api.html#reactforwardref

`forwardRef`는 전달 받은 `ref`속성을 하부트리의 다른 컴포넌트로 전달 할 수 있는 리액트 컴포넌트를 생성한다.

```javascript
// #components/TuiCalendarWrapper
import React from 'react'
import Calendar from '@toast-ui/react-calendar'

export default (props) => (
  // 3. 넘겨받은 `forwardedRef`를 진짜 컴포넌트에 넘긴다.
  <Calendar {...props} ref={props.forwardedRef} />
)
```

```javascript
const TuiCalendar = dynamic(() => import('#components/TuiCalendarWrapper'), {
  ssr: false,
})
// 2. forwardRef를 통해서 전달받은 ref를 하위 컴포넌트에 보낸다.
const CalendarWithForwardedRef = React.forwardRef((props, ref) => (
  <TuiCalendar {...props} forwardedRef={ref} />
))

export default function Index() {
  const ref = useRef()
  // 1. ref를 넘겨준다.
  return <CalendarWithForwardedRef ref={ref} />
}
```

Ref를 포워딩 하는 방법은 여기에 더 자세히 나와있다.

https://reactjs.org/docs/forwarding-refs.html


리액트 서버사이드 렌더링과 컴포넌트

아래 코드는 일반적으로 `useEffect`를 활용해서 데이터를 가져오는 방식이다.

```javascript
import React, { useEffect } from 'react'

export default function App() {
  const [todo, setTodo] = useState(null)
  useEffect(() => {
    const fetchData = async () => {
      const response = await fetch(
        'https://jsonplaceholder.typicode.com/todos/1',
      )
      const newData = await response.json()
      setTodo(newData)
    }
    fetchData()
  }, [])
  if (data) {
    return <div>{data.title}</div>
  } else {
    return null
  }
}
```

dependency에 아무것도 넣지 않음으로써, 딱 한번만 실행되게 끔하고 싶었지만, 이는 여전히 레이스 컨디션과 메모리 누수에 취약하다. 만약 서버에서 응답이 오는 시간이 길어졌고, 그 사이에 컴포넌트가 unmount 되었다고 생각해보자. 컴포넌트는 사라졌지만, 여전히 요청은 대기 중이다. 그리고 요청이 온다면, `setTodo`에 값을 넣을 것이며, 리액트는 이제 아래와 같은 경고문을 내뱉을 것이다.

> Can’t perform a React state update on an unmounted component. This is a no-op, but it indicates a memory leak in your application. To fix, cancel all subscriptions and asynchronous tasks in a useEffect cleanup function.

마찬가지로, `id`를 의존성 목록에 넣어서 처리하는 경우도 있을 수 있다.

```javascript
import React, { useEffect } from 'react'
export default function App({ id }) {
  const [todo, setTodo] = useState(null)
  useEffect(() => {
    const fetchData = async () => {
      const response = await fetch(
        `https://jsonplaceholder.typicode.com/todos/${id}`,
      )
      const newData = await response.json()
      setTodo(newData)
    }
    fetchData()
  }, [id])
  if (data) {
    return <div>{data.title}</div>
  } else {
    return null
  }
}
```

이 경우에도 마찬가지로, ID가 변경되었지만 요청은 여전히 오지 않는 경우 위와 같은 문제가 있을 수 있다.

## 해결책

```javascript
useEffect(() => {
  let isComponentMounted = true
  const fetchData = async () => {
    const response = await fetch('https://jsonplaceholder.typicode.com/todos/1')
    const newData = await response.json()
    if (isComponentMounted) {
      setTodo(newData)
    }
  }
  fetchData()
  return () => {
    isComponentMounted = false
  }
}, [])
```

unmount가 될 시에 요청이 늦게 와도 `setTodo`를 방지함으로써 문제를 해결할 수 있다. 그러나 물론 백그라운드에서는 여러개의 요청이 날라가고 있기 때문에 레이스 컨디션 문제가 발생할 수는 있다. 그래도 어쨌든, 마지막 요청의 결과만 UI에 표시된다.

더욱 확실한 방법은, [http fetch를 취소하는 `AbortController`를 사용하는 것이다.](https://developer.mozilla.org/ko/docs/Web/API/AbortController)

```javascript
useEffect(() => {
  let abortController = new AbortController()
  const fetchData = async () => {
    try {
      const response = await fetch(
        'https://jsonplaceholder.typicode.com/todos/1',
        {
          signal: abortController.signal,
        },
      )
      const newData = await response.json()
      setTodo(newData)
    } catch (error) {
      if (error.name === 'AbortError') {
        // requset를 abort하는 과정에서 에러 발생
      }
    }
  }
  fetchData()
  return () => {
    abortController.abort()
  }
}, [])
```

unmount가 되면 cleanup을 통해서 요청을 중단시켰다. 물론, `AbortController`를 사용하기 위해서는 polyfill도 필요할 것이다.


https://overreacted.io/a-complete-guide-to-useeffect/ 도 시간나면 읽어보세용

useEffect와 메모리 누수

`Redux`, `MobX`등은 이제 리액트 프로젝트를 만든다면 필수로 같이 쓰게 되는 상태 관리 라이브러리 들 중 하나가 된 것 같다. 상태 관리 라이브러리의 필요성은 알지만 서도, 무분별하게 상태 관리 라이브러리를 설치해서 무조건 쓰는 것에 대해 나 또한 그다지 긍정적이지는 않다.

- https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367
- https://dev.to/g_abud/why-i-quit-redux-1knl
- https://hackernoon.com/goodbye-redux-26e6a27b3a0b

개인적으로는 리액트에서 제공하는 `useState` `useContext` 등으로 충분하다고 생각하지만서도, 이미 대세가 되어버린 상태관리 라이브러리의 시대에 나 또한 흐름을 따라 갈 수 밖에 없다.

이 와중에 React에서 만든 `Recoil`이라고 하는 상태 관리 라이브러리가 나왔다. 과연 이 라이브러리가 다른 상태관리 라이브러리랑은 무엇이 다른지, 또 정말 쓸 만한지 고민해보자.

앞서서 리액트의 `Context`만으로 충분할 것 같다고 말한 것과는 다르게, 리액트에서는 `Context`의 한계에 대해서 명백히 인식하고 있는 것 같다.

> My personal summary is that new context is ready to be used for low frequency unlikely updates (like locale/theme). It's also good to use it in the same way as old context was used. I.e. for static values and then propagate updates through subscriptions. It's not ready to be used as a replacement for all Flux-like state propagation.

https://github.com/facebook/react/issues/14110#issuecomment-448074060

그리고 실제로 React의 Context API를 쓰던 Redux가 성능상의 문제로 인해 이를 철회한 사건도 있었다.

> In v6, we switched from individual components subscribing to the store, to having `<Provider>` subscribe and components read the store state from React's Context API. This worked, but unfortunately the Context API isn't as optimized for frequent updates as we'd hoped, and our usage patterns led to some folks reporting performance issues in some scenarios.

https://github.com/reduxjs/react-redux/releases/tag/v7.0.1

또한 Provider의 값이 배열이나 객체 인 경우, 여기에서 구조가 조금이라도 바뀌게 된다면 `Context`를 구독하고 있는 하위 모든 컴포넌트가 다시 렌더링되는 참사가 발생된다.

React Context API는 분명 나쁜 API는 아니지만, 그 한계가 어느정도 있다는 것을 알 수 있다. 그렇기 때문에 Facebook 팀에서도 그 한계를 인지하고 Recoil 을 만든게 아닐 까 싶다.

> For reasons of compatibility and simplicity, it's best to use React's built-in state management capabilities rather than external global state. But React has certain limitations:

> - Component state can only be shared by pushing it up to the common ancestor, but this might include a huge tree that then needs to re-render.
> - Context can only store a single value, not an indefinite set of values each with its own consumers.
> - Both of these make it difficult to code-split the top of the tree (where the state has to live) from the leaves of the tree (where the state is used).

## Recoil

### RecoilRoot

`recoil` 의 state를 사용하기 위해서는 부모 트리에 `RecoilRoot`를 선언해야 한다. 가장 좋은 위치는 바로 Root다.

```javascript
import React from 'react'
import { RecoilRoot, atom } from 'recoil'

function App() {
  return (
    <RecoilRoot>
      <Component />
    </RecoilRoot>
  )
}
```

### Atom

`atom`은 state의 조각을 의미한다. `atom`은 어떤 컴포넌트에서든 읽기/쓰기가 가능하다. 컴포넌트는 이 `atom`의 값을 구독하여 읽을 수 있으며, `atom`의 업데이트는 곳 이를 구독하고 있는 모든 컴포넌트의 업데이트를 야기한다.

```javascript
const textState = atom({
  key: 'textState', // unique ID
  default: '', // 기본값
})
```

### useRecoilState

이름에서 느껴지듯이, `useState`와 비슷하게 값과 이를 조작할 수 있는 `setter` 함수를 리턴한다.

```javascript
const [text, setText] = useRecoilState(textState)
```

### useRecoilValue

`useRecoilState`와는 다르게, 오로지 `atom`의 값만 가져올 수 있다.

```javascript
const text = useRecoilValue(textState)
```

### useSetRecoilState

`atom`의 `setter` 만 가져올 수 있다.

```javascript
const setText = useSetRecoilState(textState)
```

### selector

`atom`과 함께 중요한 개념 중 하나다. `Selector`는 상태에서 파생된 데이터다. `get`을 활용하여 `atom`으로 부터 파생된 데이터를 가져올 수 있으며, `set`을 활용하여 하나이상의 atom을 업데이트 할 수 있다.

```typescript
function selector<T>({
  key: string,

  get: ({
    get: GetRecoilValue
  }) => T | Promise<T> | RecoilValue<T>,

  set?: (
    {
      get: GetRecoilValue,
      set: SetRecoilState,
      reset: ResetRecoilState,
    },
    newValue: T | DefaultValue,
  ) => void,

  dangerouslyAllowMutability?: boolean,
})
```

- `key`: 유니크 아이디로, 애플리케이션 전체에서 다른 `selector`나 `atom`과 중복되서는 안된다.
- `get`: 상태로 부터 연산할 수 있는 값이다. 단순히 값이나 `Promise`로 부터 야기되는 비동기 값을 가져올 수 있으며, 또한 같은 타입을 갖는 `atom`이나 `selector` 를 리턴할 수도 있다.
  - get: 다른 `atom` `selector`에서 값을 가져오기 위해 제공되는 함수다. 이 `get`을 거치는 모든 `atom`과 `selector`는 의존성을 가진 것으로 간주된다. 따라서 이 `get`에서 쓰이는 값이 변하게 되면, 이 selector 또한 변하게 된다.
- `set?`: 만약 이 `set`이 설정되면, `selector` 는 쓰기 가능한 `state`를 리턴하게 된다.
  - `get`: 위와 마찬가지로 다른 `atom` `selector`에서 값을 가져오기 위해 제공되는 함수다.
  - `set`: `recoil`의 state 값을 쓰기 위해 제공 되는 함수다. 첫번째 파라미트로는 `Recoil`의 state를, 두번째 파라미터로는 새로운 값을 넘겨주면 된다.
- `dangerouslyAllowMutability`: `selector`는 파생된 상태로 부터의 순수함수 이기 때문에, 의존성의 같은 input이 제공되면 항상 같은 값을 리턴해야 한다. 이 옵션을 오버라이드 하고 싶을 때 쓴다.

예제를 살펴보자.

```javascript
import { atom, selector, useRecoilState, DefaultValue } from 'recoil'

// 화씨 온도를 저장해 두는 atom
const tempFahrenheit = atom({
  key: 'tempFahrenheit',
  default: 32,
})

// 섭씨 온도는 화씨로 부터 파생된다.
const tempCelsius = selector({
  key: 'tempCelsius',
  // 현재 화씨 값을 기준으로 연산하여 화씨 값을 가져온다.
  get: ({ get }) => ((get(tempFahrenheit) - 32) * 5) / 9,
  // 섭씨 값을 설정하면, 화씨 값을 set 한다.
  set: ({ set }, newValue) =>
    set(
      tempFahrenheit,
      newValue instanceof DefaultValue ? newValue : (newValue * 9) / 5 + 32,
    ),
})

function TempCelsius() {
  // selector와 atom 모두 useRecoilState를 활용하여 값을 설정하고 가져오는 것을 알 수 있다.
  const [tempF, setTempF] = useRecoilState(tempFahrenheit)
  const [tempC, setTempC] = useRecoilState(tempCelsius)
  const resetTemp = useResetRecoilState(tempCelsius)

  const addTenCelsius = () => setTempC(tempC + 10)
  const addTenFahrenheit = () => setTempF(tempF + 10)
  const reset = () => resetTemp()

  return (
    <div>
      Temp (Celsius): {tempC}
      <br />
      Temp (Fahrenheit): {tempF}
      <br />
      <button onClick={addTenCelsius}>Add 10 Celsius</button>
      <br />
      <button onClick={addTenFahrenheit}>Add 10 Fahrenheit</button>
      <br />
      <button onClick={reset}>>Reset</button>
    </div>
  )
}
```

## 느낌

- 일단 API가 굉장히 단순하고, hook을 사용하고 있기 때문에 리액트의 hook 생태계에 익숙한 사람들에게 낮은 러닝 커브로 다가올 것 같은 생각이 든다. 또 현재 `state`로 되어 있는 리액트 프로젝트를 굉장히 빠르게 마이그레이션 할 수 있을 것 같다. `<RecoilRoot/>`로 루트 프로젝트를 감싸고, `useState`를 `useRecoilState`로 바꾸면 일단은 된다.
- 컴포넌트가 사용하는 데이터만 별개로 사용할 수 있어서 좋았다.
- `selector` 라는 이름이 주는 혼란함이 있었다. `selector` 인데 `set`이 왜 됨???
- [리액트 동시성 모드가 사용가능해지면 이를 지원할 수도 있다는 언급이 있었다.](https://recoiljs.org/docs/introduction/motivation/) 왜냐하면 [Recoil은 내부적으로 React의 상태를 사용하고 있으며](https://github.com/facebookexperimental/Recoil/blob/55059f54ad1d09bfac8d086316bb18bed9cc2879/src/hooks/Recoil_Hooks.js#L20) 이는 곧 [React에서 내놓을 동시성 모드](https://ko.reactjs.org/docs/concurrent-mode-intro.html)를 지원할 수도 있다는 가능성이 존재한다고 볼 수 있기 때문이다. (실제로 motivation에서 그렇게 이야기 하기도 했고) 사용이 간편하다, Facebook이 만들었다는 것 외에 다른 상태 관리 라이브러리와 다른 가장 큰 차별점 & 그리고 도입을 해야하는 이유가 있다면 바로 이것 때문이 아닐 까 싶다. (물론 아직은 멀었지만)
  > We have the possibility of compatibility with Concurrent Mode and other new React features as they become available.

## 더 알아보기

- https://www.youtube.com/watch?v=_ISAA_Jt9kI&ab_channel=ReactEurope
- https://ui.toast.com/weekly-pick/ko_20200616


React를 위한 상태관리 라이브러리, Recoil

## 메모이제이션

https://ko.wikipedia.org/wiki/%EB%A9%94%EB%AA%A8%EC%9D%B4%EC%A0%9C%EC%9D%B4%EC%85%98

> 메모이제이션(memoization)은 컴퓨터 프로그램이 동일한 계산을 반복해야 할 때, 이전에 계산한 값을 메모리에 저장함으로써 동일한 계산의 반복 수행을 제거하여 프로그램 실행 속도를 빠르게 하는 기술이다. 동적 계획법의 핵심이 되는 기술이다.

함수형 프로그래밍의 기본원칙을 잘 지켰다면, (어떠한 외부 부수 효과에 영향을 받지 않는다면) 어떤 input이 들어가도 그 input에 대한 output은 동일 할 것이고, 따라서 동일한 input이 들어온다면 미리 전에 계산해두었던 output을 그대로 돌려줘도 될 것이다.

```javascript
const cache = {}
function addTwo(input) {
  if (!cache[input]) {
    console.log('계산 중..')
    cache[input] = input + 2
  } else {
    console.log('계산된 값을 그대로 돌려드립니다.')
  }
  return cache[input]
}
```

```javascript
addTwo(2) // 계산 중..
4
addTwo(3) // 계산 중..
5
addTwo(2) // 계산된 값을 그대로 돌려드립니다.
4
```

예제의 연산 자체는 간단했지만, 연산이 복잡하다면 메모이제이션으로 분명히 이득을 볼 수가 있다.

또 한가지 메모이제이션의 이점은, 정말로 동일한 결과가 리턴된다는 것이다. 결과값이 원시값이 아닌경우, 주소를 비교하기 때문에 `===`이 성립하지 않는데, 메모이제이션을 한다면 정말로 똑같은 값을 리턴할 것이다. (기존에 가지고 있던 값을 그대로 돌려줄 것이므로)

## 리액트의 메모이제이션

리액트는 메모이제이션을 위한 세개의 api를 제공한다.

- [memo](https://ko.reactjs.org/docs/react-api.html#reactmemo)
- [useMemo](https://ko.reactjs.org/docs/hooks-reference.html#usememo)
- [useCallback](https://ko.reactjs.org/docs/hooks-reference.html#usecallback)

리액트 메모이제이션에서는 주목해야 할 부분이 있다. https://ko.reactjs.org/docs/hooks-faq.html#how-to-memoize-calculations

> The useMemo Hook lets you cache calculations between multiple renders by “remembering” the previous computation:

바로 이전의 값만 메모이제이션 한다는 것이다.

```javascript
const Memoized = React.memo(Component)
```

```html

<Memoized num="{1}" />

<Memoized num="{1}" />

<Memoized num="{2}" />

<Memoized num="{1}" />
```

`useMemo` `useCallback`도 마찬가지로, 직전의 값만 메모이제이션한다. 코드로 풀면 이런 느낌의 메모이제이션일 것이다.,

```javascript
let prevInput;
let prevResult;

function someFunction(input) {
  if (input !== prevInput) {
    prevResult = doSomethingHeavyJob....
  }

  prevInput = input
  return prevResult
}
```

## 메모이제이션의 이유

메모이제이션은 아래 두가지 이유때문에 한다고 볼 수 있다.

1. 비싼 연산을 반복하는 것을 피하여 성능을 향상시킨다
2. 안정된 값 제공

1번에 대해서는 모든 리액트 개발자들이 공감하고 있을 것이기 때문에 생략하고, 2번에 대해서 이야기 해보자.

```javascript
function App() {
  const [body, setBody] = useState()
  const fetchOptions = {
    method: 'POST',
    body,
    headers: { 'content-type': 'application/json' },
  }

  const callApi = () => (body ? fetch('/url', fetchOptions) : null)

  useEffect(() => {
    const result = callApi()
    if (!result) return
  }, [callApi])

  return <>...</>
}
```

리액트에서 흔히 볼 수 있는 코드다. `useEffect`는 `deps`에 변경이 있을 때마다 실행된다. 여기에서는 `callApi`가 있으므로, `callApi`는 컴포넌트 내에서 매번 새롭게 렌더링 될 때마다 계속해서 만들어질 것이다.

따라서 이 값을 안정시키기 위해서 memoization을, 정확히는 `useCallback`을 사용해야 한다.

```javascript
const callApi = useCallback(
  () => (body ? fetch('/url', fetchOptions) : null),
  [body, fetchOptions],
)
```

그러나 `fetchOptions`역시 컴포넌트가 렌더링 될 때마다 새롭게 생성될 것이므로, `fetchOptions`도 memoization을 거쳐야 한다.

```javascript
const fetchOptions = useMemo(() => {
  return {
    method: 'POST',
    body,
    headers: { 'content-type': 'application/json' },
  }
}, [body])
```

`fetchOptions`와 `callApi`를 오로지 `body`의 값이 변경될 때만 다시 연산하게 함으로써 값을 안정시킬 수 있다.

원하는 값을 memoization하기 위해서 중요한 것은 memoization에 필요한 값들을 안정화 시키는 것이다. `fetchOptions`의 `useMemo`를 사용하여 `callApi`에서 하고자하는 memoization을 안정적으로 달성할 수 있게 되었다.

물론, 위의 예제를 제대로 작성하기 위해선 아래와 같이 해야할 것이다.

```javascript
useEffect(() => {
  if (!body) return

  const fetchOptions = {
    method: 'POST',
    body,
    headers: { 'content-type': 'application/json' },
  }

  fetch('/url', fetchOptions)
}, [body])
```

굳이 memoization을 하지 않더라도, `useEffect`가 `body`의 값의 변화에만 트리거하도록 바꾸면 (이것도 리액트의 직전 값만 비교하는 memoization전략과 일치한다고 볼 수 있다.) 쉽게 원하는 바를 달성할 수 있다.

블로그에서 계속 같은 글을 쓰는 것 같은데🤪

리액트와 메모이제이션

다른 사람들이 쓴 리액트 코드를 볼 때 마다 몇가지 눈여겨 보는게 있는데, 그 중 하나가 jsx안의 조건절이다. 이 사람은 `&&`을 선호나는지, 아니면 3항연산자를 선호하는지 살펴본다. 근데 보통은 간단해서 그런지 `&&`를 쓰는 경우가 더 많은 것 같다. 예전에는 이 것과 관련해서 코드 리뷰를 올려볼까도 했는데, 멀쩡히 작동하는 코드인데 괜히 시비 거는 것 같아서, 고칠 코드도 많아서, 그리고 결정적으로 소심해서 그냥 그냥 넘어가고는 했다. 그렇다. 이 글은 그냥 소심한 반항인 것이다.

```jsx
export default function StudentsList({ students }) {
  return (
    <ul>
      {students.map(({ id, name, score }) => (
        <li key={id}>
          {name} {score}
        </li>
      ))}
    </ul>
  )
}
```

여기에 이제 `&&`로 다음과 같은 조건을 추가했다고 생각해보자.

```jsx
export default function StudentsList({ students }) {
  return (
    <ul>
      {students.length &&
        students.map(({ id, name, score }) => (
          <li key={id}>
            {name} {score}
          </li>
        ))}
    </ul>
  )
}
```

만약 `students`에 `[]` 빈 배열이 온다면 렌더링이 안되어야 할 것 같지만, 실제로는 `0`이 프린트 된다.

이 버그는 예전 회사에서도 봤던 버그고, 심지어 페이팔에서도 이러한 버그가 있었다고 한다.

![paypal-bug](https://kentcdodds.com/static/330366840b58941a34169d30db87884b/e3189/no-contacts.png)

자바스크립트에서 `0`은 `falsy`한 값으로 취급되기 때문에, `&&` 우측에 있는 값은 계산하지 않는다. 근데 어디까지나 `falsy`한 값인 거지, `null`이나 `undefined`처럼 렌더링을 안하는 값은 아니기 때문에 (순수하게 빈값으로 계산되지는 않으므로) 0이 나오게 된다.

![terrible](https://upload.inven.co.kr/upload/2014/12/23/bbs/i3324974586.jpg)

해결책은, `students.length === 0 && ...`을 쓰거나, 삼항연산자로 바꾸면 된다.

```jsx
export default function StudentsList({ students }) {
  return (
    <ul>
      {students.length
        ? students.map(({ id, name, score }) => (
            <li key={id}>
              {name} {score}
            </li>
          ))
        : null}
    </ul>
  )
}
```

아래와 같은 코드는 어떤가?

```jsx
// students가 undefined로 넘어왔다면?
export default function StudentsList({ students }) {
  return (
    students && (
      <ul>
        {students.map(({ id, name, score }) => (
          <li key={id}>
            {name} {score}
          </li>
        ))}
      </ul>
    )
  )
}
```

다음과 같은 에러가 날것이다.

```bash
Nothing was returned from render. This usually means a return statement is missing. Or, to render nothing, return null.
```

(대충 또 끔찍하다는 이미지)

이 경우에는 `undefined && ...` 이 되기 때문에, `undefined`가 리턴되고, 위와 같은 에러가 뜨게 된다.

```javascript
0 && true // 0
true && 0 // 0
false && true // false
true && '' // ''
[] && true // true
```

이 처럼 `&&`는 자주 쓰는 `if`문 과 동작이 미묘하게 다르다. 그래서 이게 자바스크립트 퀴즈에 종종 나오곤한다.

```javascript
const notifications = 1

console.log(
  `You have ${notifications} notification${notifications !== 1 && 's'}`,
)
```

> 출처: https://quiz.typeofnan.dev/short-circuit-notifications/ `&&`은 정식 명칭으로 `Short-circuit evaluation`이다.

지금까지 말한 예제와는 조금 다르지만, 이것도 마찬가지로 의도 대로 동작하지 않는다.

```bash
You have 1 notificationfalse
```

## 그래서

명백하게 조건에 따라서 jsx에서 렌더링을 하고 싶지 않다면 삼항연산자를 썼으면 좋겠다.

- 우리가 이해하고 있는 `if`문 동작과 일치한다.
- 불필요한 버그나, 의도치 않은 동작 만들지도 않는다.
- jsx에 `null`이 명시적으로 표시되어 있으면 다른 개발자들도 이 부분에서 렌더링이 안되는 경우가 있다는 것을 명시적으로 알 수 있고 이를 유념할 수 있다.
- 삼항연산자가 더 이쁘다. 👀


사실 그냥 (몇 가지 합리적인 이유가 있는) 개인적인 취향임

React 1

리액트 서버사이드 렌더링과 컴포넌트

useEffect와 메모리 누수

React를 위한 상태관리 라이브러리, Recoil

리액트와 메모이제이션

JSX에서 && 대신에 3항 연산자를 더 선호하는 이유