이 글은 여기서 더 멋지게 볼 수 있습니다.

블로그 레포지토리는 여기서 확인하실 수 있습니다.

Intro

notion 을 통한 기존의 에디터 경험은 살릴 수 있으면서도 블로그 CMS로서 유용한 기능들을 제공할 수 있도록 추가한 다음의 기능들에 대해 공유 해보고자 한다.

• 블로그 데이터를 만들기 위한 데이터베이스 구축
• 블로그 글을 개성넘치는 웹페이지로 보여주기 위한 렌더링 기능
• 노션 이미지의 한계를 극복하기 위한 이미지 업로드
• 정적 페이지를 빌드 없이 쉽게 업데이트 하도록 파이프라인 만들기

이를 구축해놓으면 notion 을 에디터를 넘어서 편리한 블로그 CMS가 될 수 있도록 만들 수 있다.

💾 notion을 데이터베이스로 활용하기

데이터베이스 구축하기

notion 에 작성한 블로그 글을 데이터로서 활용하기 위해 데이터베이스를 구축하는 작업이다. 여기서는 notion 에서 데이터베이스라는 block을 활용한다.

이 데이터베이스 블록을 통해 블로그 데이터를 아래와 같이 표의 형태로 만들어낼 수 있다. 구축하려는 사람의 목적마다 다르겠으나 나의 경우에는 다음과 같이 테이블의 컬럼들을 생성하였다.

• id : 게시글 별 고유 ID
• name : 게시글 제목
• description : 블로그 게시글 요약 문장
• tags : 게시글 토픽과 관련한 주제 태그들
• releasable : 초안이 아니라 블로그에서 보여줄 수 있는 글인지를 표시하는 데이터
• featured : 인기 게시글로 구분되는 글인지를 표시하는 데이터
• createdAt : 블로그 게시글 생성일자
• updatedAt : 게시글 업데이트 일자
• thumbnailUrl : 블로그 게시글 썸네일 이미지
• prevArticleId : 이전 게시글로 연결될 게시글 고유 ID
• nextArticleId : 다음 게시글로 연결될 게시글 고유 ID

notion에서 데이터 추출하기 위한 사전 준비

여기서 관련된 가이드 내용이 자세히 설명되어 있지만 API를 통해 데이터를 추출하려면 사전 준비가 필요하다.

로그인 한 뒤 https://www.notion.so/profile/integrations 로 이동해서 API 통합을 추가해주어야 한다.

또한 콘텐츠 기능과 관련한 권한들을 모두 사용할 수 있게 모두 허용해주면 준비가 완료된다. 통합 시크릿 키는 API를 사용해야할때 쓰일 것이다.

notion에서 데이터 추출하기

notion API를 직접 활용할수도 있으나 노션에서 공식적으로 제공하는 sdk (@notionhq/client) 를 활용하면 보다 쉽게 데이터를 추출할 수 있다.

import { Client } from '@notionhq/client'

export const notion = new Client({
  auth: process.env.NOTION_TOKEN, // 아까 통합 생성시 발급되는 시크릿 키
})

우선 앞서 통합을 생성하면서 만들어진 API 시크릿 키를 활용해 다음과 같이 클라이언트 인스턴스를 생성해줘야 한다.

API가 추출할 수 있는 데이터는 크게 두가지로 페이지 자체에 대한 데이터를 추출하는 query 와 데이터베이스의 메타데이터를 추출할 수 있는 retrieve 가 있다. 쉽게 설명할 수 있게 예를 들어 설명하자면,

내가 작성한 모든 게시글들 중 블로그들에 표시될 수 있는 게시글 데이터들을 뽑아오기 위해서 다음과 같이 query 를 사용해볼 수 있다. 아래에서는 releasable 컬럼이 true 값인 게시글들을 모아 createdAt 컬럼을 오름차순으로 정렬하여 뽑아낸다.

// 블로그의 모든 게시글들 뽑아내기
const queryResponse = await notion.databases.query({
    database_id: process.env.NOTION_DATABASE_ID!, // notion에서 참조하고 있는 데이터베이스 ID
    filter: {
      and: [
        {
          property: 'releasable',
          checkbox: {
            equals: true,
          },
        },
      ],
    },
    sorts: [
      {
        property: 'createdAt',
        direction: 'descending',
      },
    ],
  })

반면, 내가 아래와 같이 데이터베이스에서 설정한 tag들의 목록을 뽑아내래면 retrieve 를 활용할 수 있다. retrieve 는 주로 데이터베이스의 입력된 row 들 보단 column 자체와 관련된 정보들을 뽑아낼 때 사용한다.

const metaDataResponse = await notion.databases.retrieve({
    database_id: process.env.NOTION_DATABASE_ID!,
}).properties.tags.select_options

📝 notion 마크다운 데이터의 렌더링

노션 API로부터 추출된 데이터를 HTML로 렌더링 하는 방법에는 크게 두가지가 존재했다.

react-notion-x

import { NotionAPI } from 'notion-client'
import { NotionRenderer } from 'react-notion-x'

const notion = new NotionAPI()

const recordMap = await notion.getPage('067dd719a912471ea9a3ac10710e7fdf')

<NotionRenderer recordMap={recordMap} fullPage={true} darkMode={false} />

react-notion-x 라는 라이브러리를 활용하면 간단한 코드 몇줄로 마크다운 데이터를 HTML 페이지로 렌더링 해준다. 노션 데이터를 불러오는 것은 notion-client 라는 라이브러리가 대신 수행하며 이 값을 NotionRenderer 컴포넌트에 넘겨주면, 아래와 같은 화면이 완성된다.

노션과 완전히 동일한 화면이 출력되는 것을 볼 수 있다. 이것이 장점이자 단점이 되었다. 나는 보라색 테마의 블로그를 디자인했고 이에 맞게 렌더링 하고 싶었는데 react-notion-x는 이를 커스텀하기가 다소 어려운 구조였다. 이 때문에 이 방식을 내가 사용하기에는 어려웠다.

notion → markdown → html

두번째 방법은 notion 데이터를 마크다운으로 변환하고 이를 또 한번 HTML로 변환하는 방식이다. 이는 앞선 react-notion-x 와 다르게 높은 자유도를 제공한다.

1️⃣ notion → markdown

우선은 마크다운으로 변환할 수 있도록 하는 notion-to-md 라이브러리를 사용한다.

import { Client } from '@notionhq/client'
import { NotionToMarkdown } from 'notion-to-md'

export const notion = new Client({
  auth: process.env.NOTION_SECRET_ID!,
})

export const n2m = new NotionToMarkdown({
  notionClient: notion,
})

export const fetchArticleContent = async (pageId: string) => {
    const mdBlocks = await n2m.pageToMarkdown(pageId)
    return n2m.toMarkdownString(mdBlocks)
}

노션의 sdk인 @notionhq/client 를 통해 받아온 데이터를 NotionToMarkdown 을 통해 마크다운 문자열 형태로 파싱하는 방식이다.

2️⃣ markdown → html

다음은 파싱된 마크다운을 HTML 로 변환하는 과정이다. 여기서는 마크다운을 리액트 컴포넌트로 렌더링 시켜주는 react-markdown 라이브러리를 활용한다. 앞서 언급했듯, 자유도가 높은 방식이기 때문에 내가 일일이 어떻게 렌더링 해야할지 지정해줘야해서 여러가지 플러그인들과 커스텀 컴포넌트들을 사용해야 한다.

import ReactMarkdown from 'react-markdown'

// 플러그인들
import remarkGfm from 'remark-gfm'
import rehypeRaw from 'rehype-raw'
import remarkToc from 'remark-toc'
import rehypeHighlight from 'rehype-highlight'
import remarkRehype from 'remark-rehype'
import rehypeSlug from 'rehype-slug'
import rehypeAutolinkHeadings from 'rehype-autolink-headings'
import 'highlight.js/styles/base16/dracula.min.css'

const { parent: content } = await fetchArticleContent()

<ReactMarkdown
  remarkPlugins={[remarkGfm, remarkToc, remarkRehype]}
  rehypePlugins={[
    rehypeRaw,
    rehypeHighlight,
    rehypeSlug,
    rehypeAutolinkHeadings,
  ]}
  ...
>
  {content}
</ReactMarkdown>

플러그인들 부분부터 살펴보자. 우선, 플러그인은 크게 2가지 종류로 나뉘며 각각의 역할이 다르다.

• remark : 마크다운 파싱 역할을 하는 플러그인들
  • remark-gfm - 마크다운 내 table, todo-list과 같은 요소를 알맞게 파싱해주는 플러그인
  • remark-toc - table of content(목차 부분) 생성을 도와주는 플러그인
  • remark-rehype - rehype가 호환되게 주어진 마크다운을 html로 파싱하는 플러그인
• rehype : html 로 파싱하는 역할을 하는 플러그인들
  • rehype-raw - 마크다운을 알맞은 형태의 html 로 파싱하는 역할을 하는 플러그인 (ex - <br/> <em/> 등을 썻을때 html과 같은 효과를 내게 공백을 조정)
  • rehype-highlight - highlight.js 를 활용해 마크다운 내 코드 block을 알맞은 형태로 변환 해주는 플러그인
  • rehype-slug - 마크다운 헤더 요소에 id를 자동으로 부여하는 플러그인으로 목차내의 특정 요소를 클릭할때 해당 블럭으로 이동시키는 역할을 한다
  • rehype-autolink-heading - rehype-slug와 연계해서 heading 요소에 링크 연결 버튼 같은 것을 생성하도록 해준다.

이외에도 수많은 플러그인들이 있으니 용도에 맞게 사용하면 될것이다.

export const Table = ({
  className,
  ...props
}: DetailedHTMLProps<TableHTMLAttributes<HTMLTableElement>, HTMLTableElement>) => {
  return <table className={clsx(className, styles.table)} {...props} />
}

<ReactMarkdown
    ...
  components={{
    h1: props => <Heading as="h1" {...props} />,
      ...
    hr: Divider,
    img: Image,
    ul: props => <List as="ul" {...props} />,
    ol: props => <List as="ol" {...props} />,
    li: ({ children }) => (
      <Text as="li" variant="body2" color="textPrimary">
        {children}
      </Text>
    ),
    a: Anchor,
    p: Paragraph,
    blockquote: BlockQuote,
    code: CodeBlock,
    table: Table,
    th: Th,
    td: Td,
  }}
>
  {content}
</ReactMarkdown>

다음은 HTML로 파싱되어 렌더링될때 어떤 스타일링을 입혀 표시할지 커스텀하는 부분이다. 헤더, 이미지, listbox, anchor, code 등 렌더링 시 사용되는 많은 html 태그들을 원하는 스타일링이 적용된 컴포넌트로 치환해주어야 한다.

컴포넌트를 넣어주기 전과 후를 비교하면 얼마나 큰 역할을 하는지 체감할 수 있을 것이다.

🌠 notion의 이미지를 영구적으로 바꾸기

notion 자체 이미지는 글을 작성하면서 업로드 하기만 바로 연동이 되어 제공이 되기에 매우 편리하다. 하지만, notion 의 업로드하는 이미지는 링크로 제공될때 만료기간이 존재한다.

{
    "url": "https://s3.us-west-2.amazonaws.com/secure.notion-static.com/9bc6c6e0-32b8-4d55-8c12-3ae931f43a01/brocolli.jpeg?...",
    "expiry_time": "2020-03-17T19:10:04.968Z"
}

실제 노션에 업로드된 이미지를 API를 통해 block 형태로 조회하면 다음과 같이 url 과 만료기간이 함께 제공된다. 그리고 공식문서에 따르면 해당 파일의 공개 URL은 1시간마다 만료된다. 이 때문에 노션 API로 불러온 이미지 데이터는 1시간마다 만료되어 제대로 된 이미지를 렌더링하지 못한다.

이러한 문제를 해결할 수 있도록 블로그 게시글을 추가하는 과정에서 이미지 블락들의 찾아내어 notion에 호스팅된 이미지 URL을 외부 저장소를 통해 이미지를 업로드 하는 작업이 필요하다.

위와 같은 이미지 변환 작업의 과정들을 정리해보자면 다음과 같다.

• notion API로부터 이미지 block 데이터들 불러오기
• 외부 저장소에 이미지를 업로드
• 업로드 한 이미지 URL로 notion에 업로드 된 이미지를 교체

1️⃣ 게시글에서 이미지 블록 모두 불러오기

notion API 를 이용해서 페이지 내에 있는 이미지 블록들을 모두 조회하는 과정이다. 이에 앞서 모든 블록들 부터 불러와야 한다.

export const fetchAllBlocksInPage = cache(
  async (blockOrPageId: string): Promise<GetBlockResponse[]> => {
    let hasMore = true
    let nextCursor: string | null = null
    const blocks: GetBlockResponse[] = []

    // 요청당 불러올 수 있는 블락 응답의 크기가 한정되어 있어 모든 블록들을 불러올때 까지
    // notion 페이지의 block들을 불러오는 과정들을 반복해야 한다
    while (hasMore) {
      const result: ListBlockChildrenResponse = await notion.blocks.children.list({
        block_id: blockOrPageId,
        start_cursor: nextCursor ?? undefined,
      })

      blocks.push(...result.results)
      hasMore = result.has_more
      nextCursor = result.next_cursor

      if (hasMore) {
        console.log('load more blocks in page...')
      }
    }

    // 블록들 중 자식요소로 있는 블록들을 찾아 이 역시 블러온다
    // 예를 들면 toggle block이 있을 것이다.
    const childBlocks = await Promise.all(
      blocks
        .filter(block => 'has_children' in block && block.has_children)
        .map(async block => {
          const childBlocks = await fetchAllBlocksInPage(block.id)
          return childBlocks
        }),
    )

      // 참고로 block들의 순서쌍은 보장되지 않는다
      // 어차피 렌더링 할때 사용되는 것은 아니므로 순서쌍이 보장될 필요는 없다
    return [...blocks, ...childBlocks.flat()]
  },
)

이렇게 모든 블록들을 불러왔으면 이미지 블록들만 간추려야 한다. 이때 block의 속성 중 type이 image 에 해당하는 것들만 찾아내면 된다.

export const fetchAllImageBlocksInPage = cache(async (pageId: string) => {
  const allBlocks = await fetchAllBlocksInPage(pageId)
  return allBlocks.filter(
    block => 'type' in block && block.type === 'image',
  ) as ImageBlockObjectResponse[]
})

2️⃣ 외부 저장소에 이미지 올리기(feat. cloudinary)

이제 notion으로부터 불러온 이미지를 업로드할 차례 이다. 우선 내가 예시로 들어 사용해볼 서비스는 cloudinary 이다. 이를 선택한 이유는 무료로 이미지를 업로드할 수 있으며 손쉽게 사용 가능한 자바스크립트 sdk를 오픈소스로 제공하고 있기 때문이었다.

이를 업로드 하기에 앞서, cloudinary 에 가입하는 절차가 필요하다.

가입하고 나서 위의 이미지 처럼 assets 탭을 선택하고 상단에서 folders 를 선택한 뒤에 원하는 이름으로 폴더를 하나 생성해준다.

또한, 설정 페이지에서 API key를와 API secret 값을 알아와야 한다. 그리고 아래와 같이 cloudinary 를 이용한 이미지 업로드 코드를 작성하면 된다

// 1. notion에 호스팅된 이미지를 base64 형태로 다운로드
// 2. cloudinary에 업로드

import https from 'https'
import { type UploadApiOptions, v2 as cloudinary } from 'cloudinary'

class CloudinaryApi {
  // 생성자를 통한 cloundinary sdk config 초기화
  constructor() {
      // cloundinary url 값
    const cloudinaryUrl = process.env.CLOUDINARY_URL!
    const urlRegex = /^cloudinary:\/\/([a-z0-9-_]+):([a-z0-9-_]+)@([a-z0-9-_]+)$/i
    if (!urlRegex.test(cloudinaryUrl)) {
      throw new Error(`Invalid Cloudinary URL provided. It should match ${urlRegex.toString()}`)
    }
    const [, apiKey, apiSecret, cloudName] = cloudinaryUrl.match(urlRegex) ?? []

    cloudinary.config({
      secure: true,
      api_key: apiKey,
      api_secret: apiSecret,
      cloud_name: cloudName,
    })
  }

  // 호스팅된 이미지를 다운로드 하여 base64 문자열로 변환
  private downloadImageToBase64(url: string): Promise<string> {
    return new Promise((resolve, reject) => {
      const req = https.request(url, response => {
        const chunks: unknown[] = []

        response.on('data', function (chunk) {
          chunks.push(chunk)
        })

        response.on('end', function () {
          const result = Buffer.concat(chunks as ReadonlyArray<Uint8Array>)
          resolve(result.toString('base64'))
        })
      })
      req.on('error', reject)
      req.end()
    })
  }

  // cloudinary uploader를 통해 이미지 업로드
  private uploadImage(image: string, options: UploadApiOptions = {}): Promise<{ url: string }> {
    return cloudinary.uploader
      .upload(image, options)
      .then(result => ({
        url: result.secure_url,
      }))
      .catch(error => {
        console.error(error)
        return { url: '' }
      })
  }

  // notion image를 영구 이미지로 변환
  async convertToPermanentImage(notionImageUrl: string, title: string) {
    const imgBase64 = await this.downloadImageToBase64(notionImageUrl)
    const { url: cloudinaryUrl } = await this.uploadImage(`data:image/jpeg;base64,${imgBase64}`, {
      // 앞서 cloudinary에서 생성했던 폴더명
      folder: process.env.CLOUDINARY_UPLOAD_FOLDER!,
      // 업로드되는 이미지의 제목 제목과
      public_id: title.split(' ').join('_').trim(),
      overwrite: true,
    })

    return cloudinaryUrl
  }
}

export const cloudinaryApi = new CloudinaryApi()

이러한 이미지 업로드 코드를 게시글 page 를 조회하는 코드와 notion block을 업데이트 하는 코드를 결합해 사용하면 다음의 코드가 완성된다.

// 주어진 pageId를 기반으로 페이지 내의 모든 이미지 블록들의 이미지 url을 변경하는 함수
export const updateImageBlocks = async (pageId: string) => {
  const allImageBlocks = await fetchAllImageBlocksInPage(pageId)

    // 모든 이미지 블록들에 대해서 다음의 과정들을 수행
  for (const [index, imageBlock] of allImageBlocks.entries()) {
    const { image, id: blockId } = imageBlock
    // notion에 직접 업로드된 이미지 파일들만 cloudinary에 업로드하여 변환
    if ('type' in image && image.type === 'file') {
      const convertedImageUrl = await cloudinaryApi.convertToPermanentImage(
        (image as FileImageBlock).file.url,
        `${pageId}_imageblock_${index + 1}`,
      )
      // cloudinary에 업로드 된 이미지 url로 이미지 블록들을 업데이트 한다
      await notion.blocks.update({
        block_id: blockId,
        image: {
          external: {
            url: convertedImageUrl,
          },
        },
      })
    }
  }
}

참고로, 노션에 직접적으로 호스팅된 이미지는 image.type 값이 file 로 나타나며, 외부 이미지는 external 값을 가진다. 또한 한번 cloudinary 에 업로드 된 이미지는 위의 조건문에 따라 cloudinary로 변환되어 업로드 되는 과정이 발생하지 않게 된다. 이로써 notion 에 업로드된 이미지도 영구적으로 호스팅 될 수 있게 되었다.

🔄 블로그 업데이트 자동화

정적인 형태로 제공하는 블로그 서비스에서 수정된 내용을 반영하기 위한 조치가 필요하다. 가장 간단하게는 다시 빌드해서 배포하는 방법이 있지만 이는 매우매우 비효율적이다. 내가 사용한 Next.js 프레임워크에서는 여러가지 방식으로 정적 컨텐츠를 업데이트 하는 방법들을 제공해주고 있다.

주기적인 업데이트

// app/blog/page.tsx

// 3600초 = 60분마다 업데이트 진행
export const revalidate = 6000

export default function Blog() {
  return (
    ...
  )
}

일정 주기마다 정적으로 생성해둔 페이지를 업데이트 하는 방법이다. 위와 같이 페이지 컴포넌트 내에서 revalidate 라는 값을 export 해주면 일정 주기마다 업데이트가 적용된다.

이렇게 일정시간 마다 업데이트 시키면, 컨텐츠가 업데이트 될 뿐만 아니라 앞서 언급한 notion 이미지 만료 문제의 경우, 매번 새로운 노션 이미지로 교체되기 때문에 해결해볼 수 있지 않을까 싶을 수 있다. 하지만 내가 외부 저장소로 이미지를 업로드를 해보기 전에 주기적인 업데이트 방법을 적용해봐도 제대로 이미지 URL이 갱신되지 않아서 간혹 이미지를 불러올때 502 에러가 주기적으로 발생했다.

이 뿐만 아니라 업데이트 된 내용이 실제로는 존재하지 않으면서도 전체적인 페이지 업데이트가 적용되는다는 점이 매우 비효율적이다.

필요할때 업데이트 하기 (on-demand)

export default async function Page() {
    const pageId = '...'

  // 페이지에서 불러오는 fetch 함수 호출 부분에 'collection' 태그를 추가해놓는다
  const res = await fetch('https://...', { next: { tags: [pageId] } })
  const data = await res.json()
  // ...
}

// app/api/revalidate/route.ts
// tag 갱신 endpoint -> 여기로 POST 요청을 보내면 페이지 데이터가 갱신된다
import { revalidateTag } from 'next/cache'

export async function POST(request: NextRequest) {
    const { pageId } = await request.json()

    revalidateTag([pageId])

    return Response.json({ revalidated: true })
}

또 다른 방법으로 on-demand revalidation 전략을 제공해주고 있다. 간단하게 서버 컴포넌트에서 불러온 데이터에 tag 를 바인딩하고 필요한 경우 nextjs 의 엔드포인트를 생성해서 해당 태그의 데이터를 갱신해주는 작업을 해줄 수 있다.

하지만 나같은 경우, 블로그 데이터를 불러올때 fetch 가 아닌 notion의 sdk 를 사용한 데이터를 사용하고 있었다. 이런 경우, fetch가 아닌 unstable_cache를 활용하여 데이터를 불러오는 부분을 감싸면 tag 바인딩이 가능하다.

import { unstable_cache } from 'next/cache'

export const fetchArticlePageContent = (pageId: string) => {
  const cacheKey = ARTICLE_CONTENT(pageId) // `${pageId}_content`

 // unstable_cache 
  return unstable_cache(
    async (pageId: string) => {
      await updateImageBlocks(pageId)

      const mdBlocks = await n2m.pageToMarkdown(pageId)
      return n2m.toMarkdownString(mdBlocks)
    },
    [cacheKey],
    {
      tags: [cacheKey],
    },
  )(pageId)
}

export const ArticleDetailContentSection = async ({ pageId }: ArticleDetailContentSectionProps) => {
  const { parent } = await fetchArticlePageContent(pageId)

  return <ArticleContentRenderer content={parent as string} />
}

이렇게 바인딩 해놓은 상태로 정적인 배포를 적용하고 업데이트가 필요한 시점에 revalidateTag 를 수행하는 API를 호출하면 페이지 업데이트를 손쉽게 진행할 수 있다.

💡 참고로 revalidateTag 를 실행하면 바로 업데이트가 수행되는 것이 아니라, revalidateTag를 실행한뒤 페이지 방문이 발생하면 그때서야 업데이트가 수행된다. 자세한 내용은 공식문서를 참고해주기를 바란다.

zapier로 revalidation 자동화하기

위의 방식으로 페이지 내용을 업데이트 하는 방법은 마련했지만, 이를 내가 직접 수행해줘야 한다는 번거러움이 있다. 누군가 노션 데이터베이스에서 업데이트 내역을 알아서 확인해서 페이지를 업데이트하는 API를 호출해줄 수 는 없는 것일까? 그것을 해주는 도구가 바로 zapier 이다.

zapier 는 여러가지 웹 앱들(Slack, Trello, Google Docs 등)을 통합해 자동화 할 수 있는 여러 기능들을 제공한다. 여기서 notion 통합을 이용하면 우리가 번거롭게 여기던 업데이트 과정을 자동화하도록 만들수 있다. 여기서 내가 만들어낼 작업을 다음과 같다

• notion 데이터베이스의 업데이트 내역을 포착한다
• 업데이트가 발생한 pageId를 알아낸다.
• 해당 pageId로 업데이트 API 요청을 보낸다

우선 zapier에서 zap 이라는걸 생성한뒤 노션의 업데이트를 감지하는 action 을 선택해주어야 한다.

이후에는 파악한 업데이트 내역을 바탕으로 API 호출을 할 수 있도록 하는 코드 액션을 선택해주면 된다. 여기서 아래와 같은 코드를 작성해 주면 된다. 여기서 주의해서 봐야할 것은 inputData 라는 변수는 앞서 액션에서 제공해주는 output 값이다.

// 이전 단계에서 불러온 database item
const item = inputData;

// database item의 releasable 속성이 false인 경우 함수 실행 중단
if (item.releasable === 'False') {
  console.log('impossible to revalidate')
  output = { revalidated: false, pageId: null }
  return;
}

// database item의 releasable 속성이 true인 경우
// 해당 item의 id를 추출하여 api 요청을 보낸다
const pageId = item.pageId;

// GET 요청을 보내기 위한 옵션 설정
const options = {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    pageId,
    revalidateKey: "xxxxxxxxxxxxx",
  })
};

// api 요청을 보내기 위한 url 설정
const url = `https://...../api/revalidate?pageId=${pageId}`;

let responseData = null

try {
  // fetch 함수를 사용하여 GET 요청을 보낸다
  const res = await fetch(url, options);
  // 요청에 대한 응답을 출력한다
  responseData = await res.json()  
  if(responseData.revalidated){
    console.log('success to revalidate')
  }
  else {
    console.log('fail to revalidate')
  }

}
catch(err) {
  console.log(err)
  console.log('fail to request')
}

// 응답 결과를 객체로 출력한다
output = { pageId, response: responseData, revalidated: responseData?.revalidated ?? false };

이렇게 자바스크립트 코드를 작성하여 action 을 완성한뒤 zap 을 완성해주면 자동화하는 과정이 완성된다.

결론

간단할 수 있는 블로그 프로젝트이지만, 나의 취향에 맞는 그리고 정말 편리한 블로그를 만들려다보니 여러가지 수고로운 작업들을 수행해야 했다. 하지만, 이러한 작업들 덕분에 나의 편리한 글쓰기 경험을 제공하기 위한 블로그를 완성할 수 있었다. 관련하여 궁금한 점이 있다면 언제든 댓글을 남겨주길 바란다.

이 글은 여기서 더 멋지게 볼 수 있습니다.

블로그 레포지토리는 여기서 확인하실 수 있습니다.

🥲 기존 블로그 사용의 문제점

기존에 사용하던 블로그 플랫폼인 velog 는 개발 블로그를 시작하기에는 더할나위 없이 좋은 플랫폼이 맞다. 특히나, 유동인구가 워낙 많아서 흐름에만 잘 편승(?)하면 좋아요를 많이 받아볼 수도 있었다. 이렇게 좋은 점도 있었으나 계속 블로그 글을 작성하기에는 아쉬운 점들이 많았다.

글 작성 과정에서의 번거러움

velog 의 에디터 자체는 글을 작성하기에는 나쁘지 않은 편이다. 하지만, 블로그 글의 길이가 길어서 쓰는 시간이 엄청 길어지면 브라우저 내에서만 글을 쓰기에는 어려움이 있었다. 왜냐하면 쓰는 시간이 하루를 넘어버리면 브라우저 탭을 실수로 닫아버리기 일 수 였다. 글을 쓰다가 실수로 임시 저장 을 누르지 않고 브라우저 탭을 닫아버리면… 그야 말로 대참사가 일어나는 것 이였다. 또한 글이 길어지면 내용을 스크롤이 길어지면서 검토하는 과정도 매우 번거러워 졌다.

그래서 나는 임시 방편으로 notion을 이용해 블로그를 작성하는 방식으로 바꿔보았다. notion은 태생이 에디터 이기에 글을 쓰는 경험도 매우 좋아서 나름 괜찮은 선택지였다.

노션과 velog는 다소 달랐다

notion으로 글을 쓰는것 까지는 괜찮다. 그런데 이제 velog로 옮기는 과정이 하나 추가된다. velog 로 옮기는 과정은 복사 붙이기만 하면 되니 매우 쉬운 것 아닐까?

이 첫번째 사진의 notion 글을 velog 로 옮겨보면 다음과 같아진다.

여기서 발생하는 문제점을 정리해보면 다음과 같다

• notion에는 잘 업로드 되었던 이미지가 velog 로 옮기면 망가져 버린다.
• notion 에서 보았던 글 모습과 velog 에서의 모습이 상당히 다르다 (간격이 좀 다르고, 블락도 의도된대로 보이지 않았다.)

이러다 보니 notion 에서 글이 잘 완성 되었다가도 velog 에서 올리기 위한 또 다른 작업이 필요했다. 이미지들 중 깨지는 것 마다 대응을 해주기 위해 notion에 있던 이미지를 다운받아서 다시 velog 에 올려야 했다.

또한 notion 에서 보이는 것과 다르게 velog 버전의 글에서 이상하거나 이상한 요소들은 내가 일일이 수정해줘야 했다. 특히나 길이가 긴 글과 같은 경우, 스크롤을 내리며 잘못된 요소를 찾아 수정을 하는 작업이 정말 번거로웠다.

이렇게 글을 쓰기 까지 매번 번거로운 작업들이 발생하게 되었고 이로 인해 글을 쓰는데 필요한 시간이 계속해서 늘어나게 되면서 글 하나를 작성하는게 망설여지기 시작했다. 이렇게 좋지 않은 나의 글쓰기 경험을 개선해보고자 기존의 블로그를 벗어나 새로운 블로그 방식을 만들어보자 라고 결심하게 되었다.

🎯 블로그 마이그레이션의 목표

이번 블로그 프로젝트를 진행하면서 이루고자 했던 목표들이다. 일차적인 최우선 과제는 나의 글쓰기 경험 향상이다.

나에게 편리한 글쓰기 경험 제공하기

노션의 좋은 글쓰기 경험은 살리면서도 스무스한 글 업로드가 가능하게 하고 싶었다. 즉, notion을 에디터로 활용하고 이로 부터 블로그에 업로드된 게시글을 추출해주는 작업이 필요했다. 다행히도 notion에서는 작성할 글을 마크다운 형태로 추출할 수 있도록 API가 마련되어 있었다.

