[TIL] Naver FE News 2024-02

[TIL] Naver FE News는 Naver FE 팀에서 매월 첫째주 수요일에 업로드하는 FE 관련 이슈들을 팔로우 하면서 관심있는 내용을 학습하고 정리하는 컨텐츠입니다. [ https://github.com/naver/fe-news ]

1. 2023 JavaScript Rising Stars

https://risingstars.js.org/2023/en#section-framework

2023 JavaScript Rising Stars

• 전체 프로젝트 부문: shadcn/ui, bun, Excalidraw
• 테스팅: Playwright, Storybook, puppeteer
• 스타일링: Stylex, unocss, tamagui
• 상태관리: Zustand, Jotai

2. JSON 표준의 흥미로운 역사

https://wormwlrm.github.io/2024/01/21/Standardization-of-JSON.html

숫자 1은 올바른 JSON 형식인가? - 재그지그의 개발 블로그

• 2001년, 대세 웹 데이터 저장 방식이었던 XML의 비효율성에 빡친(?) 더글라스 크락포드 형님이 만들었다.
• 2006년, 크락포드 형님이 HTTP 통신의 Content-Type에 application/json을 추가하는 제안을 작성한다. 이것이 바로 RFC 4627이고 JSON을 HTTP로 전송하기 위한 MIME 타입을 정의한 문서이다.
• 이 최초 정의에는 JSON에 객체 또는 배열만 올 수 있다고 쓰여 있다.
• 문제는 RFC 4627이 IETF(국제 인터넷 표준화 기구)의 공신력있는 상태를 갖기 위한 절차를 밟지 않고 그냥 발표 가능한 상태인 information 상태로 작성되었다는 것이다.
• 그러던 2011년 ECMA 인터내셔널에서 ES5.1에 JSON 스펙을 구현할 때, RFC 4627을 참고하라고 명시했다.
• 심지어 일부는 수정해서 쓰라고 얘기하는데 이 내용 중에 JSONObject나 JSONArray 외에도 JSONValue를 쓸 수 있다고 명시해버렸다.
• 2013년 ECMA 인터내셔널과 IETF의 JSON 표준화 경쟁은 본격화되었고 2013년 10월에 ECMA 404라는 JSON 형식에 대한 문서가 먼저 발표되면서 명목상으로 승자는 ECMA 인터내셔널이 가져갔다.
• 이 문서에서 JSON Values를 object, array, number, string, true, false, null로 명시했다.
• IETF에서는 2014년 3월 RFC 7159를 발표하면서 JSON의 최상위 레벨에 값(Values)이 나올 수 있고 이는 이전 버전의 JSON 사양과 다르다는 점을 주의하라고 명시했다.
• 2015년 발표된 ES6에는 RFC 4627을 참조하라는 표기가 아예 ECMA404를 참조하라는 것으로 변경되었다.
• 2017년 IETF의 새로운 JSON 표준인 RFC 8259와 ECMA 인터내셔널의 ECMA 404 개정판이 동시에 나오면서 '텍스트의 인코딩을 UTF-8로 유지한다.'는 내용을 추가했다.
• 두 조직간 표준을 서로 참조하고 일관성을 유지하기 위해 합의가 이루어진 것으로 보이며 이 개정사항 이후 현재(2024년 1월)까지 JSON 스펙은 유지되고 있다.

이 치열한 혈투의 현장 중심에 있었던 Google의 팀 브레이 형님의 분투기까지 궁금하다면 재그지그님의 원문을 읽어보세요!

3. React 서버 컴포넌트

https://www.freecodecamp.org/korean/news/how-to-use-react-server-components/

React 서버 컴포넌트를 사용해야 하는 이유와 방법

클라이언트(브라우저) 사이드 UI 라이브러리로서의 React

• React는 클라이언트 UI를 더 작고 독립적은 부분인 컴포넌트로 분해하고 구조화하는 것을 제안한다.
• React 컴포넌트에는 클라이언트 컴포넌트와 서버 컴포넌트가 있다.
• React 클라이언트 컴포넌트가 데이터를 서버로부터 받아와서 하위 컴포넌트에 전달하는 과정은 긴 지연을 동반한다.
• React가 생성한 클라이언트 컴포넌트는 아래 과정으로 렌더링 된다.
  • 1. HTML과 연결된 Javascript, CSS 및 이미지와 같은 에셋을 다운로드
  • 2. HTML 구조를 하이드레이트(Hydrate - HTML 구문 분석 + 이벤트 리스너 연결 + 스토어 데이터 가져오기)
• 위 과정을 위한 스크립트 + 종속성있는 외부 라이브러리로 인해 클라이언트 컴포넌트는 그 자체로 무겁다.

React Server Component (RSCs)

• RSC를 사용하면 데이터를 가져오는 로직을 서버로 이동하여 네트워크 호출 없이 데이터를 가져오도록 할 수 있다.
• 예시 코드

import { dbConnect } from '@/services/mongo'

import { addCourseToDB } from './actions/add-course'

import CourseList from './components/CourseList'

export default async function Home() {

  // MongoDB 연결
  await dbConnect();
  
  // db의 모델을 이용하여 모든 course를 얻는다.
  const allCourses = await courses.find();
  
  // 서버 쪽에서 콘솔이 찍힌다.
  console.log({allCourses})

  return (
    <main>
      <div>
        // 하위 컴포넌트에 클라이언트 컴포넌트를 반드시 갖는다.
        <CourseList allCourses={allCourses} />  
      </div>
    </main>
  )
}

• 이는 마치 Express와 같은 백엔드 코드를 보는 듯 하다.
• 서버 컴포넌트는 클라이언트 컴포넌트를 하위 컴포넌트로 포함하지만 클라이언트 컴포넌트는 서버 컴포넌트를 하위 컴포넌트로 포함할 수 없다.
• RSC의 한계
  • 1. RSC는 서버에 남아 있고 서버에서 렌더링됩니다. 따라서 사용자 인터렉션(이벤트 핸들러 또는 React Hooks)을 추가할 수 없습니다.
  • 2. local storage나 bluetooth, web USB와 같은 브라우저에서 제공하는 웹 API를 사용할 수 없습니다.
• 따라서 서버 컴포넌트는 단독으로 사용하는 것이 아닌 클라이언트 컴포넌트에서 사용자 인터렉션을 남기고 데이터 패칭과 같은 작업을 분리하는 역할을 담당한다고 볼 수 있다.

RSC와 SSR의 차이

• SSR은 날 것의 HTML을 클라이언트로 먼저 보내고 사용자 인터렉션이 가능한 React 컴포넌트로 변환하기 위해 하이드레이션을 추후에 적용하는 방식입니다.
• 이는 컴포넌트 자체가 서버에 남아있는 RSC와 구분됩니다.
• 즉, SSR은 애플리케이션의 초기 페이지를 더 빠르게 로드하고 SEO 성능을 끌어 올리는 역할을 담당하고 RSC는 데이터를 수집하고 하위 컴포넌트에 전달하는데 발생하는 네트워크 비용, 레이턴시와 브라우저에서 다운로드 받는 번들링 사이즈를 작게 만들어 앱성능을 향상시키는 역할을 담당합니다.

4. 스토리북으로 인터랙션 테스트하기

https://ui.toast.com/posts/ko_20220111

스토리북으로 인터랙션 테스트하기

• 컴포넌트 UI 단위 테스트 가능
• 컴포넌트 간의 결합 UI 통합 테스트도 가능
• API 서버 데이터 로직 테스트는 MSW(Mock Service Worker)의 도움이 필요
• E2E는 Cypress 또는 Playwright를 활용
• 시각적 결과물 확인 가능
• 자세한 사용 방법에 관해서는 공식 홈페이지 참고
• 인터렉션 애드온을 이용하여 인터랙션을 코드로 작성하고 이를 단계별로 재생할 수 있다.
• Storybook의 iframe.html 기능을 활용하면 Cypress/Playwright와 연계하여 E2E 테스트까지 구현 가능하다.
• Cypress에서는 현재 단독으로 컴포넌트 단위 테스트까지 지원하기 위한 개발을 진행 중이다.

5. Figma 꿀팁 알려주는 사이트

https://awesomefigtips.com/tips

Awesome Figma Tips