## Table of Contents

이따금씩 다른 사람들이 만들어둔 컴포넌트 코드를 보면, 함수형 컴포넌트에 `React.FC<>`를 달아두어서 함수를 타이핑 한 것을 종종 볼 수 있었다.

그러나 나는 그러한 방식을 썩 선호하지는 않는다. 그 이유는 다음과 같다.

## `React.FC<>`란 무엇인가?

리액트에서는 크게 두가지 방법으로 컴포넌트를 정의할 수 있다.

1. `Component`를 extending하는 클래스 컴포넌트
2. `JSX`를 리턴하는 함수형 컴포넌트

일단 리액트는 타입스크립트로 작성되있지 않기 때문에, 리액트 커뮤니티에서는 `@types/react`패키지를 제공하여 리액트에 대한 타이핑을 지원하고 있다. 여기에는 `FC`라고 하는 제네릭 타입이 있는데, 이를 활용하면 함수형 컴포넌트를 아래와 같이 타이핑 할 수 있게 도와준다.

```typescript
import { FC } from 'react'

type GreetingProps = {
  name: string
}

const Greeting: FC<GreetingProps> = ({ name }) => {
  return <h1>Hello {name}</h1>
}
```

그리고, 이 FC는 다음과 같은 구조로 되어 있다.

```typescript
type FC<P = {}> = FunctionComponent<P>

interface FunctionComponent<P = {}> {
  (props: PropsWithChildren<P>, context?: any): ReactElement<any, any> | null
  propTypes?: WeakValidationMap<P> | undefined
  contextTypes?: ValidationMap<any> | undefined
  defaultProps?: Partial<P> | undefined
  displayName?: string | undefined
}
```