또한, 이러한 API를 ORM 형태로 사용할 수 있게 클라이언트 라이브러리 (@notionhq/client) 도 마련되어 있어서 notion 의 데이터베이스만 잘 구축 해놓는다면, 데이터베이스와 백엔드 API가 마련된채로 웹서비스를 만들어낼 수도 있다. 이를 이용하는 과정에서는 정말 많은 시행착오가 있었는데 나중에 또 다른 글로 이에 대해서 이야기 해보고 싶다.

나만의 디자인으로 프로젝트 만들기

디자인에 무척 관심있던 나로서는 한번 쯤은 나만의 개성을 표현할 수 있는 사이트를 만들어 보고 싶었다. 이 때문에 개발에 착수하기에 앞서 디자인 과정부터 심혈을 기울였다 (덕분에 디자이너가 아닌 개발자 하기를 잘했다는 확신을 얻었다). 디자인 토큰 부터, 폰트, 반응형까지 신경쓰다보니 정말 힘들긴했다. 그래도 이러한 디자인 작업을 먼저 해둔 덕분에 나름 만족스러운 퀄리티가 나왔다는 생각이 들었다.

새로운 학습의 기회로 만들기

단순히 블로그 사이트 만들기로 이번 프로젝트 기회를 끝내버리고 싶진 않았다. 이번 블로그 프로젝트를 하면서 여러가지 학습적 요소들을 추가하며 의미있는 프로젝트를 만들어보고 싶었다.

• 모노레포 아키텍쳐 구성하고 이해하기
• 패키지 제작 및 배포에 대해 이해하기
• 디자인 시스템 제작하기
• 아이콘 에셋 패키지 만들어 보기

이러한 학습적 요소도 같이 하며 블로그 프로젝트를 하다보니 진행 시간이 굉장히 길어져버리긴 했다. 하지만 이 덕분에 정말 프론트엔드 엔지니어로서 많은 요소들을 배워볼 수 있었으며, 단기간에 많은 성장을 이뤄낼 수 있었다고 생각한다. 모노레포와 디자인시스템 그리고 아이콘 에셋에 대해서도 정말 할 얘기가 많아서 다른 포스트에서 다루어 보고 싶다.

🦋 아직 갈길이 멀다

결과적으로는 나에게는 멋진 블로그가 만들어져서 너무 좋았다. 하지만 아직 갈길이 멀다. 이제는 내가 글을 써서 블로그의 영양분을 채워줄 차례이다. 진정한 기술 블로그로 거듭날 수 있도록 많은 기록들을 써내려가야 할 것이다.

본 아티클은 Tkdodo의 Thinking in React Query 블로그 글을 번역한 내용입니다.

이 글은 여기서 더 멋지게 보실 수 있습니다 😆

🗣️ 오늘의 아티클은 다른 형태로 진행 됩니다. 얼마전 비엔나에서의 밋업과 예전에 React Summit에서 진행했던 발표의 슬라이드와 대본으로 이루어져 있습니다. 슬라이드를 좌우로 스와이프 하거나 양끝에 있는 화살표 버튼을 클릭하여 슬라이드를 이동할 수 있습니다. 그럼 즐겁게 읽어주세요!

Intro

안녕하세요 여러분 👋, 오늘 이 자리에 있게 되어 영광입니다. 오늘 이야기 하고자 하는 바는…여러분의 신발끈을 바로 잡는 것에 대해서 입니다.

대부분의 사람들이 신발끈을 묶는 데에 있어서 정확한 방법과 잘못된 방법의 차이를 구분해내지 못합니다. 두 방법은 언뜻 보기에 비슷해 보여도 전자의 매듭은 꽉 묶여있지만 후자의 매듭은 걸을때 풀리기 십상입니다. 이는 여러분의 삶을 변화시킬 수 있는 작은 변화일 것 입니다.

리액트 쿼리를 사용할 때도 작은 변화가 큰 차이를 만들어낼 수 있는 몇가지 상황들이 존재하곤 합니다.

제가 2020년경에 오픈소스 커뮤니티 활동을 한창 시작했을때 이러한 상황들을 발견하곤 했습니다. 여러 플랫폼들을 통해서 질의응답을 하는 활동은 제가 오픈소스 활동을 시작하게 된 아주 훌륭한 방법이였습니다. 여러분들이 이러한 문제들을 해결해주면 사람들은 고마워하고 감사해하며, 저 역시 이전에는 마주치지 못했던 문제들을 질문으로 받아보면서 많은 것들을 배워 볼 수 있었습니다.

이러한 활동 덕에 리액트 쿼리에 대해 매우 잘 알게 되었고, 그와 동시에 여러 질문들에서 공통된 패턴들을 파악할 수 있었습니다. 질문해주신 분들 중 많은 분들이 리액트 쿼리가 무엇인지 또는 무엇을 하는지에 대해 오해하고 있었고 이러한 오해는 약간의 다른 생각들을 갖도록 했습니다.

다시 돌아와서, 오늘 제가 이야기하고자 하는 바는 리액트 쿼리를 이해하는데 있어서 더 나은 사고방식을 가질 수 있는 3가지 요소들 입니다. 신발 끈을 바로 매는 것 처럼 이번 시간을 통해 여러분들은 리액트 쿼리를 쉽지만 정확하게 이해할 수 있게 될 것입니다.

자 이제 본격적으로 “React Query적으로 사고”할 수 있는 요소들에 대해 알아봅시다

1. 리액트 쿼리는 데이터 패칭 라이브러리가 아니다.

리액트 쿼리가 리액트의 데이터 패칭에 있어서 숨겨진 퍼즐 조각이라고 종종 묘사되는 만큼 여러분들이 들으면 놀랄만한 사실이 있는데 그것은 바로 리액트 쿼리는 데이터 패칭 라이브러리가 아니라는 점 입니다. 리액트 쿼리는 여러분들에게 데이터 패칭 기능을 제공해 주지 않습니다. 왜 그런지는 아래 예시를 살펴보면 알 수 있습니다.

위 코드는 일반적인 useQuery 를 사용하는 예제 코드입니다. 첫번째 인자로는 리액트 쿼리가 데이터를 저장하는 데 사용하는 고유한 queryKey 를 넘겨주고 두번째 인자로는 데이터를 불러올때마다 실행되는 함수인 queryFn 을 넘겨줍니다.

우리는 이러한 훅을 컴포넌트 내부에서 이용함으로써 데이터를 렌더링하고 쿼리가 가질 수 있는 상태들을 사용할 수 있게 됩니다.

잠시 queryFn 부분을 다시 보면 axios 라는 라이브러리로 작성되어 있다라는 점을 확인할 수 있습니다. 리액트 쿼리는 데이터 패치를 어디서 어떻게 하는지 관여하지 않습니다.

리액트 쿼리가 관여하는 부분은 queryFn 의 실행 결과로 fulfilled 혹은 rejected 상태인 Promise 객체가 반환된 이후 뿐 입니다.

사실, 누군가 리액트 쿼리 메인테이너인 저에게 리액트 쿼리에 관한 이슈를 작성 했을때 API가 공개되지 않은 상태라 그 문제점을 재현할 수 없다고 하는 상황이라고 말한다면, 저는 위에 처럼 queryFn 부분을 데이터 패칭 라이브러리 없이 Promise 객체를 반환하는 함수를 이용해서 간단하게 그 문제 상황을 재현할 수 있다고 답할 것입니다. 당연하게도 axios, fetch, graphql-request와 같은 데이터 패칭 라이브러리는 Promise 객체를 반환하기에 리액트 쿼리와 잘 동작합니다.

여러분들이 리액트 쿼리가 데이터 패치에는 관여하지 않는 것을 알게 되었다면, 바라건대 리액트 쿼리의 질문들 중 데이터 패치와 관련된 내용들은 없어져야 할 것이 분명합니다. 예를 들어, 아래와 같은 데이터 패치와 관련된 질문들은 모두 동일한 정답을 가질 것 입니다.

🤔 : 리액트 쿼리에서 baseURL을 어떻게 정의하나요?

🤔 : 리액트 쿼리에서 response header들은 어떻게 접근하나요?

🤔 : 리액트 쿼리에서 graphQL 요청은 어떻게 생성할 수 있나요?

🗣️ : 리액트 쿼리는 그러한 것들에 관여하지 않습니다. 그저 queryFn의 자리에는 Promise나 반환해주세요.

그렇다면 이제 새로운 의문점을 갖게 될 수 있습니다.

🤔 : 데이터 패칭 라이브러리가 아니라면 리액트 쿼리는 도대체 무엇인가요?

이 질문에 대한 저의 답변은 항상 다음과 같았습니다.

🗣️ : 비동기 상태 관리자(Async State Manager) 입니다.

자 여기서 비동기 상태 라는 것이 무엇을 의미하는지 이해하는게 중요합니다.

리액트 쿼리의 창시자인 Tanner Linsley는 2020년 5월 경에 It’s Time to break up with your “Global State” 라는 내용으로 발표를 진행했었습니다. 위의 발표 내용이 이번 아티클과 매우 밀접하게 관련되어 있으니 꼭 한 번 시청하는 것을 권장드립니다.

위 발표 내용의 핵심은 우리가 오랜 기간 동안 “상태” 라는 것을 어디에 보관 해둘지에 대해서만 고민하는 것에 몰두했다는 것 입니다. 예를 들어, 우리는 하나의 상태가 한 컴포넌트 내부에서만 필요하다면 위의 그림처럼 컴포넌트 내부에서 지역 상태를 정의하여 사용할 것입니다.

상위 계층에서도 사용해야 한다면, 해당 상태를 부모 컴포넌트로 끌어올리고 필요한 곳에 props로 내려주는 형태로 사용할 것 입니다.

부모보다도 더 높은 계층이나 더 넓은 영역에서 상태를 사용해야 한다면 어떻게 할 수 있을까요? redux나 zustand와 같은 “전역 상태 관리자”에게 상태값을 위임함으로써 리액트 컴포넌트 외부에서 상태를 관리하되 컴포넌트 모든 컴포넌트들에서 해당 상태를 사용할 수 있도록 할 수 있을 것입니다.

그리고 우리는 한동안 이러한 방식을 모든 종류의 상태에 대해서 적용했습니다. 버튼을 클릭하면 테마가 전환되는데 필요한 상태부터 네트워크 상에서 불러오는 이슈의 목록이나 프로필 데이터와 같은 종류의 상태에 이르기까지 말이죠. 우린 그들을 모두 동일한 전역 상태로 취급했습니다.

이러한 사고방식은 우리가 상태를 다르게 분류하면서 부터 변화하게 됩니다. 상태가 어디에서 사용되는지가 아니라 어떠한 종류의 상태인지를 따지면서 부터 말이죠.

다크모드 토글 버튼을 클릭할때 사용되는 상태처럼 우리가 완전히 제어권을 가지고 동기적으로 동작하는 상태는 이슈들의 리스트 데이터와 같이 외부에서 통제되고 비동기적으로 동작하는 상태와는 완전히 다른 특성들을 가집니다.

비동기 상태 혹은 서버 상태를 사용할때 클라이언트는 데이터를 불러올 당시의 스냅샷만을 갖고 있게 됩니다. 클라이언트가 그 상태에 대한 제어권을 갖고 있지 않다보니 이러한 상태는 언제 든지 만료될 수 있죠. 백엔드, 정확히는 데이터베이스가 이 상태를 소유하게 됩니다. 클라이언트는 그저 그 스냅샷을 화면상에서 띄울 수 있게 빌려오는 것 뿐입니다.

사용자가 브라우저 탭을 열어놓고 30분간 다른 탭을 띄워놓다가 다시 그 탭으로 되돌아가는 것을 해보면 스냅샷을 클라이언트가 빌려온다는 개념이 크게 체감될 것 입니다. 이런 상황에서 사용자가 되돌아 왔을때 페이지 내 데이터가 자동으로 갱신되어 있다면 더 멋진 경험을 제공해주지 않을까요? 이런 자동 갱신 과정이 필요한 이유는 사용자가 페이지를 떠나있는 동안 다른 이용자가 데이터를 언제든지 바꿀 수 있기 때문입니다.

그리고 이 서버 상태는 로딩과 에러 상태에 관한 정보와 같이 메타 정보들을 관리하는 작업이 필요하기에 동기적으로는 사용할 수 없는 상태값 입니다.

그래서 데이터를 자동으로 최신화 하는 작업을 비롯해 비동기적인 라이프사이클(에러, 로딩)을 관리하는 작업들은 기존의 다목적 상태 관리자들에게 바랄 수 없는 것들 이였습니다. 그러나 이제 여러분에게는 이런 요소들을 잘 수행해주는 도구들이 갖추어졌으니 비동기 상태들을 더 잘 사용할 수 있게 되었습니다. 그저 더 알맞은 일들을 할 수 있게 적합한 도구를 사용하기만 하면 됩니다.

2. 상태를 효율적으로 관리하기(feat. staleTime)

두번째는 상태 관리자가 무엇인지 그리고 왜 리액트 쿼리가 상태 관리자 중 하나인지를 이해하는 것입니다.

일반적으로 상태 관리자들은 앱 내에서 상태를 효율적으로 이용하게 해줍니다. 여기서 중요한 효율적 이란 용어를 다음와 같이 정의하고 싶습니다.

효율적인 업데이트 = 업데이트를 하되 너무 많이 하지 않도록 하기

너무 많은 업데이트가 문제가 되지 않지 않았다면, 우리 모두 React Context를 통해 상태 관리 하는 방식을 택했을 겁니다. 그러나 이는 문제사항으로 여겨지고 있고 대다수의 상태 관리 라이브러리들은 여러가지 방법을 통해 불필요하게 많은 업데이트가 일어나는 문제들을 해결하려고 하고 있죠.

두 개의 유명한 상태 관리 라이브러리인 Redux와 zustand 는 selector 라는 api를 제공 하고 있습니다. 이들은 컴포넌트가 관심있어 하는 상태의 일부만 구독할 수 있게 합니다. store 내 구독하고 있지 않는 다른 부분이 업데이트 된다 하더라도 컴포넌트들은 신경쓰지 않도록 말이죠. 그리고 이 두 라이브러리은 모두 전역으로 이용가능하게 만들어 놓았기에 hook 을 호출하여 앱 내부 어디에서나 원하는 상태값에 접근할 수 있습니다.

리액트 쿼리도 이 원칙에서 크게 벗어나지 않습니다. 다만, 클라이언트가 구독하고 있는 대상이 기존의 라이브러리 와는 다르게 queryKey 라는 고유 키를 통해 구분 된다는 약간의 차이만 있을 뿐입니다.

클라이언트가 useIssue 이라는 커스텀 훅을 호출하고 있는 상황에서, QueryCache 내의 issues 라는 slice에 변화가 생기면 해당 데이터는 업데이트가 이루어지게 됩니다.

앞의 기능들만으로 충분하지 않다면 리액트 쿼리에도 있는 selector 를 이용해볼 수 있습니다. 이를 통해 저장된 결과들 중 일부만을 도출하여 컴포넌트가 관심있는 것만 가져가는 정제화된 상태 구독도 가능합니다. 예를 들어, 위의 예시의 코드를 사용할때 클라이언트 내 컴포넌트가 이슈를 “opened” 상태에서 “closed” 상태로 바꾼다 하더라도 issue의 길이는 변하지 않기에 useIssueCount 훅을 이용해 구독중인 컴포넌트에는 어떠한 리렌더링도 발생하지 않습니다.

그리고 다른 상태 관리자들과 마찬가지로 클라이언트는 사용하고자 하는 모든 영역에서 useQuery 를 호출함으로써 필요한 상태 데이터에 접근할 수 있게 됩니다.

위 사진에서 보이는 코드들은 지양해야될 패턴들입니다. useEffect 를 이용하거나 onSuccess 라는 콜백을 이용해 별도의 state 에 데이터를 저장해 두는 작업들 말입니다.

이러한 형태의 상태 동기화 작업은 단일 진실 공급원(Single Source Of Truth) 원칙을 위반하며 불필요한 작업이라고 여겨집니다. 리액트 쿼리가 이미 상태 관리자이기에 별도의 상태로 관리할 필요가 없기 때문이죠.

여기까지 보셨다면 여러분들은 이런 생각이 드실지 모르겠습니다. 예를 들어, 위의 그림처럼 useIssues 훅을 서로 다른 3개의 컴포넌트에서 사용한다고 합시다. 그런데 여기서 Dialog와 같이 일부 컴포넌트가 조건부로 렌더링된다고 한다면, 동일한 API endpoint에 대한 데이터가 여러번 중복해서 불러와지는 것을 보게될 것입니다.

첫번째 사진의 상황을 보고는 “2초 전에 이미 불러왔는데 왜 또 다시 불러오는 걸까??” 라고 생각할 수 있습니다. 이제 여러분은 백엔드로의 중복요청을 막아야 한다는 이유로 공식문서에 들어가 refetch와 관련된 모든 옵션을 비활성화하게 될 수도 있습니다. 그러고는 “상태값을 리덕스에 뒀어야했나..”라고 후회하게 될지도 모르죠.

이러한 일이 벌어지는 것에는 다 이유가 있으니 잠시만 저의 이야기를 들어주시길 바랍니다. 왜 리액트 쿼리는 이렇게 많은 요청을 보내는 것일까요?

이는 비동기 상태에서 필요한 요구사항들을 수행해야 되기 때문입니다. 비동기 상태는 언제든지 만료될 수 있기에 특정 시점에서 업데이트하는 작업이 필요합니다. 리액트 쿼리에서는 이러한 업데이트 작업을 다음의 특정 상황들에서 진행 합니다.

• window에 포커스가 있을때
• 컴포넌트가 마운트 되었을때
• 네트워크 연결이 다시 이루어졌을때
• QueryKey가 바뀔때

이러한 이벤트가 일어날때마다 리액트 쿼리는 자동으로 쿼리를 다시 패치할 것 입니다. 그러나 이게 전부가 아닙니다. 더 중요한 것은 리액트 쿼리가 이러한 업데이트 작업을 모든 Querie들에 대해서 하지는 않는 다는 것 입니다. 오로지 stale 하다고 여겨지는 Query에 대해서만 위 작업을 진행합니다. 여기서 stale 에 대한 내용은 이번 아티클에서 두번째로 중요한 내용이 될 것입니다. 바로 staleTime 여러분의 가장 친구라는 것 입니다.

리액트 쿼리는 또한 데이터 동기화 도구이기는 하나, 무자비하게 모든 쿼리의 데이터를 백그라운드 단에서 다시 불러오지는 않습니다. 다시 패치할지 말지를 결정하는 기준은 staleTime 에 의해 정해지며 여기서 staleTime은 “데이터가 stale 해지는 데 까지 걸리는 시간”을 의미합니다.

stale 의 반댓말은 fresh 인데, 이는 fresh 하다고 여겨지는 데이터는 다시 불러오지 않고 미리 캐시된 데이터를 클라이언트에게 전달됨을 의미합니다. fresh 한 상태가 아니라면 클라이언트는 캐시된 데이터를 얻음과 동시에 다시 데이터를 불러 오는 과정이 진행됩니다.

이 말인 즉슨, 오로지 stale 한 쿼리들만이 자동으로 업데이트 되는 것을 의미합니다. 다만, staleTime은 기본적으로 0으로 설정됩니다. 당연히 여기서 0이라는 숫자는 0 밀리초를 의미하며, 리액트 쿼리는 별다른 설정이 없다면 모든 쿼리를 즉시 stale 한 상태라고 여깁니다. 이러한 방식은 엄청나게 반복된 데이터 패칭을 야기할 수 있지만, 리액트 쿼리에서는 네트워크 상에서의 요청을 최소화 하지 않고 데이터를 최신 상태로 유지하는 쪽을 선택했습니다.

그래서 이제 staleTime 값은 여러분에게 주어진 리소스와 요구사항에 따라 알맞게 정의하는게 필요합니다. 또한 staleTime 값에는 정해진 정답이 있는게 아닙니다. 여러분이 생각하기에 서버가 재시작 될때에만 변화하는 게 필요하다고 생각된다면 staleTime을 Infinity 로 설정하는 것이 가장 적합한 선택이 될 것입니다. 반면에, 협력툴과 같이 많은 사용자들이 동시에 데이터를 업데이트한다면, staleTime을 0으로 두는 것이 더 나은 선택이 될 것입니다.

따라서 리액트 쿼리을 활용하는데 있어서 매우 중요한 부분은 staleTime 을 알맞게 조절하는 것입니다. 다시 한번 말하지만 이는 정답이 정해져있지 않으며 제가 가장 선호하는 바는 위의 사진과 같이 전역적으로 기본값을 설정해두고 필요할때마다 덮어쓰는 방식입니다.

자, 앞서서 한번 봤던 비동기 상태에 대한 요구사항들을 다시 살펴보도록 합시다. 우리는 이제 리액트 쿼리에서는 데이터가 stale한 상태가 되거나 위에서 언급한 이벤트들 중 하나가 발생하면 캐시를 최신화 시킨다는 사실을 알고 있습니다. 그 이벤트 중 제가 가장 강조하고 싶은 것 중 하나가 바로 QueryKey가 변화하는 이벤트 입니다.

그럼 QueryKey가 변화하는 이벤트는 언제 가장 많이 발생할까요? 이 질문에 대한 대답은 다음 주제로 이어집니다.

3. 파라미터들을 의존성으로 받아들여라

세번째 주제는 Query의 파라미터들을 의존성으로서 봐야 한다는 것입니다. 저는 이 주제를 공식문서에도 강조하고 별도의 블로그 포스트로 올렸음에도 다시 한번 강조하고 싶습니다.

여러분이 위와 같이 filters 라는 파라미터를 정의해서 queryFn 함수에서 데이터 패치 요청시에 사용하고 있다면 여러분은 queryKey 에도 filters 라는 변수를 추가해 주어야 합니다.

이러한 규칙은 리액트 쿼리가 잘 작동해주는 것을 보장해줍니다. Query 내 엔트리들이 그들의 입력값(예시에서는 filters)에 따라 별도로 캐싱되도록 합니다. 그래서 다른 필터값을 가지게 되면 캐시 상에서 다른 키 값으로 저장되도록 하여 Race Condition 문제를 피하도록 해줍니다.

또한 이러한 방식은 filters 값이 변화했을때 자동으로 데이터를 다시 불러오도록 해주는데 이는 이전 cache 엔트리에서 다른 엔트리로 이동하는 작업으로 여겨지기 때문입니다. 게다가 이는 디버깅 하기 까다로운 stale closure 문제를 예방하곤 합니다.

또한 이러한 규칙을 잘 준수할 수 있도록 도와주는 eslint plugin이 있습니다. 여러분이 만약 queryFn 내부에서 파라미터를 사용하고 있다면 queryKey 에서 의존성으로서 명시하도록 도와주며 이는 자동으로 fixable하기에 해당 플러그인을 사용되는 것이 매우 권장됩니다.

여러분들이 queryKey 를 useEffect 에서 사용되는 의존성 배열과 비슷하다고 생각할 수는 있으나 의존성 배열처럼 참조적 안정성(referential stability)에 주의해야할 필요는 없습니다. 위의 예시처럼 참조적 안정성을 지키려고 queryKey나 queryFn 에 메모이제이션 훅을 사용하는 행위까지는 할 필요 없다는 의미입니다.

이제 마지막으로 새로운 문제에 대해서 소개해보자 합니다. 우리는 useQuery 라는 훅을 원하는 컴포넌트 계층에서 자유롭게 쓰고 있는데 만약 특정 컴포넌트에서만 존재하는 값이 Query의 의존성이 되어버린다면 어떻게 해야할까요? 예를 들어 useIssues 라는 훅이 filters 에 의존적인 상황에서 filters 에 대한 접근 권한이 특정 컴포넌트에게만 있는 제한적인 상황이라면 어떻게 해야할까요?

정답은 다시 말하지만, 리액트 쿼리가 이에 대해 관여하지 않는다 입니다. 이러한 문제는 순전히 클라이언트 상태 관리 문제일 것입니다. 왜냐하면 위 예시에서의 filter 값은 클라이언트 상태이기 때문이죠. 그리고 그것을 어떻게 관리할지는 여러분에게 달려있고요. 지역상태나 전역 상태나 여러분에게 가장 적합한 것을 사용하면 됩니다. filters 라는 값을 url에 저장해두는 것 역시 좋은 방법이 될 것입니다.

예를 들어, zustand 와 같은 상태 관리자에게 filters 값을 저장했을때 어떠한 양상을 보이는지 확인해봅시다. 이전 예시와 다른 점은 그저 filters 가 커스텀 훅의 파라미터로 들어오는 대신에 스토어로부터 직접 얻어온다는 점 입니다. 이는 커스텀 훅을 작성할때 훅들을 합성을 하는 것의 강력함을 보여줍니다.

그리고 우리는 여기서 useQuery 를 통해 관리되는 서버 상태와 useStore 에 의해서 관리되는 클라이언트 상태의 극명한 차이를 느낄 수 있습니다. 우리가 스토어에 있는 filters 의 값이 변함에 따라 Query는 자동으로 실행되어 캐시로부터 이용 가능한 가장 최신의 데이터를 가져오게 되는 것 입니다.

이러한 패턴은 리액트 쿼리를 순수한 비동기 상태 관리자로서 사용하는 것을 가능하게 해줍니다.

이번에 다룬 내용들을 요약해보자면 다음과 같습니다.

1. 리액트 쿼리는 데이터 패칭 라이브러리가 아니라 비동기 상태 관리 라이브러리 입니다.

2. staleTime 은 여러분의 가장 친한 친구입니다 - 그러나 필요에따라 알맞은 수정이 필요합니다.

3. 파라미터를 의존성으로 생각해야하며, 이전에 소개한 lint rule을 꼭 사용해야합니다.

앞서 언급한 이 세가지 원칙들을 따르도록 우리의 사고방식을 바꾸게 된다면 신발끈을 바로 매는 것이 우리의 삶의 질을 바꿔 놓은 것처럼 리액트 쿼리를 다루는데에 있어서 훨씬 더 나은 경험을 할 수 있게 될 것입니다.

오늘의 이야기는 여기까지 입니다. 트위터 팔로우와 블로그 구독을 부탁드립니다. 리액트 쿼리 v5 출시까지도 얼마 남지 않았으니 트위터와 블로그를 통해 이에 대한 최신 정보를 받아보실 수 있을 겁니다. 감사합니다!

Concurrent Feature는 리액트 18버전에서 release 된 기능이다. 여기서 Concurrent는 동시성을 의미하며 보통 동시성이라고 하면 운영체제에서 흔히 사용되는 용어로 컴퓨터가 동시에 여러가지 일들을 처리하는 것처럼 보이도록 하기 위해 할 일들을 작게 쪼개고 이를 번갈아가며 실행하는 방식을 의미한다.

동시성이 없었다면 위과 같이 커피를 만드는 것을 기다렸다가 잼바른 빵을 만드는 일을 해야 한다. 이렇게 되면 커피는 식어버릴 것이다.

이를 위와 같이 두 개의 큰 일들을 세부적인 태스크들로 잘게 쪼갠 뒤 이들을 번갈아 진행한다면 두 가지 결과를 거의 동시에 끝 마치며 맛있는 아침식사를 할 수 있다.

이러한 동시성의 개념은 리액트 상에서 복잡한 UI 상호작용을 처리하는데 있어서 필요해졌다. 본격적으로 리액트의 동시성 프로그래밍에 대해 알아보기전에 리액트에서 사용되는 데이터 패칭 전략들을 알아보자

Fetch-on-render

function App(){
    return (
        <>
            <ArticlePage/>
            ...
        </>
    );
}

function ArticlePage() {
    const { articles, isLoading } = useArticlesQuery();

    // articles가 로딩되지 않는다면 다른 UI를 보여준다.
    if(isLoading){
        return (
                <Spinner />
        );
    }

    // articles 로딩이 완료되면 해당되는 UI를 보여준다.
    // isLoading이 false가 되기 전까지 TrendArticles는 실행조차 되지 못한다.
    return (
        <>
            {articles.map((article, idx) => <ArticleCard key={idx} article={article}/>}
            <TrendArticles />
        </>
    );
}

특징

• 데이터 패칭이 이뤄지고 나서야 관련된 컴포넌트를 렌더링 하는 방식이다.

문제점

• ** Waterfall 현상 발생** : TrendArticles 컴포넌트는 articles 데이터가 로딩이 완료되어야 렌더링 되기 시작한다. 만약 TrendArticles 내부에 비동기 데이터를 호출하는 작업이 있다면 이는 articles 데이터가 모두 불러와져야 진행이 가능하다. 이러한 fetch-on-render 방식이 계층 별로 반복되면 데이터 패칭도 순차적으로 일어나면서 렌더링 성능에 나쁜 영향을 끼치게 된다.

• 나쁜 가독성 : 하나의 컴포넌트 코드 내에서 로딩 상태에 대한 로직이 포함되어야 한다는 것이다. 이 때문에 ArtciePage 에서 핵심로직에 집중하기 어려워 진다.

Fetch-then-render

function ArticlePage({ ... }) {
  const [allArticles, setAllArticles] = useState([]);
  const [trendArticles, setTrendArticles] = useState([]);

  useEffect(() => {
    // 비동기 작업을 동시에 병렬적으로 실행
    Promise.all([fetchAllArticles(), fetchTrendArticles()]).then(([allArticles, trendArticles]) => {
      setAllArticles(allArticles);
      setTrendArticles(trendArticles);
    });
  }, []);

  return (
    <>
      <AllArticleList articles={allArticles} />
      <TrendArticleList articles={trendArticles} />
    </>
  );
}

특징

• Fetch-on-render 방식의 Waterfall 현상을 해결할 수 있도록 비동기 데이터 호출을 Promise.all 로 묶어 병렬적으로 처리하는 방법이다.
  • 위 예시에서는 기존의 fetch-on-render 방식을 변형해 비동기 데이터들을 호출하는 부분을 최상단에서 몰아 처리할 수 있도록 하고 있다.

문제점

• 불필요한 관심사들의 결합 : 병렬적으로 처리하는 과정에서 불가피하게 서로 다른 비동기 데이터가 Promise.all 로 묶이게 된다. 이로 인해 서로 다른 데이터가 하나의 코드에서 호출되게 되며 강한 결합도를 가진다.

  • 가령 TrendArticles 를 불러오는 부분이 실패하면 AllArticles 부분도 렌더링 되지 못한다.

• 다른 비동기 데이터가 완료 되어야 렌더링이 가능 : 가령 TrendArticles 은 받아올 데이터가 극소수여서 20ms만에 완료되는 한편, AllArticles 는 받아올 데이터가 너무 많아 100ms 가 소요된다고 하자. 이렇게되면 TrendArticles 의 데이터는 빠르게 로드되었음에도 AllArticles 때문에 렌더링이 역시 지연 되어 버린다.

Render-as-you-fetch(with Suspense)

function App(){
    return (
    <>
        <Suspense fallback={<Spinner/>}>
            <AllArticlePage/>
        </Suspense>
        <Suspense fallback={<Spinner/>}>
            <TrendArticlesPage/>
        </Suspense>
        ...
    </>;
}

function AllArticlesPage() {
    const { articles } = useArticlesQuery();

    return (
        <>
            {articles.map((article, idx) => <ArticleCard key={idx} article={article}/>}
            ...
        </>
    );
}

function TrendArticlesPage() {
    const { articles } = useTrendArticlesQuery();

    return (
        <>
            {articles.map((article, idx) => <ArticleCard key={idx} article={article}/>}
            ...
        </>
    );
}

특징

• 렌더링 작업과 비동기 데이터 호출 과정이 동시에 이루어진다.
  • 비동기 데이터를 호출하는 과정, fallback UI를 보여주는 과정, 완성된 UI를 보여주는 과정 등 기존의 렌더링 과정들이 여러 작은 태스크들로 쪼개진 뒤 번갈아가며 진행된다.
• 비동기 데이터 호출을 통해 로딩이 발생하면 Suspense 가 이를 포착하여 UI는 fallback 으로 보여주고 로딩이 완료되면 완성된 UI를 보여준다
  • 이를 통해 컴포넌트 내부에선 로딩 상태에 대한 분기 처리가 필요없어져 코드의 가독성도 높아진다.
  • 비동기 데이터에 대한 분기처리로 인해 waterfall 현상 역시 사라진다.

🧪 Suspense 동작방식 알아보기

리액트 공식문서 예시에서는 Promise를 사용하는데 있어서 아래와 같은 wrapPromise 함수를 예시로 제공해주고 있다.

function wrapPromise(promise) {
  let status = "pending";
  let result;
  let suspender = promise.then(
    (r) => {
      status = "success";
      result = r;
    },
    (e) => {
      status = "error";
      result = e;
    }
  );

  return {
    read() {
      if (status === "pending") {
        throw suspender;
      } else if (status === "error") {
        throw result;
      } else if (status === "success") {
        return result;
      }
    },
  };
}

export function fetchProfileData() {
  let userPromise = fetchUser();
  return {
    user: wrapPromise(userPromise),
  };
}

function fetchUser() {
  return new Promise((resolve) => {
    setTimeout(() => {
      resolve({
        name: "Ringo Starr",
      });
    }, 2000);
  });
}

function ProfileDetails({ resource }) {
  const user = resource.user.read();
  return <h1>{user.name}</h1>;
}

function ProfilePage({ resource }) {
  return (
    <>
      <Suspense fallback={<h2>Loading details...</h2>}>
        <ProfileDetails resource={resource} />
      </Suspense>
    </>
  );
}

function App() {
  const [tab, setTab] = useState("home");
  const [resource, setResource] = useState(fetchProfileData());

  return <ProfilePage resource={resource} />
}

위 코드의 실행과정을 살펴보면 아래와 같다.

• fetchProfileData 실행 → wrapPromise 는 실행 시 pending 중인 Promise를 반환하는 read 함수를 반환한다.
• App 컴포넌트 렌더링 → ProfilePage → ProfileDetails 이 실행되면서 read함수가 실행된다
• 이로 인해 read 함수는 pending 중인 Promise를 반환하고 이를 ProfileDetails 상단의 Suspense 에 의해 캐치되어 fallback UI를 띄운다.
• Promise의 비동기 처리가 완료되어 status가 success 로 전환되면 read 함수가 재실행되며 결과값을 반환한다.
• 이후에는 ProfileDetails 컴포넌트가 다시 실행되며 완성된 UI를 보여준다.

여기서 read 함수가 다시 실행되는 것이나, ProfileDetails 컴포넌트가 진짜 다시 실행되는지 의문이 든다면 아래의 샌드박스를 확인해보면 좋을 것 같다.

!codesandbox[strange-kilby-2cs057]

추가적으로 확인할 수 있는 한가지 흥미로운 점은 Suspense 가 연달아 존재하더라도 블락킹 되는 것이 아니라 병렬적으로 실행된다는 점이다.

function ProfilePage({ resource, showProfile }) {
  return (
    <>
      <Suspense fallback={<h2>Loading details...</h2>}>
        <ProfileDetails resource={resource} />
      </Suspense>
      <button onClick={showProfile}>Refresh</button>
      <Suspense fallback={<h2>Loading posts...</h2>}>
        <ProfileTimeline resource={resource} />
      </Suspense>
    </>
  );
}

위 코드에서 보이는 ProfileDetails 와 ProfileTimeline 은 서로 다른 비동기 처리를 함에도 조건문을 통해 분기 처리 했을때 아래 내용들이 블로킹 되는 것과 다르게 서로 동시에 실행된다. 이로 인해 waterfall 현상이 발생하지도 않게되며 여기서 리액트가 도입한 Concurrent 모드의 진가가 확인된다.

💣 Suspense의 문제점

Suspense 로 로딩상태를 분리함으로 인해서 코드는 훨씬 간결하게 처리할 수는 있었으나 만약 응답속도가 매우 빠르게 이루어지는 비동기 요청에 대해서는 Spinner 로 인해서 오히려 깜빡임이 발생할 수 있다.

위 사진에서 보이는 것 처럼 비동기 호출이 이뤄질때 어느정도 로딩이 발생한다면 Spinner 를 보여주는 UI는 자연스러운 과정으로 이해해볼 수 있다.

하지만 두번째 사진처럼 비동기 처리가 매우 빠르게 처리된다면 Spinner를 띄우는 과정 때문에 오히려 깜빡임을 발생시킨다. 이는 사용자 경험상 좋지 않은 UI가 되어버린다.

이를 해결해줄 수 있는 방법으로 리액트 18에서는 useTransition 이라는 API를 제공한다.

const [isPending, startTransition] = useTransition();

const onClick = id => {
  startTransition(() => {
    setId(id);
  });
};

return(
    <Suspense fallback={<Spinner />}>
      <TvShowDetails id={id} />
    </Suspense>
);

const Details = ({ id }) => {
  const tvShowResource = getTvDataResource(id).read();
  return (
    <div className="flex">
      ...
    </div>
  );
};

export const TvShowDetails = ({ id }) => {
  return (
    <div className="tvshow-details">
      <Suspense fallback={<Spinner />}>
        <Details id={id} />
      </Suspense>
    </div>
  );
};

useTransition 으로 부터 나온 startTransition 이라는 함수에 상태 업데이트 로직을 부여하면 해당 상태 업데이트로 인해 새롭게 발생하는 비동기 처리가 끝날때까지 화면 렌더링 변화를 지연시킨다. 정확히는 원래의 UI를 보여주다가 업데이트된 UI를 보여주는 형태다. 이를 적용해보면 아래처럼 깜빡임 없이 개선해볼 수 있다.

🪡 Transition의 동작과 그 차이

💡 timeout으로 인해 Receded 상태로 넘어가는 것은 현재 삭제되었다. 즉, 얼마나 오래걸리든 비동기 상태가 완료될때까지는 원래의 UI를 계속 유지하게 된다.

그렇다면 Transition 은 어떠한 이유로 기존의 방식과 다른 동작 결과를 낳는 것일까? setState로 인해 state 업데이트가 일어나면 다음의 3가지 단계로 나뉘어 화면 렌더링에 반영된다.

Transition 단계

• Receded : 영어단어 자체로는 물러난다는 의미를 가진다. Transition을 사용하지 않는 경우 발생하는 단계이며, ProfileDetails 내부에서 비동기 작업이 일어나면 Suspense 에 의해서 둘러 쌓인 상위 계층의 Fallback 으로 물러남을 의미한다.

• Pending : Transition 을 사용하는 경우 발생하는 단계이며, Suspense 내부에서 비동기 작업이 일어나면 UI 업데이틀르 지연시키고 원래 보여주던 UI를 계속 유지 한다.

Loading 단계

• Loading 은 현재 컴포넌트(ProfilePage)의 자식 요소에서 발생하는 비동기를 처리하는 과정을 처리중인 단계이다. 여기서는 ProfileTimeline 을 띄울때가 해당되며 Loading posts…가 UI 상에서 나오게 된다.

Done 단계

• 비동기 처리가 완료됨에 따라 완성된 UI를 보여준다

상태변화에 따른 UI 변화 단계들을 transition을 쓰는 경우와 쓰지 않는 경우로 나누어 정리해보면 아래와 같이 표현해볼 수 있다.

즉,Transition 을 도입하면 Receded 상태가 아닌Pending 상태로 전환되면서 비동기가 처리 되는 동안에는 이전의 UI를 유지하도록 하였고, 이는 기존의 업데이트 시작 -> 로딩 -> 업데이트 완료가 너무 빠르게 이뤄지면서 발생한 깜빡임을 해소할 수 있게 만들어준 것이다.

🧶 Recoil과 Transition

아쉽게도 transition 은 아직 리액트 18에서도 개발중인 기능 중 하나이기에 써드파티 라이브러리에서 공식적으로 지원되고 있지는 않다. 다만, Recoil 의 경우 아직 불안전한 형태이지만 transition 이 적용되는 상태 API를 제공하고 있다.

// TrendSelect.tsx

import { trendAtom } from '@/recoils/trendAtom';
import { useRecoilState_TRANSITION_SUPPORT_UNSTABLE } from 'recoil';

const TrendSelect = () => {
  const [selectedTrend, setSelectedTrend] = useRecoilState_TRANSITION_SUPPORT_UNSTABLE(trendAtom);

  const handleClickTrend = (word: Trend) => () => {
    startTransition(() => {
      setSelectedTrend(word);
    });
  };

    return (...)    
}

// TrendArticlesContent.tsx

import { useRecoilValue_TRANSITION_SUPPORT_UNSTABLE } from 'recoil';

import { trendAtom } from '@/recoils/trendAtom';

const TrendArticlesContent = ({ isMobile }: Props) => {
  const trendType = useRecoilValue_TRANSITION_SUPPORT_UNSTABLE(trendAtom);
  const { data: trends } = useTrendingArticlesQuery({ type: trendType });

  return (
    <div>
      {trends?.slice(0, isMobile ? 1 : 3).map(({ id, title, author, timestamp }, idx) => (
        <TrendArticleItem
          key={idx}
          href={`${process.env.NEXT_PUBLIC_API_URL as string}/articles/${id}`}
          title={title}
          author={author}
          timestamp={timestamp}
        />
      ))}
    </div>
  );
};

// App.tsx

<Suspense
    fallback={
          <LoadingWrapper>
            <Loading type="spinner" />
          </LoadingWrapper>
    }
    >
        <TrendArticlesContent isMobile={isMobile} />
</Suspense>

위에서 볼 수 있듯이 불안정 버전이긴 하나 transtition 과 호환되는 recoil 전역 상태를 정의하여 사용 가능하다.

⛳️ 출처

Concurrent UI Patterns (Experimental) – React

What is React Concurrent Mode?

React 18 둘러보기 | nana.log

React v18.0 – React

Conceptual Model of React Suspense

사내 프로젝트에서 환경 설정 페이지의 추가적인 기능들을 구현하는 부분을 맡게되었다. 서버 상태를 관리하고 이용하는데 있어서 React Query 를 활용하고 있었는데 대부분의 구조가 아래와 같이 명령형으로 서버 로딩상태에 대해 분기 처리되고 있었다.

const SettingPage = () => {
  const { data, isLoading } = useSettingQuery(); 

  if(isLoading){
    return null;
  }

  return (
       <SettingPageForm>
      {...}
    </SettingPageForm>
  )
}

로딩 중일때는 어떠한 컴포넌트도 보여주고 있지 않다가 로딩이 완료되면 띄우고자 하는 컴포넌트를 띄우는 방식이다. 이러한 방식은 컴포넌트가 자신의 핵심 로직 외에도 로딩상태에 대한 로직을 포함하고 있어야만 했다. 이는 코드의 가독성을 떨어뜨리고 컴포넌트의 독립성을 해치는 좋지 못한 패턴으로 여겨졌다. 특히나 요구사항을 추가해야하는 나로써는 위의 로직을 그대로 사용한다면 아래와 같은 코드를 작성해야했다.

const SettingPage = () => {
  const { data: setting1, isLoading: isLoading1 } = useSettingQuery(); 
  const { data: setting2, isLoading: isLoading2 } = useSettingQuery2();
  const { data: setting3, isLoading: isLoading3 } = useSettingQuery3();

  if(isLoading1 || isLoading2 || isLoading3){
    return null;
  }

  return (
       <SettingPageForm>
      {...}
    </SettingPageForm>
  )
}

사용해야되는 쿼리가 늘어남에 따라 로딩 상태에 대한 개수도 늘어나고 이는 if 조건문을 비대하게 만들어버린다. 이를 개선하고자 비동기 상태에 대한 처리 로직을 컴포넌트 외부로 따로 뽑아 처리할 수 있는 Suspense 를 도입하기로 했다.

👏 Suspense를 통해 선언형 컴포넌트로 바꾸기

Suspense 란 컴포넌트 내에서 사용하는 비동기적 데이터를 불러오는 동안 인자로 지정한 fallback 을 대체해서 보여주었다가 비동기처리가 완료되면 컴포넌트의 UI를 보여주는 역할을 하는 녀석이다.

function wrapPromise(promise) {
  let status = 'pending'
  let response

  const suspender = promise.then(
    (res) => {
      status = 'success'
      response = res
    },
    (err) => {
      status = 'error'
      response = err
    },
  )

  const read = () => {
    switch (status) {
      case 'pending':
        throw suspender
      case 'error':
        throw response
      default:
        return response
    }
  }

  return { read }
}

export default wrapPromise


/*****************************************************/

function fetchData(url) {
  const promise = fetch(url)
    .then((res) => res.json())
    .then((res) => res.data)

  return wrapPromise(promise)
}


/*****************************************************/

import { Suspense } from 'react';

const resource = fetchData('fetchURL...');

const UserPage = () => {
  const userData = resource.read()

  return (
    <div>
      <Suspense fallback={<p>Loading user details...</p>}>
        <UserProfile data={userData} />
      </Suspense>
    </div>
  )
}

export default UserWelcome

본래 Suspense 를 사용하려면 위와 같이 promise 객체를 인자로 받아 상태에 따라 반환값을 달리해주는 함수를 구현한뒤 이를 컴포넌트 내부에서 사용해야한다. 위에서 보다시피 구현체가 복잡하며 컴포넌트 위에 리소스 변수를 선언해야되는 등 사용하기가 까다롭다.

다행히도 React Query 를 비롯한 다양한 서버 상태 관리 라이브러리에서 Suspense 기능을 손쉽게 사용할 수 있도록 알맞은 API를 제공해주고 있다.

const fetcher = (url) => axios.get(url);


/*****************************************************/


const UserPage = () => {
     const { data } = useQuery(['user'], fetcher, { suspense: true });

  return (
    <div>
        <UserProfile data={userData} />
    </div>
  )
}

/*****************************************************/

<Suspense fallback={<p>loading...</p>}>
  <UserPage/>
</Suspense>

Suspense를 사용하기 위해서 리액트 쿼리에 해줘야할 일은 평소처럼 사용하던 query에 suspense 옵션을 추가해주면 된다.

사내 프로젝트에서도 Suspense 를 통해서 로딩상태는 제거하고 컴포넌트를 간결하게 선언할 수 있었다.

const SettingPage = () => {
  const { data: setting1 } = useSettingQuery(); 
  const { data: setting2 } = useSettingQuery2();
  const { data: setting3 } = useSettingQuery3();

  return (
       <SettingPageForm>
      {...}
    </SettingPageForm>
  )
}

/*****************************************************/


<Suspense fallback={<p>Loading</p>}>
  <SettingPage ... />
</Suspense>

특히나 로딩상태로 인해 조건문이 줄줄이 붙어있던 부분이 사라지면서 컴포넌트 파일안에서는 컴포넌트 핵심로직에만 집중할 수 있게 되었다.

🛝 Waterfall 발생

여기서 Waterfall 이란 순차적으로 물흐르듯 네트워크 상의 흐름이 발생하는 것을 뜻한다.

위의 사진을 보면 좀더 와닿을텐데 3개의 쿼리를 위해서 3번의 API 호출을 하는 과정에서 각각의 호출이 순차적으로 이루어진다는 것이다. 이는 컴포넌트의 코드를 읽는 과정에서 query 부분을 만날때마다 Suspense 에 의해서 API 호출로 인한 로딩이 발생하는 동안 fallback 컴포넌트로 대체되기 때문에 일어나는 현상이다.

이는 하나의 컴포넌트에 여러번의 비동기처리가 발생해야되기 때문에 발생한 것이다. 이를 해결해볼 수 있는 방법은 useQuery 대신 useQueries 훅을 사용해보는 것이다.

const SettingPage = () => {
  /*const { data: setting1 } = useSettingQuery(); 
  const { data: setting2 } = useSettingQuery2();
  const { data: setting3 } = useSettingQuery3();*/

  const results = useQueries([
    {
      queryKey: ['setting1'],
      queryFn: fetchData1,
      suspense: true,
    },
    {
      queryKey: ['setting2'],
      queryFn: fetchData2,
      suspense: true,
    },
    {
      queryKey: ['setting3'],
      queryFn: fetchData3,
      suspense: true,
    },
  ]);

  return (
       <SettingPageForm>
      {...}
    </SettingPageForm>
  )
}

/*****************************************************/


<Suspense fallback={<p>Loading</p>}>
  <SettingPage ... />
</Suspense>

useQueries 훅은 다수의 쿼리를 처리할때 useQuery를 대신해서 사용할 수 있으며 suspense 옵션을 지정해주면 여러개의 쿼리도 병렬로 처리해준다. 하지만 이는 4.5 버전부터 사용이 가능했다. 특히나 현재 사내프로젝트에서는 리액트 쿼리 v3를 사용하고 있는 터였다. 버전업하기에는 여건이 되지 않는 터라 다른 방법을 고안해야했다.

<Suspense fallback={<p>Loading</p>}>
  <SettingPage ... />
</Suspense>

/*****************************************************/

const SettingPage = () => {

  ...

  return (
       <SettingPageForm>
      <SettingSection1/>
      <SettingSection2/>
      <SettingSection3/>
    </SettingPageForm>
  )
}

const SettingSection1 = () => {
    const { data: setting1 } = useSettingQuery1(); 

      return (
          ...
    );
}

const SettingSection2 = () => {
    const { data: setting2 } = useSettingQuery2(); 

      return (
          ...
    );
}

const SettingSection3 = () => {
    const { data: setting3 } = useSettingQuery3(); 

      return (
          ...
    );
}

다행히도 작업중인 페이지 컴포넌트 내부에는 각각의 쿼리가 하나의 섹션에만 사용되고 있어서 위와 같이 섹션별로 컴포넌트를 분리하고 각 섹션에서 하나의 쿼리만을 호출하여 사용하도록 분리했다. 이를 통해 아래와 같이 병렬적으로 세개의 API가 동시에 처리되는 것을 확인할 수 있었다.

⛳️ 출처 및 참고자료

• [React] Suspense란?

• React Query와 함께 Concurrent UI Pattern을 도입하는 방법

• 혹시 무분별하게 Suspense 를 사용하고 계신가요? (react-query)

• 컴포넌트와 결합된 모달을 분리시킨다.
• 모달을 전역에서 관리하고 렌더링 시키도록 한다.
• 모달의 열림/닫힘 상태 대신 렌더링할 모달들을 상태값으로 지정한다.
• 코드 스플리팅을 적용해 모달 컴포넌트로 인한 성능 저하를 예방한다.

🧹 시작은 클린코드 영상으로부터..

유튜브에서 프론트엔드 클린코드 관련 영상을 보면서 되게 인상 깊은 코드 사례를 보게 되었다.

출처: SLASH21 - 실무에서 바로 쓰는 Frontend Clean Code

위 사례에서는 컴포넌트 내부적으로 사용할 팝업(모달)을 위해서 렌더링 여부를 담는 상태값, 팝업 내 이벤트 핸들러, 팝업 컴포넌트 관련 코드들을 작성해야했고 이들은 뿔뿔히 흩어지게 되는 경우를 보여주고 있다. 이로 인해 팝업 관련 로직은 읽기가 정말 어려워 졌다.

출처: SLASH21 - 실무에서 바로 쓰는 Frontend Clean Code

영상에서는 이러한 문제점을 해결하기 위해 팝업을 여는 것과 관련된 훅인 usePopup 을 정의한 뒤 팝업 컴포넌트를 최상단에서 렌더링 하도록 하여 관련 로직을 하나로 응집시키고 코드의 가독성을 높였다. 이 영상을 보면서 기존에 했던 프로젝트에서도 이와 유사한 방식을 적용해 볼 수 있다고 느꼈다.

👻 기존 프로젝트 내 모달의 문제점

1. 모달 로직으로 인한 코드의 가독성 저하

위의 코드는 버튼 클릭시 지원과 관련된 모달을 띄우고 모달 내 버튼 클릭시 지원하기 로직을 처리하는 코드이다. 위에서 볼 수 있듯이 모달을 띄우기 위해서 상태값 정의, 모달 이벤트 핸들러 정의, 모달 컴포넌트와 관련된 코드들을 작성해야 했으며 이는 컴포넌트 내에서 뿔뿔이 흩어져 있다. 이로 인해 지원하기 버튼 이라는 컴포넌트 내에서 핵심 로직이 지원하기 이지만 모달을 띄우는 로직들로 인해 관련 내용을 파악하기 어려워 졌다.

2. 불필요하게 많은 모달 컴포넌트 렌더링

기존 프로젝트 내에서 위와 같이 작성한 댓글이 있으면 해당 댓글을 삭제할 수 있는지 확인받도록 모달을 띄우는 로직을 정의할 필요가 있었다. 이를 위해 아래와 같은 Comment 컴포넌트를 정의하고 사용했다.

Comment 컴포넌트에서 모달 로직은 응집성이 떨어진 채로 선언되어있으며 더 큰 문제점은 ConfirmModal이라는 컴포넌트가 댓글의 개수만큼 조건부 렌더링 될 것이다. 화면 내에서 보이는 요소는 똑같은 모달 하나 뿐이며 쓰일지도 모를 모달을 위해 불필요하게 많은 모달 컴포넌트들이 렌더링 영역 어딘가를 차지하고 있다는 말이다.

이러한 문제점들이 생기는 이유는 본질적으로 모달이라는 요소가 다른 컴포넌트들과 불필요하게 결합되어 있기 때문이다. 이 모달들은 화면 내에서 어떠한 요소들 보다항상 최상단에서 렌더링 되고 있는 점에서 모달 컴포넌트 자체는 다른 컴포넌트들과 직접적으로 결합될 이유가 전혀 없다.

🪝 1차 리팩토링 - 모달을 전역으로 관리하기

모달과 컴포넌트가 결합되는 문제를 해결하기 위해 모달을 전역에서 관리하도록 바꿔줄 필요가 있다. 방법은 간단하다.

• 전역에서 모달의 열림/닫힘 상태값를 소유하고 이 값에 따라 모달 컴포넌트를 렌더링 한다.

• 모달을 띄우는 로직이 필요한 컴포넌트에서 전역단에 선언한 모달 열림/닫힘 상태값을 변경할 수 있도록 한다.

이를 위해 우선 아래와 같이 모달의 상태를 전역으로 사용하고 관리할 수 있는 커스텀 훅을 선언하자.

import { atom, useRecoilState } from 'recoil';

const modalOpenAtom = atom({
  key: 'modalOpenAtom',
  default: false,
});

const useModals = () => {
  const [modalOpen, setModalOpen] = useRecoilState(modalOpenAtom);

  const openModal = useCallback(() => {
      setModalOpen(true);
  }, [setModalOpen]);

  const closeModal = useCallback(() => {
      setModalOpen(false);
  }, [setModalOpen]);

  return {
    modalOpen,
    openModal,
    closeModal,
  };
};

export default useModals;

위에서는 기존의 프로젝트에 전역 클라이언트 상태관리를 모두 Recoil로 처리했기에 이를 사용했으나 Context로 충분히 대체할 수 있다.

useModals 훅은 여러 군데에서 사용되어지기 때문에 이 훅을 사용하는 곳에서 리렌더링이 발생하는 것을 방지하기 위해 훅 내 함수들은 useCallback을 이용해 메모이제이션 해주었다.

이러한 훅을 사용해 아래처럼 페이지 최상단에서 모달을 조건부 렌더링 시킬 수 있다.

// 최상단 컴포넌트
const App = () => {
      ...
      return (
      <>
           <Modals />
        <Component {...pageProps} />
      </>
    );
}


const Modals = () => {
     const { modalOpen, closeModal } = useModals();

      // 모달이 열려서 확인버튼을 눌렀을때 처리하는 로직
      const handleClickConfirmButton = () => {
        비즈니스_로직();
          closeModal();
    }

      return (
      <>
              <ConfirmModal 
              open={openModal} 
              onConfirmButtonClick={handleClickConfirmButton} 
              message="..." 
              onClose={closeModal} 
            />
         }    
      </>
    );

}

그리고 이를 사용하는 측에선 다음과 같이 훅을 통해 모달을 열도록 제어할 수 있다. 아래는 ApplyButton 에 적용한 예시이다.

const ApplyButton = () => {

  const { openModal } = useModals();

  return (
      <Button onClick={openModal}>
        참가하기
      </Button>
  );
};

이렇게 1차적인 리팩토링을 적용하여 컴포넌트 내의 모달 로직을 분리시켜보았다. 이렇게 Modals 라는 컴포넌트에 모달 렌더링 로직을 위임함으로써 모달이 필요한 컴포넌트에서 불필요한 코드를 포함하지 않도록 할 수 있었다.

💣 잘못된 리팩토링

이렇게 컴포넌트와 모달간의 불필요한 결합을 없애는데에는 성공했으나 다른 문제점들이 존재한다.

1. 컴포넌트와 비즈니스 로직의 분리

// 지원하기 버튼 컴포넌트

const ApplyButton = () => {
  const { openModal } = useModals();
  return (
      <Button onClick={openModal}>
        참가하기
      </Button>
  );
};

// 모달을 관리하는 상위 컴포넌트

const Modals = () => {
     const { modalOpen, closeModal } = useModals();

      // 모달이 열려서 확인버튼을 눌렀을때 처리하는 로직
      const handleClickConfirmButton = () => {
        비즈니스_로직();
          closeModal();
    }

      return (
          <>
              <ConfirmModal 
              open={openModal} 
              onConfirmButtonClick={handleClickConfirmButton} 
              message="참가 신청하시겠습니까?" 
              onClose={closeModal} 
            />
          </>
    );

}

ApplyButton 은 버튼 클릭시 모달을 띄우고 모달 내 확인 버튼을 눌렀을때 비즈니스 로직을 실행하도록 설계되어 있었다. 허나 리팩토링 이후 상황에서는ApplyButton 내에 존재해야될 비즈니스 로직이 Modals 라는 다른 컴포넌트에 존재해야 된다.

2. 취약한 확장성

현재는 참가신청 버튼에 대한 모달만을 띄우도록 변경해놓았지만 다른 컴포넌트들에서 또다른 모달을 사용해야한다면 어떻게 해야할까?

const ApplyButton = () => {
  const { openModal } = useApplyModal();
  return (
      <Button onClick={openModal}>
        참가하기
      </Button>
  );
};

const DeleteButton = () => {
  const { openModal } = useDeleteModal();
  return (
      <Button onClick={openModal}>
        삭제하기
      </Button>
  );
};

const Modals = () => {
      const { modalOpen: applyModalOpen, closeModal: closeApplyModal } = useApplyModal();
     const { modalOpen: deleteModalOpen, closeModal: closeDeleteModal } = useDeleteModal();
      ...

      // 모달이 열려서 확인버튼을 눌렀을때 처리하는 로직
      const handleClickApplyModalConfirm = () => {
        비즈니스_로직1();
          closeApplyModal();
    }

    const handleClickDeleteModalConfirm = () => {
         비즈니스_로직2(); 
        closeDeleteModal();
    }
    ...

      return (
          <>
              <ConfirmModal 
              open={applyModalOpen} 
              onConfirmButtonClick={handleClickApplyModalConfirm} 
              message="참가 신청하시겠습니까?" 
              onClose={closeApplyModal} 
            />
             <ConfirmModal 
              open={deleteModalOpen} 
              onConfirmButtonClick={handleClickDeleteModalConfirm} 
              message="삭제 하시겠습니까?" 
              onClose={closeDeleteModal} 
            />
            ...
          </>
    );

}

• 모달이 추가될때마다 해당 모달의 열림/닫힘 여부와 관련된 상태값을 생성해주어야 한다. -> 이로 인해 새로운 atom과 새로운 커스텀 훅이 매번 생성된다.

• 모달에 필요한 비즈니스 로직을 매번 추가해주어야한다. 그것도 저 만치 멀리 있는 곳에..

• 모달이 추가될때마다 관련 컴포넌트를 추가 렌더링 시켜줘야 한다.

모달과 관련된 코드는 요구사항이 늘어남에 따라 비대해지고 가독성이 떨어지게 된다. 이로 인해 추가적인 모달이 생겨야하는 추가적인 요구사항을 반영하기 점점 어려워진다.

🤔 어떻게 해결해 볼 수 있을까?

위에서 서술한 문제점에 따른 요구사항들을 요약하면 아래와 같다.

• 모달을 사용하는 컴포넌트와 비즈니스 로직간의 격리 -> 비즈니스 로직은 사용하는 컴포넌트 내에 있어야 한다.

• 모달들의 확장성이 떨어진다 -> 확장성을 고려해야한다.

이를 충족할 수 있는 방법은 논리적으로는 간단하다. 바로 모달을 오픈할 때 모달에 대한 정보를 사용하는 컴포넌트에서 동적으로 제공하는 것이다. ApplyButton 컴포넌트를 예시로 들면

const ApplyButton = () => {

  const { openModal } = useModals();

  const handleClickButton = () => {
    openModal(
      {
        1. ConfirmModal을 열어라,
          2. Modal 내 메시지는 "참가 신청하겠습니까?"로 해라,
        3. 클릭시에는 비즈니스_로직을 실행시켜라,
        4. 닫힘 버튼 클릭시에는 모달을 닫아라
      }
    );
  }



  return (
      <Button onClick={handleClickButton}>
        참가하기
      </Button>
  );
};

위와 같이 openModal 이라는 함수에 인자로 관련된 비즈니스 로직을 넘겨 확장성을 만족시킬 수 있을 것이다. 이를 좀 더 구체화해보면 아래와 같이 모달 컴포넌트 자체를 넘기는 식으로 처리할 수 있을 것이다. (아직은 실제로 동작할 수 없는 단계이다.)

const ApplyButton = () => {

  const { openModal } = useModals();

  const applyForRecruitment = () => {
       지원_비즈니스_로직(); 
  }

  const handleClickButton = () => {
    openModal(
        <ConfirmModal
          message="참가 신청하겠습니까?"
          onConfirmButtonClick={applyForRecruitment}
          onCancelButtonClick={모달 닫기}
          ...
        />
    );
  }



  return (
      <Button onClick={handleClickButton}>
        참가하기
      </Button>
  );
};

즉, 모달과 관련된 로직을 사용하는 측에서 원하는대로 정함으로써 확장성을 고려해 볼 수 있다는 것이다.

그렇다면 사용처에서 모달의 정보들을 다 정해줬으니 전역에서 모달을 띄우는 곳에선 사용처가 정해준 모달을 렌더링만 시켜주면 되지 않을까?

const useModals = () => {
  // 모달들의 목록을 보관하는 상태값
  const [modals, setModals] = useRecoilState(modalOpenAtom);

  // 인자로 모달을 받으면 이를 모달 목록에 추가하기
  const openModal = useCallback((modal) => {
    setModals(modals => [...modals, modal]);
  }, [setModalOpen]);

  ...

  return {
    modals,
    openModal,
    closeModal,
  };
};


const Modals = () => {
     const { modals } = useModals();

      return (
      <>
        // 목록에 추가된 모달들을 렌더링시키기
        {modals.map((modal) => <modal />}  
      </>
    );

}

즉, 기존 처럼 모달의 열림/닫힘 상태를 보관하는 대신 필요한 모달 컴포넌트와 그에 대한 정보들을 전역 상태값에 담아두고 이를 렌더링 하는 방식으로 변경하는 것이다. 더 이상 모달을 관리하는 쪽에서는 모달별 비즈니스 로직을 신경 쓸 필요가 없어졌으며 모달이 여러개여도 코드의 가독성이 떨어지지 않도록 구성할 수 있을 것이다.

다시, 해결방법을 정리해보면 아래와 같다.

• 사용하는 컴포넌트에서 모달에 대한 정보를 지정해준다.
• 렌더링 할 모달과 그에 대한 정보들을 상태로 보관한다.
• 모달을 관리하는 측에선 전달받은 모달을 렌더링 시킨다.

🧼 2차 리팩토링 - 모달 컴포넌트들을 상태값으로 보관하기

1. 모달 컴포넌트를 상태값으로 보관하기

우선 모달 컴포넌트들을 상태값으로 보관하도록 useModals 훅을 아래와 같이 바꿔보자.

import { atom, useRecoilState } from 'recoil';

const modalsAtom = atom({
  key: 'modalsAtom',
  default: [],
});

const useModals = () => {
  const [modals, setModals] = useRecoilState(modalsAtom);

  const openModal = useCallback((Component, props) => {
      setModals((modals) => [...modals, { Component, props: { ...props, open: true } }]);
    },
    [setModals]
  );

  const closeModal = useCallback((Component) => {
      setModals((modals) => modals.filter((modal) => modal.Component !== Component));
    },
    [setModals]
  );

  return {
    modals,
    openModal,
    closeModal,
  };
};

• 이제 modalsAtom은 상태값에 모달 컴포넌트들을 배열형태로 보관하게 된다.
• openModal 에서는 컴포넌트(함수)와 그의 props를 인자로 받아 상태값에 추가시킨다.
• closeModal 에서는 컴포넌트(함수)를 인자로 받으면 이를 필터링 시켜 기존의 상태값에서 제거하는 역할을 한다.

2. 상태값으로 보관한 모달들 렌더링하기

이제 전역에서 모달을 렌더링하는 Modals 컴포넌트를 아래와 같이 수정하자.

import ConfirmModal from '@components/common/ConfirmModal';
import ParticipantsModal from '@components/article/ParticipantModal';

// 사용할 모달 컴포넌트들을 담은 Object
export const modals = {
  confirm: ConfirmModal, 
  participants: ParticipantsModal,
};

const Modals = () => {
  const { modals } = useModals();

  return (
    <>
      {modals.map(({ Component, props }, idx) => {
        return <Component key={idx} {...props} />;
      })}
    </>
  );
};

• modals 객체 : 모달 컴포넌트들을 담고 있다. 이를 이용해 향후 사용처 컴포넌트에서 모달 컴포넌트들의 코드를 import 하지 않고도 모달의 종류를 선택할 수 있게 도와준다.

• Modals 컴포넌트 : useModals 훅을 통해 modals상태값을 받아와 이를 컴포넌트로 렌더링 시킨다.

3. 모달 종류와 로직 넘겨주기

사용처에서 모달 컴포넌트의 종류와 해당 컴포넌트의 props를 넘겨주는 부분이다. 아래는 ApplyButton 컴포넌트의 예시이다.

import { modals } from '@components/common/Modals';

const ApplyButton = (...) => {

  const { openModal, closeModal } = useModals();

  return (
    <Button
      onClick={() =>
        openModal(modals.confirm, {
          message: '참가 신청하시겠습니까?',
          onConfirmButtonClick: () => {
                지원_비즈니스_로직();
                closeModal(modals.confirm);
          },
          onCancelButtonClick: () => closeModal(modals.confirm),
        })
      }
    >
      참가하기
    </Button>
  );
};

• 이전에 정의한 modals를 import 하여 필요한 모달이 무엇인지 지정한다.
• openModal 함수의 인자로 모달 컴포넌트와 그의 props 들을 넘기는 방식이다.

이러한 방식을 통해 모달 로직들의 응집성을 높여 가독성을 높이고 추가적인 모달이 생기더라도 높은 확장성을 가져갈 수 있게 하였다.

✅ 부록1 - 타입스크립트

    <Button
      onClick={() =>
        openModal(modals.confirm, {
          message: '참가 신청하시겠습니까?',
          onConfirmButtonClick: () => {
                지원_비즈니스_로직();
                closeModal(modals.confirm);
          },
          onCancelButtonClick: () => closeModal(modals.confirm),
           hello: 'world',
          asdadasd: 'asdasdad',
        })
      }
    >
      참가하기
    </Button>

위 예시에서 ConfirmModal에 들어갈 props가 아닌 다른 props를 넣어주면 어떻게 될까? props 부분은 단순 Object로 인식 되기에 다른 이상한 값을 넣어줘도 그대로 통과된다. 이를 방지하기 위해선 아래와 같이 타입 지정을 추가적으로 해줘야한다.

// modalsAtom
import { ComponentProps, FunctionComponent } from 'react';

const modalsAtom = atom<Array<{ Component: FunctionComponent<any>; props: ComponentProps<FunctionComponent<any>> }>>({
  key: `modalsAtom/${uuid()}`,
  default: [],
}); 


// useModals 훅

import { ComponentProps, FunctionComponent, useCallback } from 'react';

const useModals = () => {
  ...

  const openModal = useCallback(
    <T extends FunctionComponent<any>>(Component: T, props: Omit<ComponentProps<T>, 'open'>) => {
      setModals((modals) => [...modals, { Component, props: { ...props, open: true } }]);
    },
    [setModals]
  );

  const closeModal = useCallback(
    <T extends FunctionComponent<any>>(Component: T) => {
      setModals((modals) => modals.filter((modal) => modal.Component !== Component));
    },
    [setModals]
  );

  ...
};

// Modals
import { ComponentProps, FunctionComponent } from 'react';

import ConfirmModal from '@components/common/ConfirmModal';
import ParticipantsModal from '@components/article/ParticipantModal';

export const modals = {
  confirm: ConfirmModal as FunctionComponent<ComponentProps<typeof ConfirmModal>>,
  participants: ParticipantsModal as FunctionComponent<ComponentProps<typeof ParticipantsModal>>,
};

• modalsAtom 에서는 컴포넌트와 props담은 객체들의 배열의 타입을 정의해주었다.

• openModal과 closeModal 에서는 제너릭을 통해 인자로 받은 컴포넌트로 부터 타입을 유추시킨다. 그래서 openModal의 경우에는 아래와 같이 받는 인자를 해당 컴포넌트의 props에 해당하는 것으로만 제한시킬 수 있다.

• modals 객체는 모달 컴포넌트들을 담고있다. 여기서는 타입 호환을 위해 FunctionComponent 를 이용해 타입 단언을 시켰다. 타입 단언을 하지 않을 경우 (props: Props) => JSX.Element로 타입이 추론되어 타입을 맞추기 불가능했기 때문에 사용했다.

다만, 여러 컴포넌트에서 호환성을 맞추기 위해 any를 불가피하게 사용하게 되었다 🥲. 최대한 unknown을 쓰고 싶었지만 도저히 호환되는 타입을 정의할 수 없었다. 타입스크립트는 너무 어렵다.

🖖 부록2 - 코드 스플리팅

모달들을 담고있는 modals 쪽 코드를 다시 살펴보자.

import { ComponentProps, FunctionComponent } from 'react';

import ConfirmModal from '@components/common/ConfirmModal';
import ParticipantsModal from '@components/article/ParticipantModal';

export const modals = {
  confirm: ConfirmModal as FunctionComponent<ComponentProps<typeof ConfirmModal>>,
  participants: ParticipantsModal as FunctionComponent<ComponentProps<typeof ParticipantsModal>>,
};

모달들을 import 해서 이들을 객체에 담은 뒤 이 객체를 export 시키고 이를 이용해 컴포넌트에서 사용하도록 하고 있다. 그런데 만약 모달의 종류들이 점점 더 많아지면 어떻게 될까?

import { ComponentProps, FunctionComponent } from 'react';

import ConfirmModal from '@components/common/ConfirmModal';
import ParticipantsModal from '@components/article/ParticipantModal';
import Modal1 from '...';
import Modal2 from '...';
import Modal3 from '...';
...

export const modals = {
  confirm: ConfirmModal as FunctionComponent<ComponentProps<typeof ConfirmModal>>,
  participants: ParticipantsModal as FunctionComponent<ComponentProps<typeof ParticipantsModal>>,
  modal1: Modal1,
  modal2: Modal2,
  modal3: Modal3,
  ...
};

모달이 늘어나더라도 모달의 개수만 많아질 뿐 코드상으로는 문제가 없으나 문제는 modals 객체를 컴포넌트 단에서 사용하기 위해서 저 수많은 모달들을 모두 import 시켜야 한다는 것이다. 이렇게 되면 모달이 늘어남에따라 번들링되는 자바스크립트가 커지면서 컴포넌트 로딩 성능에도 영향을 미칠 수 있게 되는 것이다.

import loadable from '@loadable/component';

const ConfirmModal = loadable(() => import('@components/common/ConfirmModal'), { ssr: false });
const ParticipantsModal = loadable(() => import('@components/article/ParticipantsModal'), {
  ssr: false,
});

export const modals = {
  confirm: ConfirmModal as FunctionComponent<ComponentProps<typeof ConfirmModal>>,
  participants: ParticipantsModal as FunctionComponent<ComponentProps<typeof ParticipantsModal>>,
};

이를 방지하고자 모달 컴포넌트들에 대해서 코드스플리팅을 적용해볼 수 있다. 코드 스플리팅을 적용하면 해당 모달 컴포넌트가 렌더링 될때만 관련 코드를 로드하도록 하여 모달로 인한 리소스 로딩 성능 저하를 예방할 수 있다. 여기선 loadable 이라는 라이브러리를 사용했으며 기존 프로젝트는 Next.js 기반으로 이루어져 있기 때문에 ssr 옵션을 false 값으로 주도록 했다.

😳 리팩토링 적용

실제 리팩토링이 적용된 코드들은 여기서 살펴볼 수 있다.

⛳️ 출처 및 참고자료

• SLASH21 - 실무에서 바로 쓰는 Frontend Clean Code

• 효율적인 modal 관리 with React

NextJS와 Emotion을 기반으로 진행한 프로젝트에서 다크모드를 도입하여 사이트를 구성해보았다. 그런데 웬걸 새로고침이나 페이지 진입 할 때 카메라 플래시마냥 깜빡임 현상이 발생하고 말았다 😇

이번 포스트에서는 이 깜빡임이 무슨 원인에서 비롯되었는지 분석해보고 어떤 식으로 해결할 수 있는지 공유해볼 것이다.

👀 다크모드 짚어보기

이번 프로젝트에서 구현해본 다크모드는 다음의 기능들을 만족해야한다.

1. 이미 진입했던 사용자가 로컬스토리지를 통해 저장해두었던 테마값이 있을 경우 이에 따라 렌더링을 진행한다.

2. 그렇지 않고 디바이스에서 지정한 테마(prefers-color-scheme)값이 존재하는 경우 이에 맞는 화면을 렌더링한다.

3. 그마저도 아니라면 기본 색상인 다크 테마를 띄운다.

이제 이 요구사항을 구현해보자!

🌚 다크모드 구현하기

다음과 테마별로 사용할 스타일 속성을 지정하였다.

import { Theme } from '@emotion/react';

const lightTheme: Theme = {
  mode: 'light',
  text: 'black',
  background: '#fafafa',
  borderColor: '#eaeaea',
  bodyColor: 'white',
};

const darkTheme: Theme = {
  mode: 'dark',
  text: 'white',
  background: '#111',
  borderColor: '#222',
  bodyColor: 'black',
};

export { lightTheme, darkTheme };

그리고 라이트/다크 모드 여부를 확인할 수 있는 ColorModeContext 를 아래와 같이 구성한다.

import { ReactNode, createContext, useEffect, useRef, useContext, useState } from 'react';
import useMediaQuery from '../hooks/useMediaQuery';

interface ColorModeContextValue {
  colorMode: string | null;
  setColorMode: (value: string) => void;
}

const ColorModeContext = createContext<ColorModeContextValue | null>(null);

const ColorModeProvider = ({ children }: { children: ReactNode }) => {
  const [colorMode, setRawColorMode] = useState('dark'); // 기본 테마는 다크로 간주
  const systemPrefers = useMediaQuery('(prefers-color-scheme: dark)');
  const firstRender = useRef(true);

  const setColorMode = (value: string) => {
    setRawColorMode(value);
    window.localStorage.setItem('color-mode', value);
  };

  useEffect(() => {
    // 첫번째 렌더링 시에만 실행
    if (firstRender.current) {
      // osTheme는 운영체제 지정 테마
      const osTheme = systemPrefers ? 'dark' : 'light';
      // 유저가 선택한 테마(로컬스토리지에 저장된 값을 추출)
      const userTheme = window.localStorage.getItem('color-mode');
      // userTheme를 우선으로 하고 없다면 osTheme로 지정
      const theme = userTheme || osTheme;
      setRawColorMode(theme);
      firstRender.current = false;
    } else {
      // 마운트 이후에는 바뀌는 사용자 선호도에 테마 변화를 대응
      setRawColorMode(systemPrefers ? 'dark' : 'light');
    }
  }, [systemPrefers]);

  return (
    <ColorModeContext.Provider value={{ colorMode, setColorMode }}>
      {children}
    </ColorModeContext.Provider>
  );
};

const useColorModeContext = () => {
  const context = useContext(ColorModeContext);
  if (context === null) {
    throw new Error('useColorModeContext must be used within a ThemeProvider');
  }
  return context;
};

export { ColorModeProvider, useColorModeContext };

그 다음에는 ColorModeContext 로부터 변화하는 colorMode에 따라 알맞은 테마를 주도록 다음과 같이 ThemeProvider를 구성한다

import { ReactNode } from 'react';
import { lightTheme, darkTheme } from '../styles/theme';
import { ThemeProvider as EmotionThemeProvider } from '@emotion/react';
import { useColorModeContext } from './ColorModeContext';

const ThemeProvider = ({ children }: { children: ReactNode }) => {
  const { colorMode } = useColorModeContext();
  return (
    <EmotionThemeProvider theme={colorMode === 'light' ? lightTheme : darkTheme}>
      {children}
    </EmotionThemeProvider>
  );
};

export default ThemeProvider;

마지막으로 _app.tsx를 다음과 같이 구성한다.

import type { AppProps } from 'next/app';
import ThemeProvider from '../components/ThemeProvider';
import { ColorModeProvider } from '../components/ColorModeContext';
import GlobalStyles from '../styles/GlobalStyles';

export default function App({ Component, pageProps }: AppProps) {
  return (
    <ColorModeProvider>
      <ThemeProvider>
        <GlobalStyles />
        <Component {...pageProps} />
      </ThemeProvider>
    </ColorModeProvider>
  );
}

참고로 이렇게 했을때 development 모드에서는 잘 안될 수가 있다.이는 reactStrictMode가 켜져있기 때문이다. 아래와 같이 next.config.js를 수정해주면 된다.

/** @type {import('next').NextConfig} */
const nextConfig = {
  // reactStrictMode: true, // 이 부분을 지워버리자!
  swcMinify: true,
};

module.exports = nextConfig;

💡 reactStrictMode는 development 모드에서 버그를 찾는데 도움을 주는 요소이기 때문에 다크모드 구현이 끝나면 되돌리는 것을 추천드립니다.

관련된 자세한 코드는 여기서 확인할 수 있다.

일차적으로 구현했을때의 모습은 다음과 같다.

버튼을 누르면서 테마를 전환할 수 있고 시스템 선호도를 변경하면 이에 따라 반응하는 것을 확인할 수 있다. 또한 새로고침을 하더라도 시스템 선호도가 아니라 사용자가 지정한 값으로 초기화되는 것을 확인할 수 있다.

🔦 문제와 원인 분석

잘 되는 것 같지만 새로고침을 하게되면 깜빡임 현상이 발생한다. 순간 검은색으로 변하는 현상이 발생하는 것이 보일 것이다.

이러한 문제가 발생하는 것은 초기에 렌더링한 색상과 차후에 구현한 다크모드 기능끼리 충돌이 발생하기 때문이다.

const ColorModeProvider = ({ children }: { children: ReactNode }) => {
  const [colorMode, setRawColorMode] = useState('dark'); // 초기 테마값
  const systemPrefers = useMediaQuery('(prefers-color-scheme: dark)');
  const firstRender = useRef(true);

  ...

  useEffect(() => {
    // 마운트 이후 조정되는 테마값
    if (firstRender.current) {
      const osTheme = systemPrefers ? 'dark' : 'light';
      const userTheme = window.localStorage.getItem('color-mode');
      const theme = userTheme || osTheme;
      setRawColorMode(theme);
      firstRender.current = false;
    } else{
      ...
    }
  }, [systemPrefers]);

  return (
    <ColorModeContext.Provider value={{ colorMode, setColorMode }}>
      {children}
    </ColorModeContext.Provider>
  );
};

서버사이드 렌더링이 이뤄질 당시에는 브라우저 API를 참조할 수 없기 때문에 임의로 테마값을 렌더링 할 수 밖에없다. 그러면 기본값인 다크모드의 페이지가 나오게 될것이다. 그러다가 마운트 되고 나서는 로컬스토리지와 시스템선호도값을 파악하게 되고 이때 라이트모드의 페이지로 바꿔줘야한다. 이 때문에 깜빡임이 발생하게 되는 것이다.

🤔 해결책을 고민해보자

1. 서버가 브라우저 없이도 미리 사용자의 테마를 알고 있기?

이런 기능을 구현하기 위해서는 사용자별로 테마를 데이터베이스에 들고 있어야 하고 테마 전환시 API 통신을 해야하는 등 배보다 배꼽이 큰 상황이 발생하게 될 것이다. 또한 서비스에 처음으로 진입하는 사용자의 테마는 알길이 없으므로 이는 해결책으로 가져가기 어려운 방법이다. 따라서 클라이언트 단에서 해결하는 방법이 고안되어야 한다.

2. 클라이언트 단에서 돔요소를 렌더링하기 전에 테마를 먼저 파악한다면?

돔요소들을 띄우기 전에 테마가 무엇인지 파악하여 다크모드인지 라이트 모드인지를 알맞게 설정 한다면 정확한 페이지를 렌더링 할 수 있을 것 같다!

🛼 짚고가야할 사전 지식들

해결책을 설명하기에 앞서 짚고가야할 지식들을 알아보자

렌더링의 프로세스

기본적으로 웹 페이지를 렌더링하는 과정에는 크게 6가지의 과정들이 있다. 여기서 렌더링이란 화면요소를 그리는 과정을 의미한다.

1. HTML 파싱

HTML 파일을 읽어들이면서 마크업 단위로 쪼개는 과정이다. div, img, h1 등 여러가지 태그들을 읽어들이며 의미있는 단위로 만들어낸다. 파싱순서는 위에서 아래로 그리고 우에서 좌측으로 진행된다. 이때 유념해야 될 것은 script 태그 같은 경우 따로 속성을 지정하지 않으면(defer 등) script 해석이 끝날때까지 HTML 파싱이 블로킹 된다는 점이다.

2. CSS 파싱

CSS 파일을 읽어들이는 과정이다. HTML과 비슷하게 읽어들이는 과정이다.

3. DOM, CSSOM 트리 생성

앞서 파싱된 HTML과 CSS를 바탕으로 DOM 트리, CSSOM 트리를 만들어낸다. 어떤 요소들과 부모 자식 관계를 가져내는지를 트리 구조로 나타내는 과정이다.

4. 렌더 트리 생성

DOM, CSSOM 트리가 만들어지고나서 각각 특정 DOM이 어느 CSSOM과 결합되는지를 나타내는 과정이다. 이때까지도 실제 화면이 그려지는게 아니라 객체의 형태로만 나타난다.

5. 레이아웃

형성된 렌터 트리 내 요소들이 어느 위치에 그려지는지를 연산하는 과정이다. 예를 들어 div 는 x좌표가 20이고 y좌표가 50 이어야 겠다라는 것을 계산하는 과정이다. 이 레이아웃 과정은 다른 요소들에게도 영향을 주는 과정이라 비용이 굉장히 비싸다.

6. 페인트

레이아웃으로 구성된 요소들을 실제 화면에 그려내는 과정이다. 앞써 레이아웃이 비싼 과정이었다면 페인트는 분석된 값들을 화면에 그려내기만 하면 되기 때문에 비용이 비싼 과정은 아니다.

여기서 집중해서봐야될 과정은 1, 2, 3번이다. DOM 트리와 CSSOM 트리가 생성되면서 어떤 요소들이 어떤 스타일로 띄워질지 결정되는 과정들이기 때문이다.

그렇다면 우리의 문제와 결합시켜서 생각해보았을때 이 DOM트리가 생성되기 직전에 어떤 테마로 화면을 그려낼지 결정을 하면 되지 않을까?

HTML Blocking

앞서 렌더링의 1번 과정을 설명할때 script 태그가 해석되는 동안에는 HTML 파싱이 중단된다고 하였다. 이러한 현상을 HTML Blocking 이라고 한다.

<body>
  <script>
    alert('다크모드 개선하자!');
  </script>
  <div>
    ...
  </div>
</body>

위 코드의 실행결과인 위의 사진을 보면 확인해볼 수 있듯이 script 태그 내부의 alert 함수 호출로인하여 h1 태그가 렌더링 되지 않고 막혀버리는 모습이다. 이 원리를 활용해본다면 DOM트리가 생성되기 직전에 어떤 테마로 화면을 그려낼지 결정 하는 과정을 잘 처리해볼 수 있을 것 같다.

<html>
  <head>
    <title>Dark Mode</title>
  </head>
  <body>
    <script>
      /*
        - 로컬 스토리지를 확인해본다.
        - prefers-color-scheme라는 미디어 쿼리 속성을 확인해본다.
        - 어떤 테마로 띄울지를 결정한다.
      /*
    </script>
    <div>
         ...
    </div>
  </body>
</html>

위와 같이 HTML을 구성해본다면 어떤 테마로 띄워볼지 결정해보는 과정을 돔요소를 띄우기 전에 할 수 있을 것이다.

CSS 변수

기존에 Emotion으로 라이트/다크모드에 맞는 테마를 렌더링하는 로직은 아래와 같다.

const lightTheme: Theme = {
  mode: 'light',
  text: 'black',
  background: '#fafafa',
  borderColor: '#eaeaea',
  bodyColor: 'white',
};

const darkTheme: Theme = {
  mode: 'dark',
  text: 'white',
  background: '#111',
  borderColor: '#222',
  bodyColor: 'black',
};

const ThemeProvider = ({ children }: { children: ReactNode }) => {
  const { colorMode } = useColorModeContext();
  return (
    <EmotionThemeProvider theme={colorMode === 'light' ? lightTheme : darkTheme}>
      {children}
    </EmotionThemeProvider>
  );
};

그리고 이런 테마값들을 이용해 컴포넌트들을 스타일링하면 다음과 같이 할 수 있다.

const Button = styled.button`
  background: ${({ theme }) => theme.background};
  color: ${({ theme }) => theme.text};
  padding: 1rem;
  border-radius: 4px;
`;

이 로직이 문제가 되는 점은 바로 useColorModeContext 에 의존적이라는 것이다. 즉, 마운트가 되면서 바뀔 수 있는 값 colorMode 에 의해 스타일 속성들이 좌지우지 되버리고 이로 인해 깜빡임 현상이 발생하게 된다.

그러므로 돔요소들이 파싱되기 전에 스타일링을 할 수 있도록 해야한다. 한편, 그 CSS 값은 테마가 바뀜에 따라 동일하게 변화할 수 있어야한다. 이때 사용해 볼 수 있는 것이 css 변수이다! CSS 변수는 선언해놓으면 body 태그보다 상단에 위치하게 되며, 그 값을 바꾸면 바로 렌더링에 반영된다.

CSS가 아니라 어색할 수는 있지만 Emotion과 같은 CSS-in-JS 방식에서도 CSS 변수를 손쉽게 사용할 수 있다.

const Button = styled.button`
  background: var(--background-color);
  color: var(--text-color);
  padding: 1rem;
  border-radius: 4px;
`;

따라서 우리가 적용해볼 수 있는 해결책은

1. CSS 변수를 이용해 테마별로 다른 속성들을 스타일링한다.

2. 돔요소가 렌더링 되기 전에 테마를 파악하고 그 테마에 맞는 CSS 값을 설정할 수 있도록 스크립트를 적절히 삽입한다.

로 종합해 볼 수 있다.

🤛 해결해보기!

스크립트 삽입

위에서 살펴봤던 사전 지식들을 바탕으로 깜빡임 현상을 해결할 차례가 되었다. 우선 스크립트를 삽입해보는 방법에 대해서 알아보자.

Next.js에서 모든 돔요소보다 상단에 스크립트가 존재하기 위해서는 _document.tsx 라는 파일을 만들어주어야 한다. 공식문서에서는 다음과 같이 만들어야한다는 가이드라인을 제공해주고 있다.

import { Html, Head, Main, NextScript } from 'next/document'

export default function Document() {
  return (
    <Html>
      <Head />
      <body>
        <Main />
        <NextScript />
      </body>
    </Html>
  )
}

여기서 _documents.tsx 는 next.js 내 모든 페이지에서 전역적으로 사용되는 HTML 역할이라고 생각하면 된다. 보통은 lang 속성을 지정하는 용도로 사용을 하곤 하는데 우리는 스타일 속성을 지정할 수 있는 스크립트를 넣어줄 것이다.

const ScriptTag = () => {
  const codeToRunOnClient = `(function() {
  alert("다크모드 개선하자!");
})()`;

  return <script dangerouslySetInnerHTML={{ __html: codeToRunOnClient }} />;
};

export default function Document() {
  return (
    <Html>
      <Head />
      <body>
        <ScriptTag />
        <Main />
        <NextScript />
      </body>
    </Html>
  );
}

형태는 위와 같으며 클라이언트 단에서 실행될 코드를 문자열화 한뒤 이를 script 태그의 dangerouslySetInnerHTML 속성에 위치시켜준다. 이렇게해두면 다음과 같이 돔 요소가 렌더링 되기 전에 alert가 먼저 실행되는 것을 볼 수 있다.

참고로 리액트 내부적으로 스크립트를 삽입하여 사용할 때는 다음과 같이 dangerouslySetInnerHTML 속성을 이용해주는 것이 좋은데 이는 리액트에서 XSS 공격을 방지하기 위한 정책을 우회하기 위함이다.

필요한 스크립트 작성하기

스크립트 내부에서 실행되어야할 내용은 다음과 같다.

• 로컬스토리지와 미디어 쿼리의 prefers-color-scheme 속성을 확인해 렌더링할 컬러모드를 파악한다.

• 현재 어떤 컬러모드인지를 style 프로퍼티의 --initial-color-code 라는 이름으로 값을 넣는다.

• 컬러모드 별 필요한 스타일링 속성에 따라 CSS 변수값을 설정한다

이러한 요구사항을 만족할 수 있게 스크립트와 관련 함수를 작성해보자!

const COLOR_MODE_KEY = 'color-mode';
const INITIAL_COLOR_MODE_CSS_PROP = '--initial-color-mode';

function setColorsByTheme() {
  const modeProperties = '[modeProperties]';
  const colorModeKey = '[colorModeKey]';
  const colorModeCssProp = '[colorModeCssProp]';

  // 사용자 선호도 파악
  const mql = window.matchMedia('(prefers-color-scheme: dark)');
  const prefersDarkFromMq = mql.matches;

  // 로컬 스토리지에 저장된 테마값
  const persistedPreference = localStorage.getItem(colorModeKey);

  let colorMode = 'dark'; // 컬러모드 기본값은 다크

  const hasUsedToggle = typeof persistedPreference === 'string'; // 로컬스토리지에 저장된 테마값이 있는지 여부를 저장

  if (hasUsedToggle) {
    colorMode = persistedPreference; // 저장했으면 로컬스토리지값 대로 컬러모드 지정
  } else {
    colorMode = prefersDarkFromMq ? 'dark' : 'light'; // 아니라면 선호도에 따라 컬러모드 지정
  }

  const root = document.documentElement;

  // 스타일 태그 속성에 현재 컬러모드 값을 기록
  root.style.setProperty(colorModeCssProp, colorMode);

  // theme 속성값을 기반으로 css 변수를 만들어내기
  // 예를 들어 
  //  "card-background": {
  //          light: themeColors.primary.light,
  //          dark: themeColors.secondary.dark,
  //   },
  // 라는 테마값은 var(--card-background)로 변화함
  Object.entries(modeProperties).forEach(([name, colorByTheme]) => {
    const cssVarName = `--${name}`;
    // @ts-ignore
    root.style.setProperty(cssVarName, colorByTheme[colorMode]);
  });
}

이제 이 함수를 문자열화 하여 스크립트에 삽입하자!

const ScriptTag = () => {
  const stringifyFn = String(setColorsByTheme)
    // eslint-disable-next-line quotes
    .replace('"[MODEPROPERTIES]"', JSON.stringify(themeProperties)) // JSON은 문자열로 변환시 쌍따옴표가 생겨서 추가적으로 쌍따옴표를 붙여서 처리해야 함.
    .replace('[COLORMODEKEY]', COLOR_MODE_KEY) 
    .replace('[COLORMODECSSPROP]', INITIAL_COLOR_MODE_CSS_PROP);

  const fnToRunOnClient = `(${stringifyFn})()`;

  return <script dangerouslySetInnerHTML={{ __html: fnToRunOnClient }} />;
};

export default function Document() {
  return (
    <Html>
      <Head />
      <body>
        <ScriptTag />
        <Main />
        <NextScript />
      </body>
    </Html>
  );
}

이 과정들은 다소 생소할 수 있다. 여기서 한가지 의문이 들 수 있다.

？ 왜 함수와 변수를 문자열로 변환하여 저장하는 것인가?

이 스크립트 태그는 번들링된 자바스크립트를 불러오기 전에 실행이 된다. 이 때문에 번들링 된 값을 그대로 표시되면 원하는대로 실행이 될 수 없다. 가령,

import { themeProperties } from '../styles/theme';

export function setColorsByTheme() {
  const modeProperties = themeProperties;

  ...

  // generating css variables based on modeProperties
  Object.entries(modeProperties).forEach(([name, colorByTheme]) => {
    const cssVarName = `--${name}`;
    // @ts-ignore
    root.style.setProperty(cssVarName, colorByTheme[colorMode]);
  });
}

이렇게 작성한다면 themeProperties 라는 변수가 번들링된 자바스크립트를 가져와야 되고 이렇게 할 경우 스크립트가 제대로 실행될 수 없는 것이다. 이러한 이유로 함수 뿐만 아니라 내부 변수들도 문자열화한것은 replace 시키는 것이다. 이렇게 문자열로 변환하여 작성하게 되면 HTML에 다음과 같이 삽입된다.

이렇게 삽입이 되면 어떤 번들링 로드 없이도 바로 실행가능한 스크립트가 완성된다!

테마값 변경하기

테마에서 해야될 것이 있다. setColorsByTheme 함수 마지막 부분에서는 modeProperties라는 오브젝트를 변환해 알맞은 css 변수로 변환해주고 있다.

예를 들어

"card-background": {
    light: themeColors.primary.light,
    dark: themeColors.secondary.dark,
}

라는 테마객체를 var(--card-background)로 변화시키는 방식이다. 이를 위해서 theme 객체에 다음과 같이 값을 추가해준다.

// theme.tsx

const themeProperties = {
  'mode-color': {
    light: lightTheme.mode,
    dark: darkTheme.mode,
  },
  'text-color': {
    light: lightTheme.text,
    dark: darkTheme.text,
  },
  'background-color': {
    light: lightTheme.background,
    dark: darkTheme.background,
  },
  'border-color': {
    light: lightTheme.borderColor,
    dark: darkTheme.borderColor,
  },
  'body-color': {
    light: lightTheme.bodyColor,
    dark: darkTheme.bodyColor,
  },
};

앞으로 다크모드와 라이트모드에 따라 변경되는 스타일 값이 있다면 위와 같은 형식으로 테마 속성을 작성하면 된다.

CSS 변수로 스타일 변경하기

추가적으로 기존의 스타일링 코드를 emotion theme 대신 css 변수로 변환하기만 하면 된다. 가령

const Button = styled.button`
  background: ${({ theme }) => theme.background};
  color: ${({ theme }) => theme.text};
  padding: 1rem;
  border-radius: 4px;
`;

다음과 같이 작성된 코드는 아래로 바꾸면 된다.

const Button = styled.button`
  background: var(--background-color);
  color: var(--text-color);
  padding: 1rem;
  border-radius: 4px;
`;

colorMode 변경함수 기능 추가

마지막으로 버튼을 누르거나 시스템 선호도 변경시 테마 변경 대응하는 부분에서 css 변수도 알맞게 변경해주도록 하는 부분을 추가해주면 된다.

const ColorModeProvider = ({ children }: { children: ReactNode }) => {
  const [colorMode, setRawColorMode] = useState<string | undefined>(undefined);
  const systemPrefers = useMediaQuery('(prefers-color-scheme: dark)');
  const firstRender = useRef(true);

  // 컬러모드 설정 함수
  const setColorMode = useCallback((value: 'light' | 'dark') => {
    const root = window.document.documentElement;
    // 바뀐 값에 대응해 css 변수들도 교체
    Object.entries(themeProperties).forEach(([name, colorByTheme]) => {
      const cssVarName = `--${name}`;
      root.style.setProperty(cssVarName, colorByTheme[value]);
    });

    setRawColorMode(value);
    window.localStorage.setItem('color-mode', value);
  }, []);

  useEffect(() => {
    if (firstRender.current) {
      const osTheme = systemPrefers ? 'dark' : 'light';
      const userTheme = window.localStorage.getItem('color-mode');
      const theme = userTheme || osTheme;
      setRawColorMode(theme);
      firstRender.current = false;
    } else {
      setColorMode(systemPrefers ? 'dark' : 'light');
    }
  }, [systemPrefers]);

  return (
    <ColorModeContext.Provider value={{ colorMode, setColorMode }}>
      {children}
    </ColorModeContext.Provider>
  );
};

✨ 결과 확인하기!

기존의 기능은 살리면서도 새로고침 시 더이상 깜빡임이 발생하지 않는 것을 확인할 수 있다!

완성된 코드는 이 레포지토리에서 확인해볼 수 있다.

⛳️ 출처

• [웹브라우저 렌더링 프로세스] (https://cresumerjang.github.io/2019/06/24/critical-rendering-path/)

• The quest for perfect dark mode

자바스크립트에서는 다른 상속 기반의 언어와 달리, prototype(원형) 기반의 언어로, 모든 객체는 특정 객체를 원형(prototype)으로 삼고 이를 복제(참조)하는 방식을 통해 상속과 비슷한 효과를 가지게 한다.

개념 추상화

프로토타입을 추상화 하면 위와 같은 그림이 나오는데 이 그림은 다음의 의미를 가진다.

• 생성자(Constructor)은 원형(prototype)을 속성으로 가진다.
• 생성자와 new 키워드를 결합하면 인스턴스(instance) 가 생성된다.
• 이때 인스턴스는 자동으로 __proto__ 속성을 가진다.
• 이 __proto__ 속성은 생성자의 prototype 을 참조한다.

인스턴스와 proto 의 관계와 이해

let Person = function (name) {
    this._name = name;
}

Person.prototype.getName = function () {
    console.log('call getName method');
    return this._name;
}

위와 같이 생성자 함수 Person 을 정의하고 생성자 함수의 prototype 에getName 이라는 메소드를 정의하였다.

const j113 = new Person("seungchan");

j113.__proto__.getName(); 
// call getName method
// undefined

j113 이라는 인스턴스를 생성해주었고 이 인스턴스의 prototype 에 정의된 getName 이라는 메소드를 호출하였다. 이때 결과로 undefined 가 나오고 에러가 발생하지는 않는다.

Person.prototype === j113.__proto__ // true

참고로, 인스턴스에서 호출하는 __proto__ 는 Person 의 prototype 과 동일하기에 getName 메소드를 호출 할 수 있다.

이를 통해 알 수 있는 것은 prototype 에 정의된 getName 메소드에는 잘 도달하지만 getName 에서 반환하는 this._name 이 문제가 될 것이다. 이는 getName 메소드에서 this 가 무엇인지를 확인하면 원인파악이 되는데 getName 메소드를 호출하는 주체가 j113.__proto__ 이고 이는 곧 Person의 prototype 인데 여기에는 _name 이라는 것이 존재하지 않는다. 그래서 위의 예시에서 undefined 가 나오게 된 것이다.

// Person 생성자함수 정의는 생략
Person.prototype._name = "seungchan"

const j113 = new Person("seungchan");

j113.__proto__.getName();
// seungchan

실제로 위에 처럼 Person 의 prototype 자체에 _name 프로퍼티를 정의해 놓으면 getName 이 원하는대로 출력되는 것을 확인할 수 있다.

const j113 = new Person("seungchan");

j113.getName();// seungchan

또한, 인스턴스에서 __proto__ 라는 키워드를 생략한뒤 메소드를 호출하면 this 가 인스턴스가 됨으로써 원하는 결과가 나오게 된다. 여기서 인스턴스에서 어떻게 prototype 으로 접근이 가능한지 궁금할 수 있는데 이는 자바스크립트 문법을 설계하면서 정해진 규칙이라고 한다 (이런거 보면 참 근본 없다.)

이러한 특징들을 정리하자면 다음과 같다.

• 생성자 함수의 prototype에 정의된 메소드나 프로퍼티는 생성된 인스턴스에서 자신의 것처럼 접근이 가능하다.
• 인스턴스에서 __proto__ 키워드는 생략이 가능하다.

prototype을 기반으로 Array에 대해 이해하기

자바스크립트 내 배열 자료구조를 통해서 생성자함수 Array 와 이것의 인스턴스를 이해해보고자 한다.

const arr = [1,2];

console.dir(arr);

console.dir(Array);

위의 출력 결과는 다음과 같다.

생성자함수 Array의 인스턴스인 arr의 __proto__ 는 생성자함수 Array의 prototype 과 동일한 것을 참조하는 걸 알 수 있다. 이를 추상화 해보면 다음과 같다.

메소드 오버라이드

인스턴스는 __proto__ 라는 키워드를 생략하더라도 prototype 에 정의된 메소드 및 프로퍼티에 자유롭게 접근이 가능하다. 한편 프로토타입에 정의된 메소드와 동일한 이름의 메소드를 인스턴스에 정의하게 될 경우에는 인스턴스의 함수로 덮어씌워진다.

let Person = function(name){
    this.name = name;
}

Person.prototype.getName = function() {
    return this.name;
}

const seungchan = new Person('승찬');

seungchan.getName = function () {
    return 'i am ' + this.name;
}

console.log(seungchan.getName()); // i am 승찬

한편, 인스턴스의 메소드가 아닌 prototype 에서 정의한 메소드에 직접 접근하기 위해서는 아래와 같이 __proto__ 키워드를 사용해야 한다.

console.log(seungchan.__proto__.getName()); // undefined

하지만 위와 같이 this 가 가리키는 대상이 인스턴스의 __proto__ 가 참조하는 prototype 이 되기 때문에 적절한 name 을 가져오지 못한다. 아래와 같이 이는 call 를 사용하여 this 를 인스턴스로 지정해주면 해결 될 수 있다.

console.log(seungchan.__proto__.getName()).call(seungchan); // "seungchan"

프로토타입 체이닝

배열 인스턴스의 프로토타입인 Array 생성자함수의 프로토타입을 자세히 살펴보면 아래와 같다.

console.dir([1,2]); 

[1,2] 의 __proto__는 Array 를 가리키고 다시 Array 의 __proto__ 는 Object 를 가리키는 것을 확인할 수 있다. 이를 추상화하면 아래와 같다.

이러한 관계 덕분에 배열의 인스턴스인 [1,2] 는 Array의 메소드 뿐만 아니라 Object에서 정의된 메소드가 까지 사용이 가능해진다.

var arr = [1,2];

arr(.__proto__).push(3); // Array에 정의된 push 메소드

arr(.__proto__)(.__proto__).hasOwnProperty(2); // Object에 정의된 메소드

한편 모든 타입은 prototype 을 가지고 prototype 은 Object 형태를 가지게 되기 때문에 prototype 체인의 최상단에는 Object 가 존재하게 된다.

이렇다보니 모든 데이터타입에서 Object 프로토타입에 정의된 메소드들을 접근할 수 있게 된다. 가령 hasOwnProperty 가 대표적인 예이다. 한편 모든 Object 의 메소드 중 일부는 모든 데이터타입에서 사용될 수 있게 설계 되어 있지는 않다. 이 때문에 그러한 메소드들은 정적인 메소드로 정의되게 되었다.

Object.freeze(...);

Object.entries(...);

Obejcts.keys(...)

이 때문에 위의 메서드들은 Object 키워드와 함께 사용되어야 하는 것이다.

⛳️ 출처 및 참고자료

코어 자바스크립트 - 정재남 지음

• 자바스크립트 엔진 자체는 싱글 스레드로 동작하고 자바스크립트를 구동하는 환경이 멀티스레드 환경에서 동작한다.
• Task Queue는 두가지로 분류되어 Call stack이 비어있을 때 우선순위 따라 다르게 처리된다.

🪡 자바스크립트와 비동기 처리

자바스크립트는 단일 쓰레드 기반의 언어로 기본적으로 스레드가 하나이기에 동시에 하나의 작업만을 처리할 수 있다는 것을 시사한다. 하지만 실제로 자바스크립트가 사용되는 환경을 생각해보면 하나의 작업만이 아닌 더 많은 작업들이 동시에 처리되는 것을 확인할 수 있다. 예를 들어, 웹브라우저는 애니메이션 효과를 보여주면서 마우스 입력을 받아 처리한다든지, Node.js 기반의 웹서버에서는 동시에 여러 개의 HTTP 요청을 처리하기도 한다. 이처럼 단일 스레드인 자바스크립트에서도 동시성을 지원할 수 있는 비결에는 이벤트 루프 가 존재하여 비동기적인 일 처리를 가능케 하기 때문이다.

👍 자바스크립트 자체는 단일 스레드이다.

위에서 자바스크립트가 단일 스레드 기반임에도 동시성을 지원한다고 서술하였지만, 자바스크립트 엔진에는 이벤트 루프를 취급하지 않는다. 자바스크립트의 엔진인 V8의 경우 단일 호출 스택(Call stack)을 사용하며 요청이 들어올 때 마다 해당 요청을 순차적으로 호출 스택에 담아 처리할 뿐이다.

비동기 요청은 자바스크립트 엔진을 구동하는 환경, 즉 브라우저나 NodeJS가 담당한다. 브라우저 환경은 다음과 같다.

비동기 호출을 위해 사용하는 setTimeout 이나 XMLHttpRequest 와 같은 함수들은 자바스크립트 엔진이 아닌 Web API 영역에 따로 정의되어 있다. 또한 이벤트 루프와 태스크 큐와 같은 장치들도 자바스크립트 엔진 밖에 구현되어 있는 것을 확인할 수 있다.

NodeJS 환경에서도 브라우저와 거의 비슷한 구조를 볼 수 있는데, 차이점이 있다면 비동기 IO를 지원하기 위하여 libuv 라이브러리를 사용하며 이 libuv 가 이벤트 루프를 제공한다. 자바스크립트 엔진은 비동기 작업을 위해서 NodeJS의 API를 호출하며, 이때 넘겨진 콜백은 libuv 의 이벤트 루프를 통해 스케쥴되고 실행된다.

위에서 확인해 보았듯이 자바스크립트가 단일 스레드 기반의 언어라는 말은 자바스크립트 엔진이 단일 호출 스택을 사용한다는 관점에서만 사실이다. 실제 자바스크립트가 구동되는 환경(브라우저, NodeJS 등)에서는 주로 여러 개의 스레드가 사용되며, 이러한 구동 환경이 단일 호출 스택을 사용하는 자바스크립트 엔진과 상호 연동하기 위해 사용하는 장치가 바로 이벤트 루프 인 것이다.

♻️ 이벤트 루프와 Task Queue

앞서 자바스크립트에서는 비동기 이벤트들을 처리하기 위해서 Task Queue 와 이벤트 루프를 활용한다고 하였다.

위의 그림에서 볼 수 있듯이 자바스크립트에서 Web API에 정의 되어있는 비동기 이벤트들을 호출하게 되면 Callback(Task) Queue와 이벤트 루프가 연계하여 비동기 이벤트를 처리하게 된다. 이를 자세하게 알아보기 위해 아래의 코드를 실행해본다고 하자.

const foo = () => console.log("First");
const bar = () => setTimeout(() => console.log("Second"), 500);
const baz = () => console.log("Third");

bar();
foo();
baz();

실행 과정은 다음의 순서로 진행된다.

1. bar 함수가 호출된다. 이때 Call stack에 들어온 setTimeout 이라는 비동기 API를 처리해야 되기에 WebAPI 에서 500 밀리 초 동안 대기하게 된다
2. 대기 하는 동안 foo 함수가 호출되고 이로 인해 출력창에 “First” 가 나온다.
3. setTimeout에서 명시한 대기시간이 만료되어 Task Queue 로 전달된다. Task Queue 에 쌓이는 내용들은 이벤트 루프에 의해서 처리되는데, 이는 Call stack 이 비어있는 경우에만 이벤트루프에 의해 처리된다.
4. baz 함수가 호출되고 출력창에 “Third” 가 나온다.
5. Call stack 이 비어있는 상태인것을 파악한 이벤트 루프가 Task Queue 에 저장되어 있던 setTimeout 의 콜백함수를 콜스택에 넘기고 실행이 이루어지면서 출력창에는 “Second” 가 나오게 된다.

즉 정리해보자면, 동기적인 Task들은 Call stack 에 의하여 순차적으로 처리되는 반면 setTimeout 과 같은 비동기 이벤트들은 Call stack에 들어오더라도 Web API와 Task Queue를 거친 뒤 Call stack 이 비어있을때에만 이벤트 루프에 의해 Call stack 으로 옮겨져 다시 처리됨을 알 수 있다.

⚙️ Micro Task , Macro Task

Task Queue 에 의해서 비동기적으로 처리되는 Task들은 크게 두 가지 종류로 나뉘게 된다. 우선순위 다소 높은 비동기 API들을 Macro Task로 분류하며 대표적인 예로 위에서 다뤘던 setTimeout , setInterval , setImmediate 등이 있다. 한편, 이보다 더 높은 우선순위를 가지는 비동기 API들은 Micro Task 로 분류하며, process.nextTick, Promise객체의 callback, queueMicrotask 등이 있다. 그럼 이들이 어떤 방식으로 처리되게 될까?

앞에서 말했듯이 우선순위가 더 높은 Task들이 Micro Task 들로 분류되기에 위 그림 처럼 여기에 저장되어있던 비동기 Task들이 우선적으로 처리된 이후에, Macro Task 에 저장된 Task들이 처리되는 모습이다. 물론 Micro Task 들 역시도 Call stack 에서 더 이상 처리할게 없어야 비로소 실행된다.

그러면 실제 예시에서 setTimeout 가 Promise 객체의 코드가 동시에 주어졌을때 어떻게 처리되는지 확인해보자. 예시로 다음의 코드를 살펴보자.

console.log('Start!');

setTimeout(() => {
    console.log('Timeout!');
}, 0);

Promise.resolve('Promise!').then(res => console.log(res));

console.log('End!');

코드 내용을 살펴보면, 첫번째 비동기 부분에선 setTimeout 을 통해서 0초동안 대기 하였다가 Timeout! 을 출력하는 콜백함수를 실행한다. 두번째 비동기 부분에선 Promise 객체에 의해 비동기 적으로 Promise! 라는 텍스트를 출력하는 부분이다. 이 코드를 실행해보면 아래와 같다.

Call Stack에 첫번째 코드 부분이 쌓인 뒤 실행 되어 콘솔창에 Start! 가 출력된다.

setTimeout 부분이 콜스택에 적재된 이후에 WebAPI 에 의해 타이머가 작동하게 된다. 0초라서 사실상 바로 타이머는 종료된다.

타이머가 종료됨에 따라 setTimeout 의 콜백함수 부분은 MacroTask 로 분류된다. 세번째 부분인 Promise 부분에선 콜스택에 적재 된다. 이때 Promise.resolve 는 인자로 받은 값을 .then 키워드 부분에 전달하는 역할을 함과 동시에 비동기 처리를 해제하는 역할을 한다. 이에 따라 .then 이후 부분은 MircroTask 에 분류시킨다.

네번째 부분이 실행됨에 따라 End! 라는 글자가 콘솔창에 출력된다. 이때 Task Queue에 적재된 Task들은 아직 Call Stack 내부가 아직 비워지지 않음에 따라 아직 Queue에서 빠져나가지 않는다.

Call stack 이 비워진 것을 파악한 이벤트 루프는 순차적으로 MicroTask Queue 에 있는 Task들을 비워낸 후 MacroTask Queue 에 있는 Task들을 비워낸다. 비워낼때에는 당연히 Call Stack에 적재 시킨뒤에 순차적으로 실행시켜 처리한다.

🚧 Async/Await 와 이벤트 루프

Async/Await 키워드는 비동기 처리를 위해 ES7 부터 새롭게 도입된 것으로 기존의 Promise 와 잘 호환되게 설계 되었다. 이전에는 비동기 이벤트 처리를 위해 Promise 객체를 직접적으로 명시하는 수고가 필요했는데 이는 잘 작동하겠지만, 여전히 직관성이 떨어지는 코드에 해당된다.

Async/await 키워드를 이용해 이제 Promise 객체를 반환하는 부분을 직관적으로 표현할 수 있게 된다.

이를 자세하게 파헤쳐 보고자 아래의 코드를 예시로 알아보고자 한다.

const one = () => Promise.resolve('One!');

async function myFunc(){
    console.log('In function!');
    const res = await One();
    console.log(res);
}

console.log('Before Function!');
myFunc();
console.log('After Function!');

위의 코드를 실행해보면 다음과 같은 결과를 얻게 된다. 어떻게 되는건지 한줄한줄 파헤쳐 보자.

당연하게도 첫번째에서는 Call stack에 console.log 부분이 적재된 이후에 실행되어 ‘Before function!’ 이라는 문장이 출력되게 된다.

두번째 부분에서 myFunc 함수가 호출되고 내부에 console.log 부분이 호출됨에 따라 콘솔 창에는 In Function! 이 추가로 출력된다.

세번째에서는 myFunc 내부함수 one 이 호출되고 이는 Promise 객체를 반환한다. 이때 중요한 것은 await 키워드가 있다는 점인데, 이로 인해 myFunc 함수의 내부 실행은 잠시 중단되고 Call stack 에서 빠져나와 나머지 부분은 Microtask Queue 에 의해 처리된다. 이는 자바스크립트 엔진이 await 키워드를 인식하면 async 함수의 실행은 지연되는 것으로 처리하기 때문이다.

“After function!” 이 출력하는 부분을 실행 한 뒤에 Microstask Queue 에 저장된 myFunc 실행 부분이 Call Stack 에 적재되어 실행된다. 그렇기에 마지막으로 one 이 반환하는 “One!” 이 출력된다.

참고로, 아래의 코드 처럼 await 키워드를 myFunc 실행부분 앞에도 추가하게 되면 위와 다른 결과가 나올것이다.

const one = () => Promise.resolve('One!');

async function myFunc(){
    console.log('In function!');
    const res = await one();
    console.log(res);
}

console.log('Before Function!');
await myFunc();
console.log('After Function!');

이는 myFunc을 호출한 최상단부 자체를 Microtask Queue 로 넘기고 res를 출력하는 부분부터 After Function 을 출력하는 부분까지 순차적으로 처리되게 되기 때문이다.

📌 출처와 참고자료

자바스크립트와 이벤트 루프 : NHN Cloud Meetup

[JavaScript] Task Queue말고 다른 큐가 더 있다고? (MicroTask Queue, Animation Frames)

JavaScript 비동기 핵심 Event Loop 정리

✨♻️ JavaScript Visualized: Event Loop

⭐️🎀 JavaScript Visualized: Promises & Async/Await

자바스크립트는 인터프리터언어이다. 그런데 컴파일러를 얹은.

🔍 컴파일러 / 인터프리터의 정의

Compiler (컴파일러)

컴파일러는 특정 프로그래밍 언어로 쓰여 있는 문서를 다른 프로그래밍 언어로 옮기는 언어 번역 프로그램을 의미한다. 가령 자바스크립트라는 고급 프로그래밍 언어를 기계어라는 다른 프로그래밍 언어로 번역하는 역할을 컴파일러가 수행한다.

Interpreter (인터프리터)

기계어를 다른 언어로 번역할 필요 없이 프로그래밍 언어의 소스 코드를 바로 실행하는 컴퓨터 프로그램 또는 환경을 말한다. 코드 한줄한줄씩 바로 실행해나가는 방식으로 진행된다. 이처럼 바로 실행이 가능하기에 변경사항을 빠르게 테스트해보기 용이하다는 장점이 있다.

자바스크립트는 기본적으로 인터프리터 언어이다.

기본적으로 자바스크립트는 인터프리터 언어에 해당한다. 다른 대표적인 컴파일러 언어인 C언어 혹은 C++의 경우에는 컴파일 과정(+어셈블러 +링커) 을 통해 실행파일을 생성해주어야 비로소 프로그램 실행이 가능해진다.

반면 파이썬이나 자바스크립트 같은 언어의 경우에는 위의 사진처럼 코드 한줄씩만 입력하더라도 바로바로 실행하며 결과를 확인하는 것이 가능하기에 인터프리터 언어에 해당하게 된다. 이는 자바스크립트가 만들어질 당시 웹문서 구조를 동적으로 나타내기 위해 제작된 언어이기에 가벼운 인터프리터 구조가 적합했기 때문이다.

그렇다고 자바스크립트가 따로 별도의 과정없이 바로 컴퓨터가 실행가능한 것은 아니다. 자바스크립트가 인터프리터에 전해지기 일련의 과정을 거쳐야 한다.

자바스크립트 구동원리

자바스크립트 뿐만 아니라 모든 고급언어들은 컴퓨터에서 구동되기 위해서 기본적으로 기계가 이해가능한 기계어로 변환되어질 필요가 있다.

위에서 보다시피 자바스크립트는 기계에게 전달되기전에 바이트 코드로 변환되고 이를 받아 가상머신에 의해 기계어로 변환된다. 이러한 일련의 변환 과정은 아래와 같이 진행된다.

1) 바이트 코드로의 변환

자바스크립트 엔진에 의해 바이트코드로 변환된다.

2) 기계어로 변환

CPU마다 기계어를 다르게 해석하기에 가상 머신은 최적화된 기계어를 제작해낸다. 이 가상머신 덕분에 개발자는 따로 CPU별로 최적화된 기계어를 만들어낼 필요는 없다.

3) CPU 코드 실행

기계어를 실행하여 데이터 저장 및 연산 작업을 진행한다.

자바스크립트 엔진 : Tokenizer > Parser > AST > 인터프리터

이제 JS가 자바스크립트 엔진에 의해 어떻게 바이트 코드로 변환되는지 알아본다. 이는 엔진 내 인터프리터가 진행한다. 인터프리터에게 전달되기 전에도 일련의 과정이 필요한데 이는 이번 6일차에서 배웠던 Tokenizer, Parser를 거쳐 AST가 되는 과정이다.

이를 단순화해서 보면 다음과 같다.

• Tokenizing : 주어진 소스코드를 의미있는 단위로 나누는 과정이다. 이렇게 나누어진 것을 Token이라고도 한다. (보통 의미를 부여하는 lexer의 역할도 여기에 포함된다.)

• Parser : Tokenizer 로부터 생성된 토큰들의 배열을 바탕으로 이를 자바스크립트 문법에 알맞은 방식으로 AST(Abstract Syntax Tree) 로 변화 시킨다.

• 이렇게 생성된 AST 는 인터프리터를 거쳐 기계가 알아볼 수 있는 바이트 코드롤 변환되게 되는 것이다.

이때까지만 해도 인터프리터 언어였다… 이게 등장하기 전까진

이러한 자바스크립트는 인터프리터 언어로서 기능을 해왔지만, 점차 웹에서도 다양한 요구사항들이 추가되면서 더 많은 기능들을 갖추어야 했고 이는 자바스크립트가 점차 성능상 무거워지는 계기가 되었다. 한편, 2009년 당시 구글은 웹에서 이용가능한 지도인 구글맵스를 개발하려고 있었는데 지도 어플리케이션은 사용자 상호작용이 많이 필요한 만큼 성능상 개선이 필요했고 이를 개선하고자 내놓은 것이 바로 Chrome V8 엔진이다. 이를 통해 자바스크립트 언어에서도 컴파일을 진행하게 된 계기가 되었다.

🤔 컴파일 언어의 성능 > 인터프리터 언어의 성능?

이에 대해 알아보기전에 왜 컴파일 언어의 성능이 더 효율적인지 이해해볼 필요가 있다. 컴파일 언어와 인터프리터 언의 가장 큰 차이점은 바로 실행전 미리 기계어로 바꾸어 놓는다는 점이다. 인터프리터처럼 고급언어를 기계어로 번역하는 것이 아니라 미리 변경해놓기에 빠른 것인데 이는 아래 예시를 보면 훨씬 이해하기 수월해진다.

function sum () {
    let result = 0
    for (let i = 1 ; i <= 10 ; i++){
        result += i;
    }
    return result;
}
sum() // for loop.. -> 55
sum() // for loop.. -> 55
sum() // for loop.. -> 55

// compile 결과
sum() = 55
sum() = 55
sum() = 55

이러한 코드가 있다고 할때 컴파일 과정을 거친 sum 함수의 결과값은 미리 기계어로 번역되기에 실제 실행할 필요없이 미리 정해져있다. 반면 인터프리터는 한줄한줄 실행해 나가는 방식이기에 sum 를 만나게 되면 일일이 실행하여 for 문을 거쳐야 비로소 결과가 도출된다.

이를 통해 컴파일 언어가 인터프리터 언어보다 좋은 성능을 보이는지 확인해보았다.

자바스크립트의 컴파일

다시 돌아와 V8 엔진에 의해서 어떻게 자바스크립트도 컴파일과정을 거치는지 알아볼 차례이다. V8 엔진은 기존의 Parser를 거쳐 AST로 변환된 내용을 인터프리터에게 전달하는 과정에 덧붙여 자바스크립트 변환과정을 진행한다.

위 그림에서 자바스크립트가 Parser, AST, Interpreter를 거쳐 ByteCode로 변모하는 것은 V8 엔진이 등장하기 전까지의 JS의 모습이다. 이에 추가적으로 Profiler 라는게 등장한다. 이 Profiler 는 인터프리터를 관찰하며 실행되는 코드를 계속해서 모니터링 한다. 모니터링하는 과정에 코드내에 반복 실행되는 것이 있다면 이를 컴파일러에게 넘겨 실시간으로 컴파일 하도록 한다. 이를 통해 최적화된 바이트 코드를 생성해낸다. 이전의 코드 예시에서 sum 함수처럼 반복해서 진행되는 여지가 있는 코드가 컴파일의 대상이 되겠다.

이처럼 필요할때 마다 컴파일 하는 컴파일러를 JIT(Just-In-Time) 컴파일러라고 부른다. 또한 필요할 경우 Decompile 과정을 진행하는데 이는 컴파일러가 판단할때 컴파일하는게 좋다고 판단했던 것이 잘못되었음을 알고 되돌리는 과정이다. 이는 컴파일 하는 비용을 줄이기 위함이라고 한다.

자바스크립트는 Compiler / Interpreter 언어다?

이제 이 질문에 대답할 수 있는 차례가 왔다. 정답은 살펴본것 처럼 둘다에 해당한다. 기본적으로는 Interpreter 언어로서의 성질을 가지지만, 성능상의 최적화를 위해 Compiler 언어의 특성도 같이 가진다.

🌈 출처 및 참고자료

자바스크립트 코드 실행 동작 원리: 엔진, 가상머신, 인터프리터, AST 기초

컴파일이란 무엇이며, 자바스크립트는 인터프리터 언어인가?

JavaScript, 인터프리터 언어일까?

해당 포스트는 Context API에 대한 이해를 요구합니다. Context API에 대해 처음이시라면 velopert님의 포스트를 참고해주세요.

React 에서는 전역 상태 관리를 위하여 자체적으로 ContextAPI 를 제공해준다.

ContextAPI 를 적절히 이용하면, Props Drilling을 이용해 Props를 전달해야했던 불편함은 해소되고 불필요한 Props 공유를 막을 수 있어 매우 좋은 도구중 하나이다. 간단하게 카운터 앱에서 카운트 숫자와 카운트를 증가하는 Dispatch 함수를 공유하는 context를 정의해보자.

🎈counterContext 정의 해보기

• App.tsx

import { useState, createContext, Dispatch, useContext } from 'react';
import './App.css';
import Counter from './components/Counter';
import DisplayCount from './components/DisplayCount';

interface counterContextValue {
  count: number;
  setCount: Dispatch<number>;
}

export const counterContext = createContext<counterContextValue | undefined>(undefined);

export const useCounterContext = () => {
  const context = useContext(counterContext);
  if(!context){
    throw new Error('useCounterContext must be used within a CounterContextProvider');
  }
  return context;
}

function App() {
  const [count, setCount] = useState<number>(0);
  return (
    <div className="App">
      <counterContext.Provider value={{count, setCount}}>
        <DisplayCount/>
        <Counter/>
      </counterContext.Provider>
    </div>
  );
}

export default App;

• components/Counter.tsx

import { useCounterContext } from "../App";

export default function Counter() {
    const { count, setCount } = useCounterContext();

    return (
        <div>
            <button onClick={() => setCount(count + 1)}>
                Click me
            </button>
        </div>
    );
}

• components/DisplayCount.tsx

import { useCounterContext } from "../App";

export default function DisplayCount ()  {
    const {count} = useCounterContext();
    return <p>You clicked {count} times</p>;
}

간단하게 App.tsx 카운트 숫자와 카운트를 증가시키는 Dispatch 함수를 담는 counterContext 를 정의하고 이를 Counter 라는 컴포넌트와 DisplayCount 라는 컴포넌트에게 Context API 를 통해 카운트 숫자와 증가 함수를 전달시키는 방식이다. 여기서 기존과는 다른 방식이 약간 존재한다.

우선 타입스크립트에서 createContext 를 하려고하면 초기화 할때 기본값을 넘겨주어야 할텐데 아래의 코드를 이용할 경우 불필요한 기본값을 정의할 필요없이 undefined 로 초기화 할 수 있다.

우선 타입스크립트에서 createContext 를 하려고하면 초기화 할때 기본값을 넘겨주어야 할텐데 아래의 코드를 이용할 경우 불필요한 기본값을 정의할 필요없이 undefined 로 초기화 할 수 있다.

export const counterContext = createContext<counterContextValue | undefined>(undefined);

하지만 이 상태로 바로 Counter 컴포넌트에서 Context를 사용하려고 하면 다음과 같은 타입 오류가 발생한다.

이는 Counter 컴포넌트 입장에서는 counterContext 에서 넘어오는 값이 counterContextValue | undefined 로 정의 되어져 있고 둘 중 어느 타입이 올지 정확히 알 수 없기 때문이다. 여기서 Counter 컴포넌트는 counterContext 로 부터 타입이 counterContextValue 인 값만 받아오면 되기 때문에 타입가드를 적절히 활용하여 특정 타입만 오도록 타입을 제한하면 될 것이다.

export const useCounterContext = () => {
  const context = useContext(counterContext);
  if(!context){
    throw new Error('useCounterContext must be used within a CounterContextProvider');
  }
  return context;
}

이를 위해 위와 같은 커스텀 훅을 도입하게 되면 Counter 컴포넌트는 undefined 를 제외한 값들을 받아올 수 있게 된다. 뿐만 아니라 불필요하게 useContext 훅과 counterContext 를 import 할 필요없이 useCounterContext 만 import하면 counterContext 를 사용할 수 있게되어 코드량도 줄일 수 있다!

import { useCounterContext } from "../App";

export default function Counter() {
    const { count, setCount } = useCounterContext();

    return (
        <div>
            <button onClick={() => setCount(count + 1)}>
                Click me
            </button>
        </div>
    );
}

🧐 기존 context 사용 방법의 문제점들

import { useState, createContext, Dispatch, useContext } from 'react';
import './App.css';
import Counter from './components/Counter';
import DisplayCount from './components/DisplayCount';

interface counterContextValue {
  count: number;
  setCount: Dispatch<number>;
}

export const counterContext = createContext<counterContextValue | undefined>(undefined);

export const useCounterContext = () => {
  const context = useContext(counterContext);
  if(!context){
    throw new Error('useCounterContext must be used within a CounterContextProvider');
  }
  return context;
}

function App() {
  const [count, setCount] = useState<number>(0);
  return (
    <div className="App">
      <counterContext.Provider value={{count, setCount}}>
        <DisplayCount/>
        <Counter/>
      </counterContext.Provider>
    </div>
  );
}

export default App;

앞서 봤던 App.tsx 다시 한번 확인해보자. 크게 두가지 문제점들이 있다. 우선, counterContext 를 정의하기 위해 타이핑을 위한 interface 선언, createContext 를 통해 context를 생성하는 부분, 편의성을 위해 정의한 커스텀 훅 등 App.tsx 파일 내부에 너무 많은 코드들이 작성되어 있다. App.tsx 내부에 여러 컴포넌트들을 추가하면서 코드 길이가 길어진다면 읽기가 매우 힘들어질 것이다.

import { useCounterContext } from "../App";

export default function Counter() {
    const { count, setCount } = useCounterContext();

    return (
        <div>
            <button onClick={() => setCount(count + 1)}>
                Click me
            </button>
        </div>
    );
}

또한 이를 counterContext 사용하기 위해 App.tsx와 Counter.tsx 서로가 import 하게 되는 순환형 참조가 일어나게 된다. 이를 방지 하기 위해서는 기존의 context 사용 방법을 개선해야될 필요가 있는데 이는 바로 context 자체를 컴포넌트화 하는 것이다.

🚧 Context를 컴포넌트화 하기

• components/counterContext.tsx

import { createContext, useState, ReactNode, Dispatch, useContext } from "react"

interface counterContextValue {
  count: number;
  setCount: Dispatch<number>;
}

const counterContext = createContext<counterContextValue | undefined>(undefined);

const CounterProvider = ({children}: {children: ReactNode}) => {
    const [count, setCount] = useState<number>(0);
    return (
        <counterContext.Provider value={{count, setCount}}>
            {children}
        </counterContext.Provider>
    );
}

const useCounterContext = () => {
    const context = useContext(counterContext);

    if(!context){
        throw new Error('useCounterContext must be used within a CounterContextProvider');
    }
    return context;
}

export {CounterProvider, useCounterContext};

기존의 context 관련 코드들을 모두 하나의 컴포넌트로 담는 것이 핵심이다. 또한 이를 counterContext 의 공급책인 counterContext.Provider 를 사용하는 대신 이를 포함하는 컴포넌트인 CounterProvider 를 정의하여 좀 더 간결하게 사용할 수 있도록 할 수 있다. 아래처럼 말이다.

• App.tsx

import './App.css';
import Counter from './components/Counter';
import {CounterProvider} from './components/counterContext';
import DisplayCount from './components/DisplayCount';

function App() {
  return (
    <div className="App">
      <CounterProvider>
        <DisplayCount/>
        <Counter/>
      </CounterProvider>
    </div>
  );
}

export default App;

• DisplayCount.tsx

import { useCounterContext } from "./counterContext";

export default function DisplayCount ()  {
    const {count} = useCounterContext();
    return <p>You clicked {count} times</p>;
}

• Counter.tsx

import { useCounterContext } from "./counterContext";

export default function Counter() {
    const { count, setCount } = useCounterContext();

    return (
        <div>
            <button onClick={() => setCount(count + 1)}>
                Click me
            </button>
        </div>
    );
}

기존에는 Context API 를 사용하면서 아쉬웠던 점이 코드가 굉장히 지저분해진다 였는데 이렇게 컴포넌트화 하여 사용하니 코드도 깔끔해지면서 굉장히 사용하기 편리해졌다. Context API가 필요하다면 이런식으로 컴포넌트화 하여 사용하는 것을 추천한다!

🚩 출처와 참고자료

How to use React context effectively

velopert - 22. Context API 를 사용한 전역 값 관리

ISR과 On-demand revlidation을 이용하면 정적생성으로도 사용자에게 실시간으로 업데이트된 페이지를 제공할 수 있다.

🥏 기존의 렌더링 방식

일반적으로 NextJS를 활용하게 되면 크게 3가지 렌더링 방식을 사용할 수 있다.

• CSR (클라이언트 사이드 렌더링) : useEffect훅을 이용하거나, SWR 같은 상태관리 툴을 이용해 렌더링의 책임을 사용자에게 전가하는 것. 화면 로딩이 사용자 눈에 보여 사용자 경험을 감소시키는 단점이 있다

• SSR (서버사이드 렌더링) : 렌더링의 책임이 프론트엔드 서버에게 주어지며, 웹사이트 사용자가 접속할때마다 새로운 페이지를 생성해내는 방식. 매번 최신 정보를 유지해야한다면 좋은 방식이긴 하지만, 성능상 이슈가 있고 화면 깜빡임 현상이 있다.

• SSG (정적 생성) : 렌더링의 책임이 역시 프론트엔드 서버에게 주어지지만, 프론트엔드 build 시간에 미리 화면에 대한 HTML을 미리 생성하여 사용자에게 미리 만들어진 화면을 제공한다. 이를 통해 성능상의 이점은 챙길 수 있으나, 미리 생성된 페이지를 제공하는 방식 이기 때문에 페이지 내 데이터가 변화하더라도 변화된 내용들을 전혀 제공해주지 못한다.

이러한 상황 속에서 NextJS에서 성능상의 이점은 챙기면서도 변화된 내용에 대한 업데이트를 제공해줄 수 있는 방식이 바로 ISR(Incremental Static Regeneration) 방식이다. 오늘은 이 ISR 방식이 어떠한 구조로 이루어졌는지를 이해해보고 실제 사용해볼 것이다.

📡 ISR이란?

공식문서에 따르면 다음과 같이 작성되어 있다.

Next.js allows you to create or update static pages after  you’ve built your site. Incremental Static Regeneration (ISR) enables you to use static-generation on a per-page basis, without needing to rebuild the entire site. With ISR, you can retain the benefits of static while scaling to millions of pages.

즉, 정적생성으로 미리 만들어놓은 사이트들도 필요하다면 업데이트가 가능하다는 이야기이다. 이를 이용한다면 정적생성의 장점을 취하되 단점을 보완할 수 있게 되는 것이다. ISR은 기존의 정적생성 방식에 몇가지 옵션들을 추가하면 바로 적용이 가능하다.

function Blog({ posts }) {
  return (
    <ul>
      {posts.map((post) => (
        <li key={post.id}>{post.title}</li>
      ))}
    </ul>
  )
}

// This function gets called at build time on server-side.
// It may be called again, on a serverless function, if
// the path has not been generated.
export async function getStaticPaths() {
  const res = await fetch('https://.../posts')
  const posts = await res.json()

  // Get the paths we want to pre-render based on posts
  const paths = posts.map((post) => ({
    params: { id: post.id },
  }))

  // We'll pre-render only these paths at build time.
  // { fallback: blocking } will server-render pages
  // on-demand if the path doesn't exist.
  return { paths, fallback: 'blocking' }
}

// This function gets called at build time on server-side.
// It may be called again, on a serverless function, if
// revalidation is enabled and a new request comes in
export async function getStaticProps() {
  const res = await fetch('https://.../posts')
  const posts = await res.json()

  return {
    props: {
      posts,
    },
    // Next.js will attempt to re-generate the page:
    // - When a request comes in
    // - At most once every 10 seconds
    revalidate: 10, // In seconds
  }
}

export default Blog

위의 코드는 공식문서에서 제시하고 있는 ISR 예시이다. 우선 build 시간에 정적 생성할 경로들을 getStaticPaths 를 이용해 전달 받는데 기존과 다르게 여기서 fallback: 'blocking' 옵션이 추가되어 있다. fallback 옵션에 대한 자세한 설명은 공식문서에도 정리되어 있고 한국어로 더 잘 정리해놓은 내용이 있어 해당 블로그 링크로 설명을 대체한다. 따라서, 해당 예시에서는 fallback: 'blocking' 이기 때문에 build 시간에 만들어지지 않은 경로는 SSR처럼 요청시 새롭게 생성된다는 의미이다.

getStaticPaths 가 정적생성할 경로 id들을 제공해줬다면, getStaticProps 에서는 해당 경로들에 대해서만 정적생성을 진행한다. 여기서 revalidate: 10 옵션이 추가되어 있는데, 이는 해당 페이지로 어느 사용자가 진입한 이후 10초 후에 해당 페이지에 대해서 정적생성을 진행한다는 의미이다. 이때 정적 생성된 페이지를 통해 다음 사용자에게 업데이트된 내용이 제공된다. 간혹 일부 블로그들에서 다음과 같이 옵션을 설정하면, 매 10초마다 정적생성을 진행하는 것으로 설명이 되어있는데 이는 잘못된 이야기다. 아래의 그림을 보면 이해하기 조금 더 수월해진다.

사용자1이 해당 페이지에 진입하면 이때 부터 60초 동안은 어느 사용자가 들어오더라도 미리 생성해두었던 페이지를 제공해 준다. 이후 60초가 지나면 NextJS 백그라운드에서 해당 페이지의 업데이트가 이루어지고 이 업데이트가 완료되면 앞으로 새롭게 만들어진 페이지를 사용자에게 제공해주는 방식이다. 이를 통해 SSG 의 성능상 이점을 챙기면서도 사용자에게는 업데이트된 내용을 제공해줄 수 있다. 이제 부터는 어떻게 실제로 사용하는지 작은 실습을 통해 알아볼 것이다.

🕹 ISR 실습해보기

1. API 구성

이를 위해서는 간단한 백엔드 API와 NextJS 프로젝트가 필요한데 API는 json-server 를 이용해 간단하게 구동해볼 것이다. 이를 이용하면 json파일만으로도 간단하게 API를 구성해볼 수 있다.

우선, json-server 를 전역적으로 설치해준다.

npm i -g json-server

이후 db.json 라는 이름으로 파일을 하나 생성해준다.

{
  "books": [
    { "id": 1, "title": "book1", "description": "this is book1" },
    { "id": 2, "title": "book2", "description": "this is book2" },
    { "id": 3, "title": "book3", "description": "this is book3" },
    { "id": 4, "title": "book4", "description": "this is book4" },
    { "id": 5, "title": "book5", "description": "this is book5" },
    { "id": 6, "title": "book6", "description": "this is book6" },
    { "id": 7, "title": "book7", "description": "this is book7" },
    { "id": 8, "title": "book8", "description": "this is book8" },
    { "id": 9, "title": "book9", "description": "this is book9" },
    {
      "id": 10,
      "title": "book10",
      "description": "this is book10 which is last statically generated"
    }
  ]
}

그 다음 다음의 명령어를 이용하면 4000번포트에 API를 생성해 놓을 수 있다.

json-server --watch db.json --port 4000

이렇게 실행해놓으면 다음의 API가 자동으로 구성된다.

• http://localhost:4000/books - 모든 books를 조회
• http://localhost:4000/books/${id} - id인 book을 조회

2. NextJS 구성하기

• pages/books/index.tsx

export default function Books({ data }: BooksProps) {
  return (
    <>
      {data?.map(({ id, title, description }) => (
        <Link href={`/books/${id}`} key={id}>
          <div style={{ padding: "10px", cursor: "pointer", borderBottom: "1px solid black" }}>
            <span style={{ marginRight: "10px" }}>{title}</span>
            <span>{description}</span>
          </div>
        </Link>
      ))}
    </>
  );
}

export async function getStaticProps() {
  try {
    const { data } = await axios.get("http://localhost:4000/books");
    return {
      props: { data },
      revalidate: 6000,
    };
  } catch (err) {
    return {
      notFound: true,
    };
  }
}

• pages/books/[id].tsx

type GetSpecificBookResponse = {
  data: Book;
};

interface IdParams extends ParsedUrlQuery {
  id: string;
}

export default function SpecificBook({ data: { id, title, description } }: BookProps) {
  return (
    <>
      <div key={id}>
        <span style={{ marginRight: "10px" }}>{title}</span>
        <span>{description}</span>
      </div>
    </>
  );
}

export const getStaticPaths: GetStaticPaths = async () => {
  const { data } = await axios.get("http://localhost:4000/books");
  const paths = (data as Book[]).map(({ id }) => ({ params: { id: String(id) } }));
  return { paths, fallback: "blocking" };
};

export const getStaticProps: GetStaticProps = async (context) => {
  try {
    const { id } = context.params as IdParams;
    const { data } = await axios.get<GetSpecificBookResponse>(`http://localhost:4000/books/${id}`);
    return {
      props: { data },
      revalidate: 5,
    };
  } catch (err) {
    return {
      notFound: true,
    };
  }
};

위와 같이 구성한다면 사용자 진입 후 5초 뒤에 revalidate를 진행하여 해당 페이지의 업데이트된 내용을 제공한다.

3. 결과 확인하기

참고로 정적생성의 효과를 제대로 확인하려면 development로 실행하면 안되고 production으로 실행해야한다. 이는 development 모드로 실행할 경우 사용자가 진입할 때마다 getStaticProps가 실행되기 때문이다.

npm run build

npm run start

실행하고 나서 데이터 베이스에 해당하는 db.json 내용을 변경했을때 변화가 반영되는지 아래화면을 통해 확인해 볼 수 있다. 특정 경로의 데이터가 업데이트 되면, 일정 시간 이후 업데이트 된 내용이 반영되는 모습이다.

업데이트가 아니라 새로운 책 정보가 생성되는 경우, 일정 시간 이후 새로운 경로를 생성하는 것도 확인할 수 있다.

다만, 위에서 볼 수 있듯 갱신/생성 되는데 있어서 revalidate 옵션의 값만큼 딜레이가 발생하게 된다. 실제로 데이터가 업데이트 되었더라도, 일정시간동안은 사용자가 업데이트 되지 않은 내용을 확인하게 된다는 것이다. 또한 이러한 방식을 사용하게 될 경우, 실제 업데이트 여부와 관계없이 revalidate 가 이루어지기 때문에 다소 비효율적으로 프론트엔드 서버의 리소스가 이용되는 한계점이 있다. 이러한 한계점을 조금 극복할 수 있는 새로운 기능이 생겼는데 이는 On-Demand Revaliation 이다.

🍏 On-demand Revalidation

단어에서 추측해 볼 수 있듯, 필요할때에만 Revalidation을 진행하여 업데이트 시기를 효율적으로 설정할 수 있다. 그렇다면 어떻게 Revalidation이 필요한 때 인지를 프론트엔드서버가 알 수 있게 될까? 바로 NextJS 내 API를 이용해 실현해 낼 수 있다. 대략적인 과정은 다음과 같다.

1. 데이터베이스 내 데이터가 업데이트 된다.
2. 프론트엔드에게 API 통신을 통해 Revalidation 이 필요함을 알린다.
3. 이를 통해 업데이트가 필요한 페이지 컴포넌트들을 Revalidate를 한다.

이를 직접 실습해보자.

참고로 On-demand Revalidation은 안정화 버전이 next@12.2.0부터 제공되니 package.json의 next 버전을 꼭 확인하자. 맞지 않는다면 12.2.0버전 이상으로 설치하는 것이 요구된다.

• pages/api/revalidate-books.ts

import { NextApiRequest, NextApiResponse } from "next";

export default async function handler(req: NextApiRequest, res: NextApiResponse) {
  const { method, query, body } = req;

  if (method !== "POST") {
    return res.status(400).json({ error: "Invalid HTTP method. Only POST method is allowed." });
  }

  // Unauthorized access as invalid token
  if (query.secret !== process.env.SECRET_REVALIDATE_TOKEN) {
    return res.status(401).json({ message: "Invalid token" });
  }

  try {
    if (!body) {
      res.status(400).send("Bad reqeust (no body)");
      return;
    }

    const idToRevalidate = body.id;

    if (idToRevalidate) {
      await res.revalidate("/books");
      await res.revalidate(`/books/${idToRevalidate}`);
      return res.json({ revalidated: true });
    }
  } catch (err) {
    return res.status(500).send("Error while revalidating");
  }
}

pages 폴더 안에 api 폴더를 생성한 뒤 적절하게 api 경로를 생성한다. 위의 코드 내용을 대략적으로 설명하면,

• POST 요청이 아닌 경우 400에러를 발생시킨다.
• query의 secret값이 환경 변수 SECRET_REVALIDATE_TOKEN 과 일치하지않으면 Unauthorized 401에러를 발생시킨다. (.env 파일에 SECRET_REVALIDATE_TOKEN 값을 적절히 설정해주어야한다.)
• body 안에 Id 값이 없으면 400에러를 발생시킨다.
• 이러한 조건들을 통과한다면 /books 페이지와 /books/${id} 를 revalidate 시킨다.

이를 제대로 확인해보려면, 위에서 설정했던 revalidate 값을 크게해야 한다(예를 들어 6000). 혹은 revalidate 옵션을 생략하는 것도 가능한데 이는 아래 사진처럼 직접 revalidate 시켜주지 않는한 사이트가 자동으로는 갱신이 이루어지지 않는 형태이다.

서버를 실행한뒤 데이터를 업데이트 하고 적절히 API요청을 보내주면 아래처럼 잘 갱신됨을 확인할 수 있다.

API요청을 통해 revalidate가 필요함을 알림으로써 바로바로 갱신되는 것을 확인해 볼 수 있다. 다만, 이런식으로 수작업으로 API요청을 보내는 것은 매우 비효율적이기 때문에 Webhook을 이용하거나 백엔드에서 데이터 업데이트 이후 API요청을 보냄으로써 이를 자동화 할 수 있을 것으로 기대된다.

🚩 출처와 참고자료

https://github.com/tumetus/cooking-with-tuomo

Next JS Static Generation - fallback

📄 페이지 구성 방식 - SPA, MPA

본격적인 렌더링 방식을 알아보기 전에 웹어플리케이션을 페이지 구성 방식에 따라 크게 두가지로 나누어볼 수 있다.

SPA(Single Page Application)

페이지 변경 없이 하나의 페이지 안에서 어플리케이션이 구동되는 방식 - ex) React, Vue, Angular 등

MPA(Multi Page Application)

사용자에 상호작용에 따라 여러개의 페이지가 제공되는 웹어플리케이션 - ex) php, JSP 등

이러한 웹어플리케이션은 각자의 특징때문에 과거에는 각자에게 필요한 렌더링 방식을 사용해야했다. 나중에 제대로 설명할 것이지만 렌더링 방식은 크게 3가지로 아래와 같은데,

• CSR - Client Side Rendering : 클라이언트 측에서 렌더링을 하는 방식
• SSR - Server Side Rendering : 서버 측에서 렌더링을 하는 방식
• SSG - Static Site Generation : 빌드 타임에 미리 리소스들을 정적으로 생성하는 방식

이러한 렌더링 방식과 결합시켜 아래와 같은 구성으로 웹어플리케이션을 구성하였다.

하지만, 최근들어 다양한 기술들과 프레임워크가 등장하면서부터는 SPA 상에서도 SSR을 구성할 수 있게되었다. 지금까지 웹어플리케이션의 페이지 구성방식에 대해 알아봤다면 이제부터는 정말로 렌더링 방식에 대해 알아볼 차례이다.

🕹 CSR의 동작 과정과 특징

CSR은 클라이언트 측에서 리소스를 다운로드 받아 직접 렌더링에 관여하는 방식인데 다음의 특징들을 가진다.

• JS 다운로드 후 브라우저 측에서 동적 DOM 생성하고 나서야 렌더링이 완료되기 때문에 초기 로딩속도가 매우 느리다. 다만, 모든 요소가 다운로드 된 후 렌더링이 진행되기에 화면 깜빡임은 없다.
• 첫 렌더링 이후에는 일부 요소 변경 시 해당되는 리소스만 요청하면 되기 때문에 초기 로딩을 제외한 나머지 시기의 구동 속도는 매우 빠르다.
• 빈 뼈대 HTML과 JS경로를 제공하는 것 외에는 하는일이 없어 서버 측 부하는 다소 적다.
• 웹 크롤러 입장에서는 인덱싱 과정에서 빈뼈대 HTML을 읽어드리기 때문에 적절한 색인 작업이 불가능하다. 이는 검색어 상단에 노출시키도록 하는 작업인 검색엔진최적화(SEO)에 불리하다.

대표적으로 React 라이브러리를 이용한다면 아래와 같이 useEffect 훅을 이용해서 렌더링에 필요한 데이터를 백엔드로부터 불러오는 것이 대표적인 예이다.

useEffect(() => {
    axios
      .get('https://worldtimeapi.org/api/ip')
      .then((res) => {
        setDateTime(res.data.datetime);
      })
      .catch((error) => console.error(error));
  }, []);

📡 SSR의 동작 과정과 특징

SSR은 CSR 과 달리 서버가 HTML 뼈대와 JS 링크를 주는 것에 그치지 않고 직접 HTML페이지와 관련된 JS파일을 실행시켜 완성된 HTML과 브라우저 측에서 실행할 JS 파일링크를 넘기는 방식으로 렌더링을 진행한다. 이러한 SSR 방식은 다음의 특징들을 가진다.

• 초기 렌더링시 HTML 뼈대만이 아니라 렌더링이 완료된 HTML과 이후 실행될 자바스크립트 코드가 제공되어 웹 크롤러 입장에서는 더 상세하게 인덱싱이 가능하여 SEO(검색엔진 최적화)에 매우 용이하다.

• 이미 렌더링이 완료된 상태로 페이지가 제공되기 때문에 초기 구동속도가 빠르다. 다만, HTML과 관련된 JS 로직들이 모두 연결되기 전까지는 사용자의 상호작용이 불가능하다. 이러한 경우 TTV(Time To View) ≠ Time To Interact 인 상황이라고도 한다.

  • 참고로 SSR 과정에서 서버측에서 먼저 렌더링한 HTML 파일이 전송된 후 이후에 클라이언트 측에서 실행할 JS가 다운로드되어야 웹페이지가 인터렉션이 가능해지는데 이러한 과정을 Hydration 이라고 한다.

• 또한 서버가 매 요청시 필요한 리소스를 직접 만들어야하기 때문에 서버에 과부하가 생길 수 있다. 이러한 경우, 사용자가 페이지 최초 진입시 페이지가 보여지는데 오랜시간이 걸릴수도 있다.

CSR과 SSR의 특징들을 정리하여 장점과 단점으로 분리하면 다음과 같다.

🎱 CSR의 단점 개선

위에서 살펴보았던 CSR 단점들은 다음의 해결책들을 통해 어느정도 해소될 수 있다.

• 초기 진입시 느린 로딩 속도 개선

  • Code-splitting - SPA는 초기 실행시에 필요한 웹 리소스를 다운받는 특징이 있다. 이를 해소하기 위해 일부 리소스들에 대해서 lazy loading 을 적용하여 한번에 다운로드 받지 않도록 하는 방법이 있다. 리액트에서는 React.lazy와 Suspense 컴포넌트를 활용해 일부 리소스를 필요할 때 import 시킴으로써 최적화할 수 있다.

      const OtherComponent = React.lazy(() => import('./OtherComponent'));
    
      function MyComponent() {
        return (
          <div>
            <Suspense fallback={<div>Loading...</div>}>
              <OtherComponent />
            </Suspense>
          </div>
        );
      }

    Code splitting 에 대해서 자세하게 알아보고싶다면 아래를 참고하길 바란다.

    Code-Splitting(코드 스플릿팅)

  • Tree-shaking - 웹어플리케이션을 개발하다보면 다양한 모듈들을 설치해 사용하게 될텐데 이중에서 사용되지 않은 모듈들을 최대한 배제하는 기법이다. 나무를 흔들어서 죽은 나뭇잎들을 떨어뜨리는 데에서 유래 되었다고 한다.

      import * as util from '../utilFile';

    대표적으로 특정 파일에서 모듈을 위와 같은 방식으로 import 하게 될 경우, 사용하지 않는 모듈들도 같이 import 하게될텐데 이런식으로 불필요한 리소스가 누적되면 어플리케이션을 build 하면서 만들어지는 번들의 크기가 매우 커지게된다. 이로 인해 리소스를 로딩하는 시간을 지연시킬 수 있다. 이에 대한 자세한 설명은 아래를 참고하면 좋을것 같다.

    웹 성능 최적화를 위한 Tree Shaking 소개

• SEO 개선

  • 페이지 미리 렌더링함으로써 검색엔진에서 해당 웹어플리케이션을 인덱싱하기 용이하기 하면 SEO 가 잘 안되던 기존의 문제점을 해결할 수 있다. 이처럼 페이지가 미리 렌더링되도록 해놓는 작업을 Pre-rendering 이라고 한다.

• SSR/SSG를 부분 도입

  • 렌더링의 부담을 모두 Client 측으로 돌리는 것이 아니라 일부 Server 측에게도 부여하는 방식이다. 이를 통해 초기 로딩 속도를 크게 감소시킬 수 있다. 또한 이를 도입하면 프리렌더링도 해줄 수 있어 SEO 개선도 가능하다. 이제부터는 SSR/SSG를 도입하는 방법에 대해서 알아보고자 한다.

🥏 CSR + SSR/SSG 도입 방법

• 프레임워크 없이 도입

  Express, Nest 등으로 백엔드 라이브러리를 이용해 별도의 서버를 운영하는 방법 : 진입장벽이 높고, 서버 환경 구성이 백엔드에 익숙하지 않은 프론트엔드 개발자에게는 다소 어렵다는 단점이 있어 실현되기 어렵다.

• 프레임워크를 이용해 도입

  프레임워크를 이용하면 쉽게 SSR/SSG를 도입할 수 있는데 프론트엔드 라이브러리 별로 도입할 수 있는 프레임워크는 다음과 같다.

  • React - NextJS, Gatsby

  • Angular - Universal

  • Vue - Nuxt

    대표적으로 NextJS 를 이용해 SSR를 할 경우 다음과 같은 방식으로 특정 페이지에 대하여 SSR을 진행할 수 있다. getServerSideProps 라는 함수가 프론트엔드 서버측에서 미리 실행되어 data를 패치한뒤 이를 페이지 컴포넌트의 props로 넘기는 방식이다.

    function Page({ data }) {
    // Render data...
    }
    
    // This gets called on every request
    export async function getServerSideProps() {
    // Fetch data from external API
    const res = await fetch(`https://.../data`)
    const data = await res.json()
    
    // Pass data to the page via props
    return { props: { data } }
    }
    
    export default Page

다만, 프레임워크를 사용하게되면 당여히 프레임워크에 대한 이해가 필요하여 러닝커브가 존재하고 코드 복잡도도 상승하게 된다는 단점이 있다.

🧐 CSR, SSR, Universal(CSR+SSR)의 선택 기준

지금까지 렌더링하는 방식들의 특징들과 도입방법들에 대해서 알아보았다. 각각의 장단점들이 있으니 상황에 맞게 사용하는 것이 중요하다. 각 렌더링 방식에 대하여 사용해야될 경우를 특정해보면 다음과 같다.

• CSR이 선호되는 경우

  • 유저와의 상호작용이 많은 경우
  • 고객 개인 정보를 다뤄야 하는 페이지라 검색엔진 노출이 필요 없는 경우

• SSG/SSR이 선호되는 경우

  • 회사 홈페이지 처럼 홍보가 필요해 검색어 입력시 상위페이지에 존재해야함(SEO 필요)
  • 누구에게나 동일한 내용 노출
  • 자주 업데이트가 이루어지는 페이지 ⇒ SSR
  • 자주 업데이트가 이루어지지 않는다 ⇒ SSG

• Universal(CSR + SSR)이 선호되는 경우

  • 사용자에 따라서 페이지가 달라짐 ⇒ SSR/CSR를 적절히 혼용
  • 빠른 인터렉션이 중요한 경우 ⇒ 프리렌더링이 필요함 ⇒ SSR
  • 화면 깜빡임 X ⇒ 리소스를 다운받은 상태에서 렌더링이 이뤄져야함 ⇒ CSR
  • 검색어 상위 노출이 요구 ⇒ SEO 최적화 필요 ⇒ SSR

위의 내용을 참고하되 정해진 정답은 없으니 프로젝트의 상황에 맞게 렌더링 방식을 선택하는 것이 좋겠다.

🪢 같이 배워보면 좋은 키워드들

• Code-splitting
• Tree-shaking
• SEO(Search Engine Optimization)
• Hydration

🚩 출처 및 참고자료

[10분 테코톡] 🎨 신세한탄의 CSR&SSR

Client-Side v/s Server-Side Rendering: What to Choose When? - DZone Web Dev

Understanding Rendering in Web Apps: SPA vs MPA

이제부터는 Prettier와 ESLint가 적용되었다는 가정하에 Webstorm 환경에서 적용방법을 보여주도록 하겠다.

🦄 Prettier 플러그인 설치 및 설정

1. Prettier 플러그인 설치

Preferences > Plugins 선택 후 Prettier를 검색하여 설치한다. 맥북의 경우 왼쪽 상단 Webstorm을 선택하면 Preferences 메뉴를 확인할 수 있다. 아래는 설치가 끝난 후의 모습이다.

2. Prettier 경로 설정

Preferences 메뉴창에서 왼쪽 상단에 검색어로 Prettier 를 입력한 뒤 아래 사진 처럼 언어 및 프레임 > JavaScript > Prettier 를 선택한 뒤 Prettier 패키지의 경로를 현재 프로젝트의 node_modules 내 Prettier로 설정한다.

3. 저장시 Prettier 적용 설정

Preferences > Plugins 선택 후 File watchers를 검색하여 설치한다. 기본적으로 이미 설치되어 있을 수도 있다.

이후 Tools > File watchers(파일 감시기) 를 선택하여 Prettier 항목들을 추가해준다. 저장 시 Prettier가 적용되도록 하기 위함이다. 본 프로젝트에서는 Typescript 기반의 NextJS 프로젝트 이기 때문에, 3가지 확장자에 대해서 설정해줘야 한다. (*.tsx, *.ts, *.js)

파일 타입인 TypeScript JSX, TypeScript, Javascript 각각에 대해서 아래의 설정을 동일하게 적용해주면 된다. 파일타입 외에 설정해줘야 할 것은 첫번째로 변경 시 실행할 도구 중 다음의 항목들이다.

• 프로그램 : $ProjectFileDir$/node_modules/.bin/prettier
• 인수 : -write $FilePathRelativeToProjectRoot$
• 새로고침할 출력 경로 : $FilePathRelativeToProjectRoot$
• 작업 디렉터리 : 프로젝트의 루트 디렉토리

4번째 항목인 작업 디렉토리 항목은 현재 프로젝트의 루트 디렉토리를 적어주면 된다. 두번째로 고급 옵션 항목에는 편집한 파일을 자동 저장하여 감시기 트리거 항목을 체크해 주면 된다. 지금까지 말한 사항들을 적용하면 아래와 같다.

아까 말한대로 위 작업을 동일하게 하되 파일 타입만 바꿔서 적용해 주면 된다.

마지막으로 Code Cleanup(코드 정리) 을 해주게되면 적용이 완료된다.

이제 각 파일의 저장버튼을 누르면 Prettier가 포맷팅 하는 것을 확인할 수 있을 것이다.

👒 ESLint 설정 및 적용

다음은 ESLint 를 적용하는 방법이다.

Preferences 를 선택한 뒤 왼쪽 상단에 검색 키워드로 eslint 를 입력해준다. 여기서 설정해줘야 항목들은 다음과 같다.

• 수동 ESLint 설정을 체크
• ESLint 패키지에 현재 프로젝트 node_modules 에 설치된 eslint 경로를 명시
• 작업 디렉터리에 현재 프로젝트의 루트 경로를 명시
• 구성 파일 항목에 현재 프로젝트의 .eslintrc.js의 경로를 명시
• 저장 시 eslint —fix 실행 옵션 체크

항목들을 체크 하고 확인 버튼을 누른 뒤 다시 한번 Code Cleanup(코드 정리) 작업을 해준다.

이렇게 ESLint 설정 역시 끝나게 된다.

🚩 출처 및 참고자료

WebStorm 에서 ESLint + Prettier 자동 저장 설정 하기

ESlint설치, 실행법, webstrom에서 ESlint적용

프로젝트 개발을 위해서 NextJS + Typescript + Emotion 기반 템플릿을 만들면서 이에 대한 설명을 다룬 내용들을 공유하기 위해 이 포스트를 올립니다.

해당 포스트의 코드는 아래 레포지토리를 참고해주세요.

템플릿 기능 소개

본 템플릿은 아래의 기술 스택들을 포함하고 있습니다.

• NextJS
• TypeScript
• ESLint & Prettier (저장 시 포맷 자동 적용 + Google 스타일 가이드 반영)
• Husky (커밋 전 포맷 체크)
• Emotion
• Stylelint - 본 포스트에서 다뤘으나 코드에는 반영되지 않았습니다.

NextJS App 생성

$ npx create-next-app code-like-google 실행

$ cd code-like-google 실행

$ code . 실행

api 폴더 제거

app.js 제거

💎 TypeScript 적용(Google TS Guide 적용)

tsconfig.json 라는 이름의 빈 파일을 프로젝트에 생성

$ npm install --save-dev @types/react @types/node 실행

$ npm run dev 실행

자동으로 채워진 tsconfig.json 대신 아래의 내용으로 변경 (Google Style Guide 적용)

{
"compilerOptions": {
    "allowJs": true,
    "allowUnreachableCode": false,
    "allowUnusedLabels": false,
    "declaration": true,
    "esModuleInterop": true,
    "forceConsistentCasingInFileNames": true,
    "isolatedModules": true,
    "jsx": "preserve",
    "lib": ["dom", "dom.iterable", "esnext"],
    "module": "esnext",
    "moduleResolution": "node",
    "noEmit": true,
    "noFallthroughCasesInSwitch": true,
    "noImplicitReturns": true,
    "pretty": true,
    "resolveJsonModule": true,
    "skipLibCheck": true,
    "sourceMap": true,
    "strict": true,
    "target": "es2018"
  },
  "include": ["next-env.d.ts", "**/*.ts", "**/*.tsx"],
  "exclude": ["node_modules"]
}

🟣 ESLint 적용

ESLint statically analyzes your code to quickly find problems. Many problems ESLint finds can be automatically fixed. ESLint fixes are syntax-aware so you won't experience errors introduced by traditional find-and-replace algorithms.

ESLint 에 설정해둔 사항이 알아서 수정되도록 이후 부분에서 설정할 것임

npm install eslint --save-dev 실행

npx eslint --init

• 아래와 같이 질문들에 대해 답변 선택 (Google 방식 대로 eslint 적용)

    # Interactive
    ? How would you like to use ESLint? ...
    > To check syntax, find problems, and enforce code style

    ? What type of modules does your project use? ...
    > JavaScript modules (import/export)

    ? Which framework does your project use? ...
    > React

    ? Does your project use TypeScript? » Yes

    ? Where does your code run? ...
    √ Browser

    ? How would you like to define a style for your project? ...
    > Use a popular style guide

    ? Which style guide do you want to follow? ...
    > Google: https://github.com/google/eslint-config-google

    ? What format do you want your config file to be in? ...
    > JavaScript

    eslint-plugin-react@latest @typescript-eslint/eslint-plugin@latest eslint-config-google@latest eslint@>=5.16.0 @typescript-eslint/parser@latest
    ? Would you like to install them now with npm? » Yes

.eslintrc.json제거

• .eslintrc.js 를 아래와 같이 수정

    module.exports = {
      "env": {
        "browser": true,
        "es2021": true,
      },
      "extends": [
        "plugin:react/recommended",
        "google",
        "next/core-web-vitals", // next에서 제공; 이게 없으면 모든 파일에 React 모듈을 import 해야됨
      ],
      "parser": "@typescript-eslint/parser",
      "parserOptions": {
        "ecmaFeatures": {
          "jsx": true,
        },
        "ecmaVersion": "latest",
        "sourceType": "module",
      },
      "plugins": [
        "react",
        "@typescript-eslint",
      ],
      "rules": {
        "require-jsdoc": "off", // Google Guide로 인해 강제된 jsdoc 옵션 해제
        "quotes": ["error", "double"], // 문자열 들을 쌍따옴표로 감싸도록 강제
      },
    };

여기서 index.tsx 상에서 에러가 생기고 있다면, eslint가 잘 적용되고 있는 것

이후 index.tsx 에서 세미콜론이나 쌍따옴표가 없어 발생하는 에러를 없앤 뒤, $npm run dev 실행 확인

🔴 Prettier 적용하기

It removes all original styling and ensures that all outputted code conforms to a consistent style.

$ npm install --save-dev --save-exact prettier

여기서 —save-exact는 package.json에 정확한 버전(^4.0.0 말고 4.0.0 과 같은 형태로 설치)으로 prettier 설치 한다는 의미

$ npm install --save-dev eslint-config-prettier 실행

eslint-config-prettier 는 eslint와 prettier의 충돌을 막기 위해 설치

eslintrc.js 중 extends 항목에 prettier를 추가하도록 다음과 같이 수정

extends: ["plugin:react/recommended", "google", "prettier"],

.prettierrc 파일 생성 후 다음의 내용으로 채우기(필요한 옵션들은 찾아서 알아서 추가하기)

{
    "printWidth": 100,
    "semi": true,
    "singleQuote": false,
    "tabWidth": 2,
    "trailingComma": "es5"
}

⚠️  prettier 일부 옵션들은 eslint에서 설정한 옵션들과 충돌할 수 있으니 주의할 것.

ex) Google Style에서는 semi 콜론을 강제하고 있으므로, prettier에서 semi를 false 로 할 경우 충돌 날 수 있음

.prettierignore 와 .eslintignore를 추가하고 아래의 내용을 적용하기

.next
next-env.d.ts
node_modules
yarn.lock
package-lock.json
public

다음의 항목들은 prettier와 eslint의 규칙들을 적용 받지 않음.

🆚 VSCode Extension 설치하기(ESLint, Prettier)

다음의 두 Extension을 설치 한 뒤, VSCode를 껏다가 다시 켜기

📎  저장 시 Format 자동 적용 설정하기

프로젝트 루트 경로에 .vscode 추가하기

.vscode 폴더 안에 settings.json 파일 생성 후 아래의 내용으로 작성

{
    "editor.formatOnPaste": true,
    "editor.formatOnSave": true, 
    "editor.defaultFormatter": "esbenp.prettier-vscode",
    "editor.codeActionsOnSave": {
        "source.fixAll.eslint": true,
        "source.fixAll.format": true
    }
}

잘 적용된다면 포맷 적용 안된 파일을 저장할 시 아래처럼 prettier 에서 설정한 포맷에 맞게 자동 수정됨

🦊 Husky

Husky는 commit 이나 push 와 같은 Git 명령어를 시도할때 사용자가 설정한 규칙을 잘 지켰는지 확인하는 역할을 한다.

husky 초기화

아래 예시의 설정에서는 다음의 사항들을 확인한다.

• Code 상에 Prettier 관련 경고 사항들은 없는지 확인한다.
• Code 상에 ESLint 관련 경고 사항들은 없는지 확인한다.
• Code 상에 TypeScript로 컴파일 시 관련 에러는 없는지 확인한다.
• next build 를 통해 프로젝트 빌드시 정상적으로 되는지 확인한다.

package.json 이 존재하는 곳에서 다음의 명령어를 실행하여 husky 관련 설정을 초기화 한다.

npm install husky --save-dev

이렇게하게 되면 package.json에는 아래의 명령어 스크립트가 생성될 것이다.

{
    "scripts" : {
        "prepare" : "husky install",
        ...
    },
    ...
}

이후엔 아래 명령어를 실행하여 husky 관련 초기화를 진행한다.

npm run prepare

위와 같이 했을 때 오류가 발생한 경우

간혹 하나의 프로젝트에서 frontend 와 backend 로 나누어지고 package.json 역시 폴더별로 따로 관리되는 경우가 있다.

```bash
│   
├── frontend                     # 프론트엔드 폴더
│   
├── backend                      # 백엔드 폴더
│
└── .git                         # git 관련 파일
```

이 때문에 /frontend 나 /backend 디렉토리로 이동해 npm install husky -—save-dev 를 실행했을 것이다. 이때 에러가 발생하게 될텐데 이는 husky 가 git과 연동되기 위해서는 .git 폴더와 같은 디렉토리 안에서 초기화 되어야 하기 때문이다. 따라서 앞서 생성된 package.json 의 명령어를 다음의 명령어로 변경해 주어야 한다.

  {
    // .git가 있는 root 디렉토리로 이동후 실행
    "prepare": "cd .." && husky install 
  },

한편 위와 같이 frontend 와 backend 가 나뉘어져 있는 프로젝트의 경우라면 적용해야될 husky 작업이 다를 것이다. 이처럼 디렉토리 별로 다른 husky 를 생성하려면 한번 더 변형이 필요하다. 가령 frontend 만을 위한 husky 를 생성하려면 아래의 명령어로 바꾸면 된다.

{
    "prepare": "cd .." && husky install frontend/.husky
}

이는 frontend 의 폴더에만 husky를 초기화하겠다는 의미이다. 이렇게 수정해 준 뒤 npm run prepare 를 실행하면 정상적으로 초기화 된다.

Husky와 연동할 명령어 작성

husky 와 연동해서 사용할 명령어를 생성하기 위해 package.json의 scripts를 아래와 같이 수정한다.

"scripts": {
    "dev": "next dev",
    "build": "next build",
    "start": "next start",
    "check-types": "tsc --pretty --noEmit",
    "check-format": "prettier --check .",
    "check-lint": "eslint . --ext ts --ext tsx --ext js",
    "format": "prettier --write .",
    "test-all": "npm run check-format && npm run check-lint && npm run check-types && npm run build",
    "prepare": "husky install"
  },

• check-types  : 타입스크립트의 [tsc](https://www.typescriptlang.org/docs/handbook/compiler-options.html) CLI 명령어를 실행한 뒤 그 결과 존재하는 warnings/errors를 출력한다.

• check-format  : Prettier로 하여금 모든 파일에서 .prettierrc 에서 명시한 규칙들이 잘 적용되었는지 확인하도록 한다. (단, .prettierignore 에 명시된 파일 이름들은 제외)

  

• check-lint : ESLint 로 하여금 Linting과 관련된 에러나 경고들을 표시한다.
• format : Prettier 로 하여금 자동으로 포맷팅을 적용하도록 함.
• test-all : 위에서 명시했던 모든 명령어들을 실행하도록 한다.
• **prepare** 는 husky 관련 설정들이 Git hooks에 연동하도록 함.

Git-hook 작성하기

이러한 명령어들이 Git 의 명령어와 연동하도록 작성하는 것이 Hook이다. 작성할 수 있는 Hook들은 아래와 같다.

가령 Commit 이전에 특정 명령어들이 연동되도록 pre-commit 훅을 생성할 수 있다. 또한 Push 이전에 특정 명령어들이 실행되어 모두 만족할때에만 push 가 이뤄지도록 구성할 수 있다.

pre-commit 훅 작성 예시

.husky 폴더 안에 pre-commit 이란 파일을 생성한다. 이후 해당 파일에 연동할 명령어와 실패시 실행할 명령어들을 작성한다. 참고로 일반적인 명령어 형식은 아래와 같다.

npm run format || # hook과 연동할 명령어
(
    echo 'Failure of formatting' # 실패 시 띄울 메세지
    false;
)

아래는 pre-commit 훅을 작성하는 예시이다. 아래와 같이 작성할 경우 commit 이루어지기 전에 formatting, linting, type checking, build 를 진행한다.

#!/bin/sh
. "$(dirname "$0")/_/husky.sh" # 이부분을 파일 앞에 붙여주는게 필요하다(아마도?)

echo '🏗️👷 Styling, testing and building your project before committing'

# Check Prettier standards
npm run check-format ||
(
    echo '🤢🤮🤢🤮 Its F**KING RAW - Your styling looks disgusting. 🤢🤮🤢🤮
            Prettier Check Failed. Run npm run format, add changes and try commit again.';
    false;
)

# Check ESLint Standards
npm run check-lint ||
(
        echo '😤🏀👋😤 Get that weak s**t out of here! 😤🏀👋😤 
                ESLint Check Failed. Make the required changes listed above, add changes and try to commit again.'
        false; 
)

# Check tsconfig standards
npm run check-types ||
(
    echo '🤡😂❌🤡 Failed Type check. 🤡😂❌🤡
            Are you seriously trying to write that? Make the changes required above.'
    false;
)

# If everything passes... Now we can commit
echo '🤔🤔🤔🤔... Alright... Code looks good to me... Trying to build now. 🤔🤔🤔🤔'

npm run build ||
(
    echo '❌👷🔨❌ Better call Bob... Because your build failed ❌👷🔨❌
            Next build failed: View the errors above to see why. 
    '
    false;
)

# If everything passes... Now we can commit
echo '✅✅✅✅ You win this time... I am committing this now. ✅✅✅✅'

Hook을 작성했는데 git 명령어와 연동이 안되는 경우

이는 pre-commit 이라는 파일에 실행권한이 없어서 git 명령어가 실행됐음에도 같이 실행되지 않는 경우일 것이다.

$ ls -al .husky

total 8
drwxr-xr-x   4 yangseungchan  staff  128 10 26 20:01 .
drwxr-xr-x  16 yangseungchan  staff  512 10 26 19:57 ..
drwxr-xr-x   4 yangseungchan  staff  128 10 26 19:57 _
-rw-r--r--   1 yangseungchan  staff  157 10 26 20:08 pre-commit # 실행 권한이 빠져있다.

이를 해결하기 위해서는 아래의 명령어를 실행하여 .husky 폴더 내 파일들이 실행 권한을 갖도록 해야한다.

$ chmod ug+x .husky/*

실행 시 다음과 같은 결과가 나올 것이다.

1) 정상적인 경우

$ git commit -m "[Add] Husky setting"
🏗️👷 Styling, testing and building your project before committing

> next-ts-plate@0.1.0 check-format
> prettier --check .

Checking formatting...
All matched files use Prettier code style!

> next-ts-plate@0.1.0 check-lint
> eslint . --ext ts --ext tsx --ext js

> next-ts-plate@0.1.0 check-types
> tsc --pretty --noEmit

🤔🤔🤔🤔... Alright... Code looks good to me... Trying to build now. 🤔🤔🤔🤔

> next-ts-plate@0.1.0 build
> next build

info  - Checking validity of types  
info  - Creating an optimized production build  
info  - Compiled successfully
info  - Collecting page data  
info  - Generating static pages (3/3)
info  - Finalizing page optimization  

Page                                       Size     First Load JS
┌ ○ /                                      6.26 kB        82.1 kB
├   └ css/955229c28454e75a.css             668 B
└ ○ /404                                   193 B            76 kB
+ First Load JS shared by all              75.8 kB
  ├ chunks/framework-1f10003e17636e37.js   45 kB
  ├ chunks/main-fc7d2f0e2098927e.js        28.7 kB
  ├ chunks/pages/_app-02d0f4839caa4a8e.js  1.36 kB
  └ chunks/webpack-69bfa6990bb9e155.js     769 B

○  (Static)  automatically rendered as static HTML (uses no initial props)

✅✅✅✅ You win this time... I am committing this now. ✅✅✅✅
[main e85d3dd] [Add] Husky setting
 10 files changed, 112 insertions(+), 58 deletions(-)
 rewrite .eslintrc.js (87%)
 create mode 100755 .husky/pre-commit

2) 에러가 발생하는 경우

🏗️👷 Styling, testing and building your project before committing

> next-ts-plate@0.1.0 check-format
> prettier --check .

Checking formatting...
All matched files use Prettier code style!

> next-ts-plate@0.1.0 check-lint
> eslint . --ext ts --ext tsx --ext js

/Users/yangseungchan/Desktop/SCG/next-ts-plate/pages/index.tsx
  2:8  error  'styles' is defined but never used  no-unused-vars

✖ 1 problem (1 error, 0 warnings)

😤🏀👋😤 Get that weak s**t out of here! 😤🏀👋😤 
                ESLint Check Failed. Make the required changes listed above, add changes and try to commit again.
husky - pre-commit hook exited with code 1 (error)

😃 Emotion 적용(SWC 기반) + _app.tsx 생성

1. Emotion 설치 및 Global CSS 적용하기

Emotion은 css-in-js기반으로 css를 적용하는 라이브러리 입니다. 이전에는 SSR이 지원되지 않아 babel 설정이 필요했지만, v10부터 SSR이 지원되어 설정이 따로 필요없어졌다.

To use emotion’s SSR with Next.js you need a custom Document component in pages/_document.js that renders the styles and inserts them into the <head> . An example of Next.js with emotion can be found in the Next.js repo This only applies if you’re using vanilla Emotion or a version of Emotion prior to v10. For v10 and above, SSR just works in Next.js.

아래의 명령어를 실행하여emotion 관련 모듈을 설치한다.

npm i --save @emotion/styled @emotion/react

emotion연동을 위해 next.config.js 을 아래와 같이 수정한다.

const nextConfig = {
  reactStrictMode: true,
  compiler: {
    emotion: true,
  },
};

module.exports = nextConfig;

Emotion 은 전역스타일링을 지원한다. 아래의 코드를 작성하여 Emotion 을 이용해 전역 스타일링 컴포넌트를 생성해 줄 수 있다. 전역 스타일도 적용하고, css-in-js 방식으로 적용하기 위해 아래와 같이 수정한다.

• styles/global.tsx

import { css, Global } from "@emotion/react";

export const globalStyles = (
  <Global
    styles={css`
      html,
      body {
        padding: 0;
        margin: 0;
        font-family: -apple-system, BlinkMacSystemFont, Segoe UI, Roboto, Oxygen, Ubuntu, Cantarell,
          Fira Sans, Droid Sans, Helvetica Neue, sans-serif;
      }

      a {
        color: inherit;
        text-decoration: none;
      }

      * {
        box-sizing: border-box;
      }
    `}
  />
);

• styles/home.tsx

import styled from "@emotion/styled";

export const Container = styled.div`
  min-height: 100vh;
  padding: 0 0.5rem;
  display: flex;
  flex-direction: column;
  justify-content: center;
  align-items: center;
  height: 100vh;
`;

• styles내의 css 파일들은 제거하기
• pages/_app.tsx

import createCache from "@emotion/cache";
import { CacheProvider } from "@emotion/react";
import { AppProps } from "next/app";

import { globalStyles } from "../styles/global";

const cache = createCache({ key: "next" });

const App = ({ Component, pageProps }: AppProps) => (
  <CacheProvider value={cache}>
    {globalStyles}
    <Component {...pageProps} />
  </CacheProvider>
);

export default App;

• pages/index.tsx

import Head from "next/head";
import { Container } from "../styles/home";

export default function Home() {
  return (
    <Container>
      <Head>
        <title>Create Next App</title>
        <meta name="description" content="Generated by create next app" />
        <link rel="icon" href="/favicon.ico" />
      </Head>
      Next TypeScript Template
    </Container>
  );
}

2. Emotion 기반 Theme 주입하기

이외에도 일부 css 공통 요소들을 Theme화 할 수도 있다. 아래의 코드를 작성하여 Theme를 생성해주도록 한다.

• styles/theme.tsx

import { Theme } from "@emotion/react";

const theme: Theme = {
  colors: {
    primiary: "hotpink",
  },
};

export default theme;

_app.tsx가 프로젝트의 진입점이기 때문에 Theme를 하위 컴포넌트나 페이지에서 사용할 수 있도록 Provider를 부여하기 위해 아래와 같이 해당 파일을 수정해준다.

• pages/_app.tsx

import createCache from "@emotion/cache";
import { CacheProvider, ThemeProvider } from "@emotion/react";
import { AppProps } from "next/app";

import { globalStyles } from "../styles/global";
import theme from "../styles/theme"; // 추가

const cache = createCache({ key: "next" });

const App = ({ Component, pageProps }: AppProps) => (
  <CacheProvider value={cache}>
    <ThemeProvider theme={theme}> 
      {globalStyles}
      <Component {...pageProps} />
    </ThemeProvider>
  </CacheProvider>
);

export default App;

주요 색상이 hotpink 인 테마를 제공하였으니 적용을 해보도록 할 것이다.

Title 이라는 컴포넌트를 생성해 주어 Theme를 적용해 볼 것이다. 컴포넌트를 만들때에는 컴포넌트의 리액트 로직과 CSS로직을 코드상에서 분리시켜 놓기 위해 아래와 같은 패턴으로 컴포넌트를 만들어줄 것이다.

index.tsx에는 리액트 로직의 내용이 들어가게 되고 styles.tsx에는 css 로직들이 들어가게 될것이다.

기존에 pages/index.tsx 에서 Next TypeScript Template 라는 글자를 Title 라는 컴포넌트로 만들것이다. 아래와 같이 코드를 추가해준다.

• styles/theme.tsx - Theme 선언하기

import { Theme } from "@emotion/react";

const theme: Theme = {
  colors: {
    primary: "hotpink",
  },
};

export default theme;

다만, 현재 프로젝트는 타입스크립트 기반이므로, Theme 객체의 타입을 사용자가 정의해주어야 한다. 그렇지 않으면 Theme에 어떤 속성이 있는지 타입스크립트는 이해하지 못한다. 따라서, 다음과 같이 프로젝트 루트 디렉토리에 Theme 객체에 어떤 속성이 있는지 부여해준다.

• emotion.d.ts

/* Theme 타입 설정 파일 */

import "@emotion/react";

declare module "@emotion/react" {
  export interface Theme {
    colors: {
      primary: string;
    };
  }
}

Theme에 속성을 추가적으로 부여하고 싶다면, emotion.d.ts 파일과 styles/theme.tsx 에 모두 해당 속성을 추가해 주어야 한다.

이제 선언된 테마를 적용해보기 위해 Title이라는 컴포넌트를 완성시키고 시작페이지에 렌더링할 것 이다. 아래의 코드를 따라해보자.

• components/Title/styles.tsx - 색상이 primary인 h1 컴포넌트

import styled from "@emotion/styled";

export const TitleText = styled.h1`
  color: ${(props) => props.theme.colors.primary};
`;

• components/Title/index.tsx - title이 prop인 컴포넌트

import { TitleText } from "./styles";

interface TitleProps {
  title: string;
}

const Title = ({ title }: TitleProps) => {
  return <TitleText>{title}</TitleText>;
};

export default Title;

• pages/index.tsx - Title 컴포넌트 렌더링

import Head from "next/head";
import Title from "../components/Title";
import { Container } from "../styles/home";

export default function Home() {
  return (
    <Container>
      <Head>
        <title>Create Next App</title>
        <meta name="description" content="Generated by create next app" />
        <link rel="icon" href="/favicon.ico" />
      </Head>
      <Title title="NextJS TypeScript Template" />
    </Container>
  );
}

결과는 다음과 같다.

또한 emotion의 css props 기능을 사용하려면 tsconfig.json을 아래와같이 수정해주어야 한다.

{
  "compilerOptions": {
    ...
    "jsxImportSource": "@emotion/react",
    ...
  },
  "include": ["next-env.d.ts", "**/*.ts", "**/*.tsx"],
  "exclude": ["node_modules"]
}

🌟Stylelint 적용하기 - 권장x, 코드에 없음

Stylelint를 emotion과 같은 css-in-js 환경에서 사용하기 위해 사용되는 @stylelint/postcss-css-in-js가 depreceated 되면서, css-in-js에서는 Stylelint를 사용하기 매우 까다로워졌다. 특히나, 자동 Fix 기능이 적용되지 않기 때문에, css에 통일된 규칙을 적용하고 싶은 경우에만 추가하는 것이 좋겠다.

앞서 🆚 VSCode Extension 설치하기(ESLint, Prettier) 에서 포맷팅을 적용하였지만, 이는 타입스크립트를 위한 포맷터라 내재된 emtion에 내재된 css코드는 포맷이 일정하지 않을 수 있다. 따라서 css코드의 포맷팅이 따로 필요하다. Stylelint는 css 정적 분석 도구 중 하나로 css 코드의 포맷팅을 지원한다.

우선 필요한 모듈들을 아래의 명령어를 실행해 설치한다.

npm install --save-dev stylelint stylelint-config-standard stylelint-config-prettier postcss-syntax @stylelint/postcss-css-in-js

설치한 모듈들이 어떤 기능을 하는지 살펴보면 다음과 같다.

• stylelint : stylelint를 사용하기 위한 기본 모듈
• stylelint-config-standard : stylelint에서 제시한 규칙들 중 일부를 모아 적용해 놓은 써드파티 모듈이다. 기본적으로 설정되있는 규칙들은 이곳을 참고할 것.
• stylelint-config-prettier : 포맷팅 시 stylelint 규칙과 prettier 규칙이 충돌하지 않도록 방지해주는 모듈이다.
• postcss-syntax, @stylelint/postcss-css-in-js : css-in-js 모듈에서 stylelint가 작동하도록 하는 모듈이다.

이후에는 루트 디렉토리에 .stylelintrc.js 라는 파일을 생성해 다음의 내용을 채워준다.

module.exports = {
  extends: ["stylelint-config-standard", "stylelint-config-prettier"],
  overrides: [
    {
      files: ["**/*.tsx"],
      customSyntax: "@stylelint/postcss-css-in-js",
    },
  ],
};

이후 작동되는지 확인하기 위해 package.json의 script를 다음과 같이 수정하고 실행해본다.

...
"scripts": {
    "lint-css": "stylelint --ignore-path .gitignore '**/*.(css|tsx)'",
}
...

이처럼 stylelint에 의해서 css 코드 내에 규칙에 맞지 않는 것들을 지적해 내는 것을 확인할 수 있다. 다만, function-no-unknown 의 규칙의 경우 emotion의 코드방식과 충돌하는 것이므로 불필요한 규칙에 해당한다. 이처럼, 자신에게 불필요한 규칙은 없애거나 필요한 규칙은 추가해줄 수 있다. 다음과 같이 말이다.

• .stylelintrc.js

module.exports = {
  extends: ["stylelint-config-standard", "stylelint-config-prettier"],
  overrides: [
    {
      files: ["**/*.tsx"],
      customSyntax: "@stylelint/postcss-css-in-js",
    },
  ],
  rules: {
    "function-no-unknown": null, // emotion styled와 충돌나서 배제
    "color-hex-length": "long", // 16진수 색상에 대해 표기법 지정
    "unit-allowed-list": ["em", "rem", "vh", "vw"], // 사용가능한 단위 특정하기
  },
};

참고로, stylelint가 알아서 잘못된 내용들을 수정하기 원할텐데 이 경우 다음의 명령어를 사용하면 된다.

npm run lint-css --fix

다만, AutoFix 기능은 극히 일부 규칙(Autofixable로 명시된 규칙)만 적용된다고 한다. 그래서 자동으로 고쳐주는 부분은 eslint나 prettier 만큼은 효과적이지 못하다. 공식 문서를 참고해 규칙들을 확인하며 적절히 커스텀하여 사용해야 한다.

🗂 폴더 구조 정리 및 import 개선

현재 프로젝트의 디렉토리 구조는 다음과 같이 되어있다.

이러한 상황에서 특정 컴포넌트나 파일을 import 해야하면 다음과 같은 상대경로를 작성해야 한다.

import Head from "next/head";
import Title from "../components/Title";
import { Container } from "../styles/home";

여기서 개선할 여지가 있는 두가지 문제점이 있다.

1. 프로젝트 구조가 너무 복잡하여 가독성이 떨어진다.

2. import 시 상대경로를 사용하여 역시 가독성이 떨어진다. (현재는 단순하지만 경로가 복잡해지면, import경로가 굉장히 보기 싫어진다)

이를 해결하기 위해 디렉토리 구조를 다음과 같이 수정할 것이다.

수정한 디렉토리 구조를 바탕으로, import 시 상대경로 대신 절대경로를 사용하도록 다음과 같이 tsconfig.json을 수정해준다.

{
  "compilerOptions": {
    ...
    "baseUrl": "src",
    ...
  },
  "include": ["next-env.d.ts", "**/*.ts", "**/*.tsx"],
  "exclude": ["node_modules"]
}

이렇게 수정하게 되면 import 경로가 얼마나 복잡하든 절대경로를 사용하여 다소 굉장히 깔끔해진다.

/* 적용 전
import Head from "next/head";
import Title from "../components/Title";
import { Container } from "../styles/home";
*/

// 적용 후
import Head from "next/head";
import Title from "@components/Title";
import { Container } from "@styles/home";

🚩 출처 및 참고자료

NextJS Style Guide: Prettier, ESLint, Husky and VS Code

NextJS with emotion with swc

Linter StyleLint

본 포스트는 [10분 테코톡] 💙 하루의 실행 컨텍스트 - YouTube 영상을 참고 및 요약하여 만들어졌습니다. 포스트 대신 위의 영상을 보시면 내용을 더 풍부하게 이해하실 수 있습니다.

Execution Context과 Lexical Environment

1. Environment Record(환경 레코드) - 식별자와 식별자에 바인딩된 값을 기록. 여기서 식별자(Identifier)란 코드에서의 변수나 함수를 나타낸다.

2. Outer Environment Reference(외부 환경 참조) - 바깥(이전) Lexcial Environment를 가리킨다.

🟡 Environment Record (feat. 호이스팅)

Lexical Environment의 구성 요소 중 하나인 Environment Record를 알아보면서 함께 호이스팅에 대해서도 알아보고자 한다.

Hoisiting (호이스팅)

자바스크립트 엔진에 의해 코드에서 선언문이 마치 최상단으로 끌어올려진 듯한 현상

Environment Record와 호이스팅에 대해 이해 하기 전에 잠~깐 자바스크립트 엔진이 코드를 어떻게 실행하는지 알아보고 넘어갈 것 이다.

🧐 JS 엔진의 코드 실행 단계

1. 생성 단계(Creation Phase) : 선언문만 우선 실행해서 Environment Record에 기록을 하는 단계
2. 실행 단계(Execution Phase) : 선언문 외 다른 코드들도 순차적으로 실행하는 단계. 이때에는 Environment Record를 참조하거나 업데이트 한다.

JS엔진의 실행 단계를 알아보았으니 이제 호이스팅에 대해 이해해 볼 수 있다. 호이스팅은 크게 3가지로 나뉘는데 첫번째는 Variable의 호이스팅, 두번째는 function expression, 세번째는 함수 선언의 호이스팅 이다. 각 호이스팅 별로 JS 엔진의 실행 단계와 함께 Environment Record가 어떻게 바뀌어 나가는지 살펴볼 것이다.

1. Variable 호이스팅

Case 1) var 호이스팅 - var로 선언된 변수의 호이스팅

Phase 1) 생성 단계

1. Call Stack에 전역 환경 상에서의 Environment Context를 생성

2. 선언문들만을 실행하여, Environment Record 만을 저장해둔다. 위의 예시에서는 TVChannel 이라고 선언된 변수를 읽어들인다. 이 경우 var형 변수이므로 undefined로 값을 초기화 해둔다.

Phase 2) 실행 단계

1. 선언문을 제외한 나머지 코드들을 읽어들인다. 첫번째 줄은 자바스크립트 엔진이 Call Stack을 참조하더라도 TVChannel이 "undefined"로 저장되어 있고 이를 출력한다.

2. 두번째 줄은 TVChannel에 "Netflix"값을 할당하는 코드이다. 이를 위해 전역 Context내의 Record속에 저장된 TVChannel의 값을 "Netflix"로 변경해준다.

3. 세번째 줄은 TVChannel을 출력하는 코드이므로 전역 Context 내의 Record를 참조하여 TVChannel의 값을 확인하고 이를 출력한다.

Case 2) const(혹은 let) 호이스팅 - const(혹은 let)로 선언된 변수의 호이스팅