> [github 소스 코드 보기](https://github.com/DefinitelyTyped/DefinitelyTyped/blob/0beca137d8552f645064b8a622a6e153864c66ee/types/react/index.d.ts#L548-L556)

## 함수를 타이핑 하지만, 인수를 타이핑 하지는 않는다.

`React.FC`는 함수를 타이핑해준다. 이름에서 할 수 있는 것처럼. 함수 타이핑은 일반적인 기명 함수에 적용하기 매우 어렵다. 만약 아래와 같은 코드에 함수 타이핑을 적용해본다고 가정해보자.

```typescript
function Greeting({ name }) {
  return <h1>Hello {name}</h1>
}
```

먼저 쉽게할 수 있는 방법 중 하나는, 익명 함수를 변수에 할당하여 타이핑 하는 것이다.

```typescript
const Greeting: FC<GreetingProps> = function ({ name }) {
  return <h1>Hello {name}</h1>
}
```

혹은 화살표 함수를 쓸 수도 있겠다.

```typescript
const Greeting: FC<{ name: string }> = ({ name }) => {
  return <h1>Hello {name}</h1>
}
```

그러나 우리가 일반적으로 쓰는 기명 함수 방식에서는 이러한 타이핑을 사용할 수 없다. 만약 함수 타이핑을 사용하지 않는다면, 함수를 기명이건 익명이건 어떤 방식으로 사용해도 문제가 없다.

```typescript
function Greeting({ name }: GreetingProps) {
  return <h1>Hello {name}</h1>
}
```

## `React.FC<>`는 항상 children을 가질수 있다.

`React.FC<>`로 타이핑 하는 것은 컴포넌트에 children이 있을 수 있다는 것을 의미한다.

```typescript
export const Greeting: FC<GreetingProps> = ({ name }) => {
  return <h1>Hello {name}</h1>
}

const App = () => (
  <>
    <Greeting name="Stefan">
      <span>{"I can set this element but it doesn't do anything"}</span>
    </Greeting>
  </>
)
```

`Greeting`에는 딱히 `children`을 렌더링하거나 처리하는 코드가 없음에도 위 코드는 정상적으로 처리되는 것을 볼수 있다.

대신, 일반적인 방법으로 한다면 아래코드는 다음과 같은 결과가 나온다.

```typescript
function Greeting({ name }: {name: string}) {
  return <h1>Hello {name}</h1>
}
const App = () => <>
  // Property 'children' does not exist on type 'IntrinsicAttributes & { name: string; }'.ts(2322)
  <Greeting name="Stefan">
    <span>{"I can set this element but it doesn't do anything"}</span>
  </Greeting>
</>
```

최소한 컴포넌트에 children의 존재가 가능한지 여부를 확인하는 것은 도움이 될 수 있다. 만약 컴포넌트에 children이 존재할 수도 있다는 것을 알리기 위해서는, `PropsWithChildren`을 사용하는 것이 좋다.

```typescript
type PropsWithChildren<P> = P & { children?: ReactNode | undefined }
```

[https://github.com/DefinitelyTyped/DefinitelyTyped/blob/0beca137d8552f645064b8a622a6e153864c66ee/types/react/index.d.ts#L830](https://github.com/DefinitelyTyped/DefinitelyTyped/blob/0beca137d8552f645064b8a622a6e153864c66ee/types/react/index.d.ts#L830)

```typescript
function Card({ title, children }: PropsWithChildren<{ title: string }>) {
  return (
    <>
      <h1>{title}</h1>
      {children}
    </>
  )
}
```

## `React.FC<>`는 defaultProps를 쓰지 못하게 만든다.

`defaultProps`는 클래스 기반 컴포넌트의 유물로, props에 기본값을 세팅할 수 있도록 도와준다. 함수형 컴포넌트에서는, 자바스크립트의 기본적인 기능을 활용하면 기본값을 제공할 수 있다.

```typescript
function LoginMsg({ name = 'Guest' }: LoginMsgProps) {
  return <p>Logged in as {name}</p>
}
```

타입스크립트 3.1 버전 이후로, `defaultProps`를 이해하는 메커니즘이 추가되었으며, 이는 사용자가 세팅한 값을 기반으로 기본값이 설정된다. 그러나 `React.FC`는 `defaultProps`에 대한 타이핑 하기 때문에 이러한 기본값에 대한 연결고리를 끊어버리게 된다. 아래 코드를 살펴보자.

```typescript
type GreetingProps = {
  name: string
}

export const Greeting: FC<GreetingProps> = ({ name }) => {
  return <h1>Hello {name}</h1>
}
음
Greeting.defaultProps = {
  name: 'World',
}

const App = () => (
  <>
    {/* name에 world가 들어오지 않음 💥*/}
    <Greeting />
  </>
)
```

하지만, 일반적인 함수 방식이라면 `defaultProps`는 여전히 유효하다.

```typescript
export const Greeting = ({ name }: GreetingProps) => {
  return <h1>Hello {name}</h1>
}

Greeting.defaultProps = {
  name: 'World',
}

const App = () => (
  <>
    {/* Yes! ✅ */}
    <Greeting />
  </>
)
```

## Stateless Function Component의 과거

예전에는 모두가 함수형 컴포넌트를 stateless function component (무상태 함수형 컴포넌트)라고 불렀었다.

```typescript
/**
 * @deprecated as of recent React versions, function components can no
 * longer be considered 'stateless'. Please use `FunctionComponent` instead.
 *
 * @see [React Hooks](https://reactjs.org/docs/hooks-intro.html)
 */
```

[https://github.com/DefinitelyTyped/DefinitelyTyped/blob/0beca137d8552f645064b8a622a6e153864c66ee/types/react/index.d.ts#L532-L548](https://github.com/DefinitelyTyped/DefinitelyTyped/blob/0beca137d8552f645064b8a622a6e153864c66ee/types/react/index.d.ts#L532-L548)

훅이 소개된 이후로, 함수형 컴포넌트에는 많은 상태가 들어오기 시작했고 이제는 더이상 stateless하게 취급하지 않는다. 위 코드에서 볼 수 있는 것 처럼, `SFC`는 `FC`가 되었다. 또 훗날 `FC`가 무엇으로 바뀔 수 있을지도 모를일이다. 그러나 단순히 인수 (props)를 타이핑 하는 것은 이후에 함수의 타입이 바뀌더라도 안전하게 처리할 수 있다.

## Summary

`React.FC`를 쓰는 것이 꼭 나쁜 것 만은 아니다. 여전히 이것을 사용하는게 좋은 경우도 있을 것이고, 그렇다고 이를 억지로 고칠 필요도 없을 수 있다. 그러나 props를 타이핑 하는 것이 조금더 자바스크립트의 느낌과 비슷하고, 다양한 경우의 수로 부터 조금더 안전해 질 수는 있다.


React.FC가 잘못됐다는 이야기는 아닙니다

React.FC를 사용하지 않는 이유

## Table of Contents

## Introduction

리액트에서 훅이 등장한 2018년 이래로, 리액트 커뮤니티에서는 함수형 컴포넌트 사용에 많은 탄력을 받았다. 훅을 사용하여, 함수형 컴포넌트의 상태 로직 (stateful logic)과 렌더링 로직을 매우 손쉽게 분리할 수 있게 되었다.

이 후 수년간 리액트에서 훅을 사용해오면서, 훅이 항상 편리함만을 제공해주는 것은 아니다. 모든 코드가 그렇지만 당연히 여기에도 위험성이 존재하며, 훅도 마찬가지다.

## 클로져

객체/함수지향 프로그래밍에 대해 잘못 알려진 사실 중 하나는, 객체 지향은 stateful하고, 함수지향은 stateless 하다는 것이다. 그리고 이 논쟁에 뒤따르는 사실 중 하나는, 상태는 보통 나쁜 것으로 치부되기 때문에 상태를 피하고, 더 나아가 객체 지향을 피해야 한다는 사실로 이어진다. 이 말 중 일부는 옳지만, 대부분의 진실이 그렇듯, 잘못된 사실도 있다.

`state`, 즉 상태란 무엇인가? 컴퓨터에서는 '계산을 한 값을 보관해두는 것'이라고 불리우는, 주로 메모리에 들어가 있는 값을 의미한다. 변수에 무언가를 저장할 때 마다 그 변수에 주어진 라이프 타임 동안 상태를 유지하게 된다. 그리고 프로그래밍 패러다임의 유일한 차이는, 이 변수를 얼마나 오래 보관해두느냐, 그리고 이 결정이 어떤 트레이드 오프를 가지고 오느냐 정도로 볼 수 있다.

아래 동일한 작업을 하는 함수형 코드와 객체지향 코드를 살펴보자.

```javascript
class Hello {
  i = 0
  inc() {
    return this.i++
  }
  toString() {
    return String(this.i)
  }
}
const h = new Hello()
console.log(h.inc()) // 1
console.log(h.inc()) // 2
console.log(h.toString()) // "2"
```

```javascript
function Hello() {
  let i = 0
  return {
    inc: () => i++,
    toString: () => String(i),
  }
}
const h = Hello()
console.log(h.inc()) // 1
console.log(h.inc()) // 2
console.log(h.toString()) // "2"
```

여기에서 메모리를 유지하는 메커니즘 (`i`) 은 많은 공통점을 가지고 있다. 클래스는 객체의 인스턴스를 참조하는 `this`를 사용하는 방식으로, 함수형은 범위내 모든 변수를 기억하는 클로져를 활용하는 방식으로 이 기능을 구현했다.

클로져는 함수를 `stateful`하게 만들어 주기 때문에 매우 중요한 개념이라 볼 수 있다. 그러나 클로져의 한가지 중요한 문제점이라고 한다면, 메모리 누수가 쉽게 일어난다는 점이다. 함수가 스코프를 넘어서도 살아있을 수 있기 때문에, 가비지 콜렉터가 이를 수집할 수가 없게 된다. 위 예제에서는, `inc`가 존재하는한, `i`는 가비지 콜렉팅 당하지 않을 것이다.

클로져에서 또한가지 조심해야 할 것은, 명시적 의존성을 암묵적인 의존성으로 바꿔버린다는 것이다. 함수에 인수를 넘겨주면, 그 함수의 의존성은 명시적이라고 볼 수 있지만, 프로그램이 이 클로저가 무엇에 의존성을 가지고 있는지는 알 수 없게 된다. 즉, 클로저가 메모리에 보관하는 값은 호출에 따라서 변화할수도, 그 결과에 따라 다른 값을 만들어 버릴 수도 있다.

## 클로져와 훅

```javascript
function User({ user }) {
  useEffect(() => {
    console.log(user.name)
  }, []) // exhaustive-deps

  return <span>{user.name}</span>
}
```

훅에 있는 개념 중 하나는, 의존성에 변화가 있을 때마다 (`dependencies`) 부수효과가 발생한다는 것이다. 예를 들어, `useEffect`는, 엑셀 시트처럼, 부수효과에 필요한 입력값이 달라지는 경우에만 실행된다. `useMemo` `useCallback`도 마찬가지다.

훅은 예제의 `user` 처럼, 해당 스코프에서 정보를 보고 유지할 수 있기 때문에 클로져의 이점을 누릴 수 있다. 그러나, 이러한 종속성이 암묵적이어서, 이 사이드 이펙트가 언제 실행되어야 하는지 알 수 없다.

클로져는 훅 api에 일련의 `dependencies`가 필요한 이유다. 이 결정은 프로그래머가 이러한 암묵적인 의존성을 명확히 하는 책임을 지도록 강요하고, 따라서 일종의 '휴먼 컴파일러'로서 기능한다. dependencies를 선언하는 것은 수동으로 하는 보일러 플레이트 작업이며, C 메모리 관리와 같이 오류가 발생하기 십상이다.

이 문제를 해결하기 위한 리액트의 해결책은 `eslint` 이지만, 리액트 훅을 커스텀 훅으로 구성하면 문제가 또 발생한다.

이 문제를 완전히 피할 수 있는 방법은, 훅을 컴포넌트 외부로 이동시키는 것이다. 이렇게 한다면, 의존관계로 사용할 수 있는 인수를 강제적으로 건내받을 수 있게 된다.

```javascript
const createEffect =
  (fn) =>
  (...args) =>
    useEffect(() => fn(...args), args)
const useDebugUser = createEffect((user) => {
  console.log(user.name)
})

function User({ user }) {
  useDebugUser(user)

  return <span>{user.name}</span>
}
```

훅을 클로져 외부로 이동시키면, dependencies를 수동으로 추적하거나 subscription이 부족해지는 문제 (`dependencies`가 모자른)에 직면할 필요가 없다. 그러나 여전히 리액트와 자바스크립트가 두 종속성이 같은지를 판단하는 문제에 대해서는 여전히 취약하다.

## 동일성과 메모리

동일성이라고 한다면, 변하지 않은 것 이라고 이해하 면 쉽다. 예를 들어, 3은 언제나 3이다. 자바스크립트에서는, 이러한 동등 비교를 실행할 수 있는 여러가지 방법이 있다. 예를 들어, `==` `===` `Object.is`는 완전히 다른 방식이며, 각 다른 결과를 얻을 수 있다. `Object.is`의 경우, 연산한 값이 같은지 확인한다.

- 두 개가 `undefined` 인지
- 두 개가 `null`인지
- 두 개가 `true` `false` 인지
- 두 개가 `+0` 인지
- 두 개가 `-0` 인지
- 두 개가 `NaN`인지
- 혹은 0, `NaN`이 아니며 같은 값을 가지고 있는지
- 문자열의 경우, 크기와 구성하고 있는 글자가 같은 순서인지
- 나머지 non-primitive의 경우, 이들은 mutate하기 때문에, 메모리 참조가 같은지 비교한다. 이는 일반적인 개발자의 직관과 다르다. `Object.is([], [])`는 두 배열 객체의 메모리 포인터가 다르므로 `false` 가 나온다.

> [MDN 문서](https://developer.mozilla.org/ko/docs/Web/JavaScript/Reference/Global_Objects/Object/is#%EC%84%A4%EB%AA%85) 참고

## 훅과 동일 비교

훅은 dependencies를 비교할 때 `Object.is`를 사용한다. 따라서 의존성을 비교했을 때, 이 둘이 다를 때만 실행 된다. 여기서 같다는 것은 `Object.is`를 사용하여 비교한다.

```javascript
const User({ user }) {
  useEffect(() => {
    console.log(`hello ${user.name}`)
  }, [user]) // eslint barked, so we added this dependency

  return <span>{user.name}</span>
}
```

위 컴포넌트에서, `useEffect`는 얼마나 실행될까? 알 수 없다. `user`가 달라지는 횟수 만큼 실행될 것이다. `user`가 메모리에 어떻게 할당되었는지 모른다면, 이 객체가 어떻게 동일 비교를 할 수 있는지 알 수 없다. 즉 이 코드는 동작할 수 있지만, 올바르지 않으며 상위컴포넌트에서 변경이 일어나면 완전히 망가질 수도 있다.

```javascript
function App1() {
  const user = { name: 'paco' }

  return <User user={user} />
}

const user = { name: 'paco' }
function App2() {
  return <User user={user} />
}
```

위 예제에서, 우리는 훅의 미묘한 부분을 알 수 있다.

`App1`은 매번 새로운 객체를 할당한다. 이 객체는 개발자가 볼 때는 항상 동일하지만, `Object.is`가 볼 때는 그렇지 않다. 즉, 이 컴포넌트는 렌더링 할 때마다 `useEffect`가 실행될 것이다.

`App2`는 항상 같은 객체 포인터를 참조한다. 즉, 렌더링 횟수에 관계없이 사이드 이펙트가 실행되는 것은 한번 뿐이다.

실제 코드는 이보다 훨씬 더 복잡하기 때문에, 개발자는 객체가 언제, 얼마나 할당되는지 이해하기 쉽지 않다.

이번엔 실제 프로덕션에서 사용될 법한 코드를 살펴보자.

```javascript
function App({ options, teamId }) {
  const [user, setUser] = useState(null)
  const params = { ...options, teamId }

  useEffect(() => {
    fetch(`/teams/${params.teamId}/user`)
      .then((response) => response.json)
      .then((user) => {
        setUser(user)
      })
  }, [params])

  return <User user={user} params={params} />
}
```

위 예제는 동일한 요청을 반복적으로 시도할 것이다. 객체를 재구성하게 되면, 렌더링 시마다 새로운 객체를 할당하므로 `useEffect`의 dependencies로 사용하기에는 부적절하다.

## 결론

훅은 다른 기술과 마찬가지로, 새로운 기술로서의 일종의 과대 광고 효과를 어느정도 누렸다고도 볼 수 있다. 많은 개발자가 상태 관리 솔루션 대신, 상태 저장 로직을 구현하기 위해 훅을 채택했다. API는 쉬워 보이지만, 그 내부 동작은 복잡하기 때문에 부정확할 위험이 높아진다.

대부분의 버그는 컴포넌트에서 훅을 떼고, 유일한 의존관계로 primitive 를 사용하여 해결할 수 있다. 타입스크립트를 사용하는 경우, 자체 훅을 만들어 엄격하게 입력하고 관리할 수 있다. 이를 통해 개발자들이 훅이 가진 한계를 이해하는데 큰 도움이 될 수 있다.

```typescript
type Primitive = boolean | number | string | bigint | null | undefined
type Callback = (...args: Primitive[]) => void
type UnsafeCallback = (...args: any[]) => void

const createEffect =
  (fn: Callback): Callback =>
  (...args) => {
    useEffect(() => fn(...args), args)
  }

const createUnsafeEffect =
  (fn: UnsafeCallback): UnsafeCallback =>
  (...args) => {
    useEffect(() => fn(...args), args)
  }
```


deps에 primitive 값만 사용하기, 훅을 컴포넌트에서 제거하기

리액트 훅을 사용할 때 조심해야 할 것

## Table of Contents

## Introduction

[remix](https://remix.run/)는 새로운 리액트 기반 풀스택 웹 프레임워크다. 뭐 어떤 프레임워크고 어떻게 쓰는지는 remix 홈페이지에 잘 나와 있으므로, nextjs에서의 관점에서 remix는 어떤 웹 프레임워크고 무엇이 좋은지, 또 쓸만은 한지 한번 고민해보려고 한다.

## 클라이언트 - 서버 아키텍쳐

### nextjs

먼저 nextjs가 어떻게 애플리케이션을 구조화 하는지를 살펴보자. 일반적으로 nextjs에서는 클라리언트와 서버간의 통신을 위해서 클라이언트의 javascript에 의존하는 경우가 많다. 아래 예제를 살펴보자.

```jsx
// pages/contact.tsx

export default function ContactPage() {
  // form에 전송할 정보
  const [name, setName] = useState(null)
  const [email, setEmail] = useState(null)
  // form 제출 상태와 관련있는 상태 값
  const [submitting, setSubmitting] = useState(false)
  const [errors, setErrors] = useState(null)
  // 실제 클라이언트에 렌더링되는 form
  return (
    <form onSubmit={handleSubmit}>
      <input type="text" name="name" />
      {errors?.name && <em>Name is required</em>}
      <input type="text" name="email" />
      {errors?.email && <em>Email is required</em>}
      <button type="submit">Contact me</button>
    </form>
  )
  async function handleSubmit(e) {
    // form submit시 페이지로 넘어가지 않기 위해
    e.preventDefault()
    const formData = { name, email }
    // 클라이언트 측 validation
    const errors = validateForm()
    if (errors) {
      setErrors(errors)
    } else {
      setSubmitting(true)
      try {
        // 서버에 post 요청
        const response = await fetch('/api/contact', {
          method: 'POST',
          body: JSON.stringify({
            contact: {
              ...formData,
            },
          }),
        })
        const result = response.json()
        if (result.errors) {
          setErrors(result.errors)
        } else {
          // 홈으로 보내기
          router.push('/')
        }
      } finally {
        setSubmitting(false)
      }
    }
  }
}
```

그리고, nextjs에 `/api/` 동작을 추가할 수 있을 것이다.

```js
// pages/api/contact.js
export default function handler(req, res) {
  const { name, email } = req.body

  const errors = {}
  if (!name) errors.name = true
  if (!email) errors.email = true

  if (Object.keys(errors).length > 0) {
    res.status(400).json(errors)
  } else {
    await createContactRequest({ name, email })

    res.status(200).json({ success: true })
  }
}
```

이러한 방식은 nextjs에서 일반적인 방식으로, 위 코드에서 볼 수 있는 것 처럼 상당한 양의 자바스크립트 코드가 필요하다. (그리고 전체 페이지 번들에 hydration이 일어나지 않는다면 제대로 동작하지 않을 것이다.) 또한 위에 예제 처럼 수동으로 fetch 기반의 form을 만들어서 처리한다면, 비동기 fetch 이슈와 같은 문제도 처리해야 한다.

### remix

remix는 자바스크립트 코드를 훨씬 적게 썼던 php/rails 내부의 서버 템플릿 웹 앱 시절을 생각나게 한다. 아래 예제를 살펴보자.

```jsx
// app/routes/contact.tsx
export const action: ActionFunction = async ({ request }) => {
  const formData = await request.formData()

  const name = formData.get('name')
  const email = formData.get('email')

  const errors = {}
  if (!name) errors.name = true
  if (!email) errors.email = true

  if (Object.keys(errors).length > 0) {
    return errors
  }

  await createContactRequest({ name, email })

  return redirect('/')
}

export default function ContactPage() {
  // ActionFunction을 리턴으로 하는 action 함수가 기본으로 실행됨
  const errors = useActionData()
  return (
    <form method="post">
      <input type="text" name="name" />
      {errors?.name && <em>Name is required</em>}
      <input type="text" name="email" />
      {errors?.email && <em>Email is required</em>}
      <button type="submit">Contact me</button>
    </form>
  )
```

겉으로 보았을 때는 php 스타일로 작성된, post 핸들러를 갖춘 HTML form 일 뿐이다. 자바스크립트에 hydration이 이뤄지지 않더라도 이 코드는 작동한다. `useActionData`는 액션 핸들러에서 반환된 json 데이터를 사용할 수 있도록 한다. 이 액션 아키텍텨는 리액트를 풀스택 프레임워크로 정의하는 방법이다.

remix의 디자인은 기존의 브라우저가 지원하는 클라이언트 - 서버 모델을 본떠서 만들어졌기 때문에, 훨씬 더 적은 코드로 작성되었다.

이러한 방식에 익숙하지 않은 개발자들은, 이러한 핸들러에 일반적인 패턴이 다음과 같이 존재한다는 것을 인지하고 있어야 한다.

- validation이 실패하면, 에러를 서버로 부터 받고 동일한 페이지를 리렌더링 한다.
- validation이 성공하면 대상 페이지로 리다이렉트가 일어난다. 그리고 이 도착 페이지에 toast 메시지를 노출할 수 있다. (remix에는 빌트인 [session](https://remix.run/docs/en/v1/api/remix#using-sessions)이 있는데, 이를 활용하면 된다.)

만약 한 페이지에 여러개의 form이 있다면?

숨겨진 필드를 사용하여 각 form이 무엇을 나타내는지를 구별하거나, submit button에 추가적인 값을 넘겨주면 된다.

만약에 일반적인 REST API를 쓰고 싶다면?

nextjs의 경우에는, api 엔드포인트는 임의의 페이지와 클라이언트를 서비스할 수 있는 일반적인 REST api의 일부였다. 이에 반해 remix는 `loader` 함수를 정의하여 (뒤에서 설명) 임의의 데이터를 반환하는 라우트인 리소스 라우트를 정의할 수 있다. nextjs와 다르게, `/pages/api`에 위치할 필요는 없다.

만약 클라이언트 측에서 인터랙션이 있는 form validation을 사용하고 싶다면?

`Form`과 함께 `useTransition`을 사용하면 된다. (리액트의 `useTransition`과 다름 주의)

```jsx
// app/routes/contact.tsx

export const action: ActionFunction = async ({ request }) => {
  /*...*/
}

export default function ContactPage() {
  // 서버의 에러를 JSON 형태로 받을 수 있음. 이 경우에는 페이지를 리로드 하지 않고도 form을 리렌더링 할 수 있음
  const errors = useActionData()
  // form 성공시
  const { submission } = useTransition()
  return submission ? (
    <Confirmation contact={Object.fromEntries(submission.formData)} />
  ) : (
    <Form method="post">...</Form>
  )
}
```

서버사이드에서는 여전히 validation을 수행하지만, 이제 빠르게 클라이언트에서 피드백을 반영할 수 있다. 클라이언트 측에서 validation을 하고 싶을 경우, 추가적으로 로직을 추가하여 클라이언트에서 validation을 실행할 수 있다.

다만 이 경우 클라이언트가 JSON 데이터 fetch를 수행하거나, 자바스크립트를 아직 사용할 수 없는 경우 전체 html 응답을 요청하여 서버와 통신할 수 있다는 점이다.

## 항상 SSR

remix는 항상 서버사이드 렌더링이 일어나며, 특정 페이지가 정적으로 생성되는 것을 표시하는 개념을 지원하지 않는다. 그렇다고 정적 사이트를 만들 수 없다는 것은 아니다.

기본적인 측면에서, 서버 사이드 데이터 fetch 및 렌더링 속도가 충분하게 빠를 경우, edge server에 배치하여 정적 사이트 수준의 성능을 달성할 수 있다. (자세한 방법은 하단 예시를 참조)

그러나 이 방법은 언제나 가능한 것은 아니고, 페이지가 본질적으로 느린 백엔드 서비스에 의존할 수 있다. 이 경우 http 캐시를 활용할 수 있다. CDN을 서비스 인프라 최상단에 두고, 올바른 `Cache-Control` 헤더를 사용하면 CDN이 지연 시간을 최소화 하면서 변경되지 않은 콘텐츠를 저장하고 제공할 수 있다.

이를 통해 정적 사이트 빌드를 수행하는 대신, 변경 사항을 즉시 재구현 할 수 있다는 이점이 있다.

```jsx
// app/routes/some-page.tsx

export function headers() {
  return {
    'Cache-Control':
      'public, max-age=300, s-maxage=3600, stale-while-revalidate=300',
  }
}

export default function SomePage() {
  return <div>...</div>
}
```

이는 트레이드 오프가 있다. 직접적으로 프레임워크 수준에서 제어되는 invalidation을 포기하는 대신, CDN에 있는 전용 cache flushing 로직에 의존해야 한다. 사용자의 브라우저에서 캐시를 무효화하는 것 또 고려해야 하므로, 캐시 만료에 너무 지나치게 적극적으로 대응하지 않는 것이 좋다.

## hydration

Nextjs에서 달성하고자 하는 기능 중 하나는 부분적인 hydration이다. 특히 정적인 컨텐츠의 경우, 리액트 SSR/SSG 프레임워크는 필요한 자바스크립트 번들 보다 훨씬 더 많이 전달되고 hydration 되므로, 페이지 로드 성능에 큰 영향을 미칠 수 있다.

Remix는 개발자에게 언제 hydration이 일어날 수 있는지 결정할 수 있게 해준다. 하지만 현재는 페이지 단위로만 제공되고 있다. 이 방법은 조건부로 `Document` 내부의 `<Scripts/>`를 렌더링 하지 않는 것이다.

https://remix.run/docs/en/v1/guides/disabling-javascript

```jsx
// app/entry.server.tsx

import React from 'react'
import { Meta, Links, Scripts, Outlet, useMatches } from 'remix'

export default function App() {
  let matches = useMatches()

  // 아래 코드 참조
  let includeScripts = matches.some((match) => match.handle?.hydrate)

  // includeScripts 상태 값으로 제어 가능
  return (
    <html lang="en">
      <head>
        <meta charSet="utf-8" />
        <Meta />
        <Links />
      </head>
      <body>
        <Outlet />
        {/* 스크립트 제어! */}
        {includeScripts && <Scripts />}
      </body>
    </html>
  )
}
```

```jsx
// app/routes/some-page.tsx

export let handle = { hydrate: true }

export default function SomePage() {
  return <div>...</div>
}
```

Remix 개발자가 현재 부분적인 hydration을 할 수 있는 방안에 대해서 아주 깊게 연구 하고 있다고 하니 기대해봄직하다.

## 스타일

스타일을 적용하기 위해서는, header에 링크를 추가하면 된다. 이는 HTML 에 스타일 시트를 추가하는 것과 매우 유사하다. remix에 이러한 스타일 정보를 미리 제공하면, 모든 CSS를 캐시 가능한 스타일 시트 URL과 함께 병렬로 로딩할 수 있으므로, `prefetch`와 함께 사용한다면 최적의 페이지 로드 성능을 얻을 수 있다.

> 이와 관련되서 스타일 순서가 보장되지 않는 nextjs의 오랜 버그가 있다. https://github.com/vercel/next.js/issues/16630

```jsx
// app/routes/some-page.tsx

import styles from '~/styles/global.css'
// styles is now something like /build/global-AE33KB2.css

export function links() {
  return [
    {
      rel: 'stylesheet',
      href: 'https://unpkg.com/modern-css-reset@1.4.0/dist/reset.min.css',
    },
    {
      rel: 'stylesheet',
      href: styles,
    },
  ]
}

export default function SomePage() {
  return <div>...</div>
}
```

https://remix.run/docs/en/v1/guides/styling

위 가이드를 보면 알겠지만, scss, css, css-in-js를 사용해도 `links`를 통해서 스타일을 노출 시키는 것은 필수사항이다.

## 파일 기반 라우팅

remix는 nextjs를 사용하는 사람에게 매우 친숙한 파일 기반 라우팅을 사용한다. 그러나 nextjs 와 다르게 경로를 계층으로 구성할 수 있는 React Router 스타일의 중첩을 지원한다.

예를 들어, 아래와 같은 라우팅이 있다고 가정해보자.

- `/dashboard`
- `/dashboard/settings`
- `/dashboard/reports`

```jsx
// app/routes/dashboard.tsx

export default function DashboardLayout() {
  return (
    <div>
      <Header />
      {/* 내부 중첩 라우팅에 필요한 컨텐츠가 들어간다. */}
      <Outlet />
      <Footer />
    </div>
  )
}
```

```jsx
// app/routes/dashboard/settings.tsx
export default function Settings() {
  // ...
}
```

```jsx
// app/routes/dashboard/reports.tsx
export default function Reports() {
  // ...
}
```

```jsx
// app/routes/dashboard/index.tsx
export default function DashboardMain() {
  // ...
}
```

nextjs와 마찬가지로 remix는 isomorphic routing을 지원하므로 js에 hydration이 발생한다면 클라이언트에서 전환이 빠르게 일어난다.

## 경로 위치에 있는 데이터 가져오기

nextjs에서는 페이지 내부의 `getStaticProps` 또는 `getServerSideProps`에서 데이터를 가져올 수 있다. remix에서는 nextjs와 같은 방식으로 페이지 라우팅에 필요한 `loader` 함수를 사용할 수 있다. 마찬가지로, SSR 응답에 JSON으로 이 데이터를 직렬화한다.

```jsx
// app/routes/mypage.tsx

// 데이터를 가져온다. 이는 서버에서 수행된다.
export async function loader() {
  return fetch(/*...*/)
}

export default function MyPage() {
  const data = useLoaderData()
  return <div />
}
```

그러나 remix의 `loader`가 다른 점은 페이지 레벨 뿐만 아니라 중첩 라우팅에서도 사용이 가능하다는 것이다.

이것의 이점은, 데이터를 배치하는 것이 용이 해진다는 것이다. 예를 들어 `/dashboard`라는 루트 라우팅이 있을 경우, 하위 라우팅에 공통 페이지 레이아웃을 렌더링 할 수 있다는 것이다.

```jsx
export async function loader() {
  return getCurrentUser()
}

export default function DashboardLayout() {
  const currentUser = useLoaderData()
  return (
    <div>
      <Header>
        <UserAvatar user={currentUser} />
      </Header>
      {/* 하위 렌더링 페이지가 여기에 배치된다. */}
      <Outlet />
      <Footer />
    </div>
  )
}
```

그리고 ` /dashboard/settings` 에 또다른 `loader`가 있다고 가정해보자. 루트는 이에 대해 관심이 없으며, 마찬가지로 다른 페이지에서도 이에 대해 가지고 있을 필요가 없다. nextjs에서는 `getServerSideProps`의 일부를 분산하여 이를 수동으로 구현할 수 있지만, remix는 좀더 자연스러운 지원을 제공한다.

```jsx
// parent route
import { Outlet } from 'remix-utils'

export default function Parent() {
  return <Outlet data={{ something: 'here' }} />
}
```

```jsx
// child route
import { useParentData } from 'remix-utils'

export default function Child() {
  const data = useParentData()
  return <div>{data.something}</div>
}
```

이러한 분산된 fetch 설계는 스타일 시트의 링크와 마찬가지로, remix가 전체 트리의 데이터 의존성을 미리 알고 있기 때문에 별렬로 실행할 수 있다는 장점이 있다.

## 배포

remix는 vercel, cloudflare worker, deno deploy, fly.io와 같은 다양한 배포 환경을 지원한다. 각 배포에는 프로젝트 별로 약간 다른 구성 및 패키지가 필요할 수 있겠지만, 노드 환경과 비노드 환경 (cloudflare)에서 모두 실행 가능하다.

특정 배포 대상에 따른 remix 설정은 `create-remix`를 사용할 때 자동으로 구성되지만, 기본 설정에서 다른 설정으로 옮겨갈 경우에는 약간의 수정을 추가하면 된다.

## 기타

- remix 내부에는 세션과 쿠키를 처리할 수 있는 함수가 내장되어 있으며, 이는 클라이언트 서버 아키텍쳐에서 중요하다.
- `app/routes/reports/$report.tsx` 형태의 동적 라우팅을 지원한다. nextjs는 `[param]`, remix는 `$param`이다.
  ```jsx
  export default function Report() {
    // ...
    return <div>...</div>
  }
  ```
- nextjs 에 글로벌 `App` `Document` Wrapper가 있다면, remix에는 `entry.server.tsx`가 있다. 또한 `entry.client.tsx`를 사용하여 hydration과정에서 정확히 어떤일이 일어나는지 확인할 수 있다.
- nextjs에 있지만 remix에 없는 것은
  - 이미지 최적화 컴포넌트 `next/image`
  - 구글 폰트와 Typekit를 위한 자동 폰트 CSS 인라이닝
  - 스크립트 스케쥴링 및 우선순위 지정과 같은 세부적인 제어

## 느낀점

- react-router-dom 스타일의 중첩 routing 지원, 그리고 부모 데이터를 불러올 수 있는 기능이 인상적이다. nextjs는 페이지별로 다 찢어져있어서 특정 페이지들을 위한 context 구현이 opt-out 하지 않는 이상 불가능 했는데 이점은 굉장히 맘에 든다.
- static한 페이지가 많은 애플리케이션은 여전히 nextjs가 더 좋은 방식을 제공하고 있는 것 같다. CDN과 cache를 사용하는 것은 물론 기존에 있는 접근이지만 서도, nextjs가 더 편리한 방식으로 구현했다고 본다.
- 기본적으로 ssr이라는 점은 좋은 것 같다. 프론트엔드 개발자들이 static 파일을 upload하고 서빙하는 시대는 지났다. 이제 node 서버, 더 나아가 배포와 devOps에 대해서도 고민해야할 때가 왔다. (사실 진작에 왔다)
- 위와 마찬가지로, SPA의 패러다임은 이제 조금씩 쇠퇴하고 있는 느낌이다. 기기의 성능이 갈수록 좋아지는 시대일 수록 SPA가 빛을 발한다는 이야기를 들었던 것 같은데 이제 틀린게 아닌가 싶다. 성능을 사용자의 기기에 의존해서는 안된다.
- javascript가 실행되지 않는 환경을 고민하는 것 또한 인상적이다. 성능 측면에서 우리가 항상 고민해봐야할 문제다.
- 다음 토이 프로젝트는 remix다.


늘 새로워 짜릿해 새로운게 또 나왔어

React 2

React.FC를 사용하지 않는 이유

리액트 훅을 사용할 때 조심해야 할 것

Remix nextjs와 비교하면서 살펴보기

리액트 서버 컴포넌트의 동작 방식

리액트 18에서 변경될 새로운 SSR 아키텍쳐