console.log(TVChannel);

const TVChannel = "Netflix";

console.log(TVChannel);

Phase 1) 생성 단계

1. TVChannel이란 변수의 선언문을 실행한다. 이때 const형 변수이기에 전역 Context 내의 Record에는 TVChannel을 기록해두기는 하지만 var형인 경우와는 다르게 바로 초기화 되지 않는다.

Phase 2) 실행 단계

선언문을 제외한 나머지 코드들을 실행한다. TVChannel이란 변수를 출력하려고 시도하지만 Context내의 Record를 확인했을때 TVChannel은 어떠한 값도 띄지 않고 있기에 어떠한 값을 출력할 수 없어서 Reference Error가 발생하게 된다.

위와 같이 const(let)으로 선언했을때 선언하기 이전에 식별자를 참조할 수 없는 구역이 존재하게 되는데 이러한 구역을 일시적 사각지대(Temporal Dead Zone)이라고 한다. 이는 let, const로 선언한 변수의 경우 선언이 되었을 때 초기화는 따로 이루어지기 때문에 발생하게 된다.

2. Function Expression 호이스팅

Function Expression(함수 표현식)은 함수를 특정 변수에 담아두는 방식을 의미

Function Expression은 함수를 변수에 담아둔 형태이기에 JS엔진에게는 변수로 취급되므로 호이스팅은 변수와 동일한 방식으로 이루어진다. (var 함수표현식은 undefined로 초기화되고, let과 const는 어떤 값으로도 초기화 되지 않는다.)

3. Function 호이스팅

study();

function study(){
  // ...  
};

Phase 1) 생성 단계

Context 생성 후 Record 내부에 study라는 함수 객체를 생성 후 기록해 둔다. 이 때에는 JS엔진이 함수 선언과 동시에 함수 객체를 생성해 둔다.

Phase 2) 실행 단계

JS엔진이 Context내 Record를 참조하여 study 함수를 정상적으로 실행한다.

이처럼 함수 선언의 경우에는 선언과 동시에 함수객체가 생성되기 때문에 호이스팅이 일어나도 정상적으로 실행될 수 있다.

🟣 Outer Environment Reference

Outer Environment Refernece는 외부 환경을 참조하는 역할을 하며 이전에 실행된 Lexcial Environment를 가리킨다. 이는 식별자 결정 (Identifier Resolution)이 필요한 상황에서 사용된다. 아래의 상황을 생각해보자

다음의 코드를 예시로 들어보면, Call Stack에 전역 Execution Context가 생성된 뒤, goTo2F 함수가 실행되면서 goTo2F 함수에 대한 Execution Context가 생성된 것을 볼 수 있다. 이 상황에서 goTo2F 함수가 lamp 변수를 출력해야 한다면, 어떤 변수를 출력해야할까? 이 상황을 JS엔진은 Outer를 이용하여 해결하려고 한다.

let lamp = false;

function goTo2F() {
    let lamp = true;
    function goTo3F(){
        let pet = 'puppy';
        console.log(pet);  // puppy
        console.log(lamp); // ????
    }
    goTo3F();
}

goTo2F();

다음의 코드를 예시로 들어 JS엔진이 코드를 실행하면서 Outer Environment Reference를 어떻게 사용하는지 알아보려고 한다.

다음은 goTo2F 함수가 실행되는 시점을 가리킨다. 전역에 선언된 lamp와 goTo2F 함수가 전역 Execution Context 내부에 생성되어 있는 모습이다.

이 상황에서 goTo2F 함수를 실행하면 goTo2F 함수에대한 Execution Context를 생성한 뒤 새로 생성된 Exeuction Context의 Outer에는 전역 Lexcial Environment(Record + Outer)로 되돌아갈 수 있는 Outer를 생성해 둔다.

위의 그림은 goTo2F 함수가 실행되고 났을때의 상황을 보여준다. lamp 변수와 goTo3F 함수 객체가 Record에 기록된다. 이후에는 goTo3F 함수가 실행될 것이다.

위의 그림은 goTo3F 함수가 실행되는 시점을 나타낸다. 이전과 마찬가지로 goTo3F라는 새로운 함수가 실행되었으므로 새로운 Exeuction Environment를 생성하고 여기에는 goTo2F 함수의 Execution Environment로 돌아갈 수 있는 outer를 생성해 놓은 모습이다.

위 그림은 goTo3F가 본격적으로 실행되고 났을 때의 모습을 나타낸다. Record에 변수 pet이 기록된 모습이다. 이 상황에서 pet의 값을 출력해야 한다면, 현재 실행중인 Context(그림 상 제일 위에 위치한 Context)를 먼저 참조하여 pet의 값을 출력해낸다.

이외에 corona라는 변수를 출력해야 한다면 어떻게 될까? JS 엔진은 마찬가지로 현재 실행중인 Execution Context 부터 살펴보며 corona가 어떤 값을 가지는지 찾아본다. 여기서 현재 찾아보고 있는 Context 안에 corona 변수 값이 존재하지 않는다면 outer를 통해 이전 Execution Context로 이동하여 탐색과정을 진행한다. 이러한 과정을 전역 Exeuction Context에 도달할 때 까지 반복해 낸다. 결국 찾아내지 못한다면, corona 변수는 어떤 값인지 알 수가 없기에 Reference Error를 뿜어낸다.

다음은 lamp라는 변수의 값을 출력해야 되는 경우이다. 이 경우도 마찬가지로 Execution Context들을 찾아보다가 가운데 Execution Context에서 lamp의 값을 발견하게 되고 이 때에는 탐색 과정을 종료하게 된다. 한편, 이러한 경우 동일한 식별자인 전역 Execution Context에 위치한 lamp의 값은 알 수가 없게 되는데 이러한 상황을 변수 섀도잉(Variable Shadowing) 이라고 한다.

변수 섀도잉(Variable Shadowing)

동일한 식별자로 인하여 상위 스코프에서 선언된 식별자의 값이 가려지는 현상

이전에 선언된 코드의 Context들을 정리해보면 다음과 같다. 위에서 언급했듯 JS 엔진은 코드 실행 시 식별자의 값을 찾아내기 위해 Call Stack 내부의 선언된 Execution Context들을 Outer를 통해 둘러보는 과정을 진행한다. 이처럼 식별자의 값을 결정할 때 사용하는 Context 또는 스코프들의 연결 리스트를 스코프 체인이라고 하고, 식별자를 결정할 때 스코프를 이동하는 과정 자체를 스코프 체이닝 이라고 한다.

🟡 + 🟣 Execution Context

지금까지 Execution Context내 Lexcial Environment를 구성하는 Lexical Environment Record와 Outer Environment Reference의 의미와 그 기능에 대해 알아보았다. Execution Context의 기능을 한마디로 요약한다면 다음과 같다.

Exeuction Context(실행 컨텍스트)

코드를 실행하는데 필요한 환경을 제공하는 객체

여기서 환경이란 코드 실행에 영향을 주는 조건이나 상태를 의미한다.

이처럼 자바스크립트가 Execution Context라는 객체를 통해 식별자를 판별할 수 있는 것은 ES5이후 부터였다.

이전에는 함수가 어디에서 호출되느냐에 따라 스코프가 결정되는 동적 스코프 방식이였다면 ES5 이후로는 Execution Context를 이용해 함수가 어디에 선언되어있는지에 따라 스코프가 결정되는 정적 스코프 방식을 채택하게 되었다. 이를 통해 자바스크립트는 좀 더 효율적으로 식별자의 값을 결정해낼 수 있게 되었다.

🚩출처 및 참고자료

[10분 테코톡] 💙 하루의 실행 컨텍스트 - YouTube

👀 Intro

프론트엔드에서 백엔드서버로 api 요청을 보낼 때 흔히 볼 수 있는 에러들 중 하나이다.

개발하면서는 서로 오리진이 다르니 프론트나 백엔드에서 CORS 에러를 해결해주도록 하면 된다.

라고 대충 알고 넘어갔지만, 이번을 계기로 확실하게 이해하고 정확히 무슨 요인으로 발생하는지 알아보고자 한다.

📪 Origin

CORS 에러를 이해하려면 Origin 에 대해 알아볼 필요가 있다.

[출처] : 모던 자바스크립트 튜토리얼

위 그림에서 볼 수 있듯이 Origin 이란 Protocol, Hostname, Port를 한데 묶은 것을 의미한다. 다음의 간단한 예제를 통해 같은 오리진인지 아닌지 확인해보자

❓ 다음 중 http://localhost와 동일 Origin인 URL은 무엇일까?

• https://localhost

• http://localhost:80

• http://127.0.0.1

• http://localhost/api/cors

✅ 정답을 확인해봅시다.

1. 첫번째 URL은 프로토콜이 https로 다른 프로토콜을 가지고 있으므로 다른 Origin 으로 취급된다.

2. 두번째 URL은 포트번호가 80이라서 다른 오리진이라고 생각하겠지만 이는 잘못된 생각이다. 우선 http 프로토콜의 경우 포트번호가 생략될 경우 기본적으로 포트 80을 배정받는다고 한다. 따라서 두번째 URL은 동일한 Origin으로 취급된다. ([참고로 https 프로토콜의 경우 443 포트를 기본적으로 배정받는다.](http의 기본 포트가 80, https의 기본 포트가 443인 이유는 무엇일까? - 기계인간 John Grib))

3. 세번째 URL은 Hostname이 127.0.0,1 로 통상적으로 localhost 를 의미하는 IP주소이다. 따라서 같은 오리진으로 보일 수도 있다. 다만, 브라우저의 경우 에는 같은 오리진인지 판단할때 문자열 값 자체를 기준으로 판단하기 때문에, 다른 Origin 으로 판단 한다.

4. 네번째 URL의 경우 localhost뒤에 /api/cors 라는 pathname이 붙었을 뿐, 같은 Protocol, Hostname, Port를 가지기 때문에 같은 Origin으로 판단 한다.

⚠️ SOP(Same Origin Policy)

Origin에 대해 이해한 내용을 바탕으로 웹에서 규정되어 있는 SOP에 대해 알아볼 필요가 있다 공식문서에 따르면, SOP는 다음과 같이 정의된다.

동일 출처 정책(same-origin policy)은 어떤 Origin에서 불러온 문서나 스크립트가 다른 출처에서 가져온 리소스와 상호작용하는 것을 제한하는 중요한 보안 방식입니다. 동일 출처 정책은 잠재적으로 해로울 수 있는 문서를 분리함으로써 공격받을 수 있는 경로를 줄여줍니다.

즉 보안상의 이유로, 웹 상에서는 다른 Origin으로 부터 요청 받는 리소스 접근을 제한하는 정책이라고 볼 수 있다. 따라서 위의 URL들 중 첫번째와 세번째 URL이 http://localhost의 리소스에 접근하려 할 경우 SOP에 위반되어 리소스 접근에 제한 받는다. 이러한 상황은 프론트엔드와 백엔드 개발 중에 흔히 직면할 수 있는 상황이다.

예를 들어, 프론트엔드가 localhost:3000으로 개발 중인 상황에서, 백엔드 서버는 localhost:5000에서 호스팅 중인 상황이라면, 이 둘은 서로 포트번호가 달라 다른 Origin으로 취급되어 SOP에 위반되게 되는 것이다. 이러한 상황을 우리가 흔히 말하는 CORS 에러라고 하는 것이다. 그럼, 이렇게 Origin이 다른 상황에서는 어떻게 원하는 리소스에 접근할 수 있을까? 여기서 이제 CORS에 대해 알아갈 필요가 있는 것이다.

🌙 CORS(Cross Origin Resource Sharing)

MDN 공식문서에 따르면, CORS는 다음과 같이 정의된다.

교차 출처 리소스 공유(Cross-Origin Resource Sharing, CORS)는 추가 HTTP 헤더를 사용하여, 한 출처에서 실행 중인 웹 애플리케이션이 다른 출처의 선택한 자원에 접근할 수 있는 권한을 부여하도록 브라우저에 알려주는 체제입니다. 웹 애플리케이션은 리소스가 자신의 출처(도메인, 프로토콜, 포트)와 다를 때 교차 출처 HTTP 요청을 실행합니다.

즉, SOP에 위반 되는 상황 속에서도 리소스에 접근하려면, CORS 헤더를 도입하여 이러한 상황을 해결해야 한다. 여기서 CORS헤더를 도입한 경우는 아래와 같은 상황을 의미한다.

Origin이 https://foo.example인 클라이언트에서 https://bar.other 도메인의 리소스를 접근하는 시나리오를 생각해보자. foo.example에서 리소스를 호출하는 코드는 다음과 같다.

const xhr = new XMLHttpRequest();
const url = 'https://bar.other/resources/public-data/';

xhr.open('GET', url);
xhr.onreadystatechange = someHandler;
xhr.send();

이런식으로 리소스 접근 호출을 할 경우, 브라우저가 서버로 전송하는 내용의 헤더는 다음과 같다.

GET /resources/public-data/ HTTP/1.1
Host: bar.other
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:71.0) Gecko/20100101 Firefox/71.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Connection: keep-alive
**Origin: https://foo.example**

요청 헤더의 경우 어느 Origin에서 보내는 요청인지 항상 포함되어 있다. CORS가 도입된 서버가 리소스 요청에 보내는 응답은 다음과 같다.

HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 00:23:53 GMT
Server: Apache/2
Access-Control-Allow-Origin: *
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: application/xml

[…XML Data…]

눈여겨 봐야할 정보는 Access-Control-Allow-Origin 가 *로 설정되어 있으며 이는 어느 Origin에서든 bar.other의 리소스에 접근할 수 있다는 것을 의미한다. 특정 Origin만 접근할 수 있도록 하려면, 다음과 같이 헤더를 변경하면 된다. 아래는 https://foo.example이라는 오리진을 가진 URL만 접근할 수 있음을 의미한다.

Access-Control-Allow-Origin: https://foo.example

👂 CORS를 도입하는 방법

지금 까지는 CORS 에러에 대해서 알아봤다면 이제는 해결하는 방법에 대해서 알아보려고 한다. 이 문제를 해결하는 방법은 프론트엔드, 백엔드 양 측에게 모두 존재한다.

프론트엔드 - Proxy Server 도입

Proxy란 어떠한 대상의 기본적인 동작의 작업을 가로챌 수 있는 객체를 의미한다. 이를 이용한 Proxy Server는 서버와 클라이언트 사이에서 클라이언트가 자신을 통해 다른 네트워크 서비스에 간접적으로 접속할 수 있도록 하는 응용 프로그램을 의미한다.

[출처] : 면접을 위한 CS 전공지식 노트

위의 그림에서 볼 수 있듯, 프론트엔드 서버 말단에 프록시 서버를 도입하여, /api, /api2로 보내지는 요청의 Origin을 API 서버의 Origin과 동일하게 하여 SOP를 위반하지 않도록 할 수 있다.

리액트의 경우 http-proxy-middleware 모듈을 이용하여 이를 구현해 낼 수 있다.

const { createProxyMiddleware } = require('http-proxy-middleware');

module.exports = function(app) {
  app.use(
    '/api',
    createProxyMiddleware({
      target: 'http://localhost:5000',
      changeOrigin: true,
    })
  );
};

[출처] - https://create-react-app.dev/docs/proxying-api-requests-in-development/

위의 코드를 src 폴더안에 setupProxy.js라는 파일로 작성하면 리액트 서버에 프록시 서버를 도입할 수 있다고 한다.

백엔드 - (1) Access-Control-Allow-Origin 응답 헤더 추가

응답 헤더의 Access-Control-Allow-Origin 항목을 해당하는 Origin으로 설정해주면 CORS를 도입할 수 있다. Express의 경우는 다음과 같이 추가해 줄 수 있다.

app.use((req, res) => {
    res.header("Access-Control-Allow-Origin", "*"); // 모든 도메인 허용
    res.header("Access-Control-Allow-Origin", "http://localhost:3000"); // 특정 도메인 허용
});

다만 "*"를 이용해 모든 도메인을 허용해 놓는 것은 보안상 좋지 못하니 Origin을 특정해 주는 것이 좋다.

백엔드 - (2) CORS 미들웨어 사용하기

Express의 경우, cors 모듈을 사용하여 CORS를 도입할 수 있다.

import express from "express";
import cors from 'cors';

const app = express();

app.use(cors({ origin: [
  'http://localhost:3000',
  'https://nomalog.netlify.app'
]));

위와 같이 CORS를 설정한다면, localhost:3000과 nomalog.netlify.app라는 Origin에 대해 CORS를 허용할 수 있다.

🚩 출처 및 참고자료

교차 출처 리소스 공유 (CORS) - HTTP | MDN

동일 출처 정책 - 웹 보안 | MDN

[10분 테코톡] 🌳 나봄의 CORS - YouTube

React + Express | CORS 설정하기

Editor에 대한 공식 Github 문서에 따르면 크게는 두 가지 방법으로 적용할 수 있다고 나와있다.

1. Viewer를 직접 적용

2. Editor의 factory를 활용해 적용하는 방법

이번 포스트에서는 리액트 및 NextJS에서 적용하기 쉽게 하기 위해서 Viewer를 직접 적용하는 방법으로 할 것이다.(사실 Editor의 factory를 React 컴포넌트로 어떻게 적용하는지 몰라서이다..=_=)

공식 문서에 따르면 Viewer 모듈과 해당 css 파일을 불러오면 된다고 한다. 그래서 나도 이에 따라 컴포넌트 파일에는 Viewer를 불러오고 Viewer를 불러와야 하는 Page에는 dynamic import를 적용해 봤다.

또한 뷰어에 대한 공식문서에 따르면 Viewer는 내용값으로 HTML이 아닌 MarkDown 만을 받는다고 하니, 주의하도록 하자!!

Viewer Component

import Viewer from '@toast-ui/editor/dist/toastui-editor-viewer';
import '@toast-ui/editor/dist/toastui-editor-viewer.css';

const TestView = () => {
  return <Viewer height="600px" initialValue="# hello" />;
};

export default TestView;

Viewer Page

import dynamic from 'next/dynamic';

const Viewer = dynamic(() => import('../../../components/TestView/TestView'), {
  ssr: false,
});

const ProfessorStatus = () => {
  return (
    <Viewer />
  );
};

export default ProfessorStatus;

이대로 무난하게 잘 되는줄 알았으나... 에러가 발생하고 말았다.

분명 dynamic import를 적용했음에도 에러가 발생한 것 때문에 많이 절망적이었다... 그래도 공식 Github를 살펴보면서 해결의 실마리를 찾을 수 있었다.

우선 이전의 Editor 경우도 @toast-ui/react-editor 에서 import 해왔다는 점에서 @toast-ui/react-editor를 자세히 살펴보았다. 그리고 Viewer에 대한 코드를 살펴보니 아래 사항을 확인할 수 있었다.

import Editor from './editor';
import Viewer from './viewer';

export { Editor, Viewer };

이를 통해서 @toast-ui/react-editor 모듈에서 Editor와 Viewer 모두 import하는 것이 가능하다는 것을 확인할 수 있다. 이를 바탕으로 Viewer Component를 아래와 같이 수정해 봤다.

Viewer Component 수정!

import Viewer from '@toast-ui/react-editor';
import '@toast-ui/editor/dist/toastui-editor-viewer.css';

const TestView = () => {
  return <Viewer height="600px" initialValue="# hello" />;
};

export default TestView;

그러고 결과를 확인해보면 정상적으로 작동함을 확인할 수 있다!!

공식문서가 React와 NextJS에 대해서 적용하는 법에 대해 친절히 설명해 줬으면 이런 고생들을 하지 않았겠지만.. 이런 고생들을 하면서 많은 것들을 배운 기회가 된 것 같다. 이제 프로젝트 내 게시판 기능 구현에 한 단계 앞으로 나아간 것 같다!

이런 문제가 발생한 것은 바로 ToastUI Editor에서는 NextJS에서 적용되는 SSR(Server Side Rendering)을 지원하지 않기 때문이었다. 이러한 충돌을 막기 위해서는 해당 에디터를 dynamic하게 import할 필요가 있다. 위 블로그 링크에서 해결책을 확인할 수 있으니, 자세한 설명은 생략하겠다.

그런데 한 가지 문제가 있다. 정상적으로 적용된 에디터 페이지를 들어가보면, 잘 나오는데 에디터만 유독 느리게 나온다. 아마도 런타임에 로드를 해야 되는 것이다 보니 다른 요소들에 비해서 느리게 나오는 것 같다. 이를 완화 시키고자 dynamic import시 loading 옵션을 추가했다. Dynamic Import의 loading 옵션에 대한 자세한 설명을 보고싶다면 공식문서를 참고하기를 바란다.

Editor를 Dynamic import로 불러오는 부분

const PostEditor = dynamic(() => import('../PostEditor/PostEditor'), {
  ssr: false,
  loading: () => <EditorLoader />,
});

EditorLoader 컴포넌트

import CircularProgress from "@material-ui/core/CircularProgress";

import { makeStyles } from "@material-ui/core/styles";

const useStyles = makeStyles((theme) => ({
  loaderContainer: {
    height: "600px",
    width: "100%",
    border: `0.5px solid ${theme.palette.grey[400]}`,
    borderRadius: "4px",
  },
  loaderItem: {
    position: "relative",
    top: "50%",
    left: "50%",
  },
}));

const EditorLoader = () => {
  const classes = useStyles();
  return (
    <div className={classes.loaderContainer}>
      <div className={classes.loaderItem}>
        <CircularProgress color="primary" />
      </div>
    </div>
  );
};

export default EditorLoader;

EditorLoader의 구성요소 중 하나인 CircularProgress라는 요소는 material-ui에서 제공해주는 컴포넌트인 점을 참고하길 바란다. 꼭 위와 같이 material-ui를 적용할 필요 없이 적용한 editor의 크기로 자기 스타일에 맞는 Loader를 적용하면 된다.

위 사진에서 볼 수 있듯이 loading 옵션을 적용하니 Editor를 가져오는 동안 EditorLoader 컴포넌트가 그 자리를 차지하면서 이전과 다르게 에디터의 로딩을 기다리더라도 이질감은 덜 느껴진다.

원래는 Editor와 Viewer를 같이 다룰려고 하였으나 너무 길어진 관계로 다음글에서 Viewer 적용을 소개하려고 한다.