Jaddong's Lab

코드관리와 퍼포먼스 관점에서의 CSS-in-JS vs CSS in CSS

jaddong — Wed, 3 Jul 2024 16:01:48 +0900

CSS-in-CSS

빌드타임에서 모든 스타일을 생성되어 빌드의 결과물인 css파일의 클래스네임으로 html에 스타일링된다.

ex) bootstrap, tailwinds, sass, less

우리 컴포넌트에서 알아보기

이미 빌드타임에 만들어져 있는 stylesheet로 스타일이 변경되는 걸 확인할 수 있다.

동영상 서비스가 종료되어 해당 콘텐츠를 재생할 수 없습니다.

장점

단순한 CSS 작성으로 러닝 커브가 낮다.
styled-component나 emotion같은 라이브러리가 포함되어있지 않아 번들 사이즈가 작다.
style과 관련하여 가독성을 해치지 않는다.

<span class={"line-clamp-2 truncate break-all leading-normal"}>{text}</span>

단점

초기 로딩에 거대한 stylesheet 파일들이 포함될 수 있다.
중복 코드가 발생할 수 있다.

List라는 컴포넌트가 아래와 같은 스타일이 필요했고, 이에 row라는 클래스네임을 지정했다. Item이라는 컴포넌트가 필요했고 이에 동일한 스타일이 필요해서 같은 클래스네임을 넣어줬다.

.row {
  padding: 0.5rem;
  border: 1px solid #ddd;
}
 
<List className="row"></List>

<Item className="row"></Item>

몇 달 뒤 다른 동료가 코드를 보았을 때 row라는 스타일이 어디에서 왔는지 딱 코드만 봤을 때 알 수가 없다. row클래스네임을 vscode에서 검색해봐야하고, 비슷한 유형의 스타일을 작성할 때 중복되진 않은 지 확인해봐야한다.

BEM으로 className을 잘 확장할 수 있지만 코드베이스에서 여러 사람이 작업할 때 일관성을 유지하는 것이 문제이다.

중첩된 CSS 규칙은 아래와 같이 유지 관리가 어려워진다.

.row {
  padding: 0.5rem;
  border: 1px solid #ddd;
	 
	span{
		color: black;
	}
}
.tx-blue{
	color:blue
}

<Item className="row">
	<span className="tx-blue">text<span>
</Item>

또한 자바스크립트 변수와 이용해 동적 style을 구성할 수 없다.

function ExampleDiv({ width, height }:{width: number; height: number;}) {
  return <div class=`bg-black	w-[${width}px] h-[${height}px]`>안녕하세요</div>;
}

.w-{변수}px{
	width: {변수}px;
}

.h-{변수}px{
	height: {변수}px;
}

CSS-in-JS

초기 런타임에 global css가 작성되고 prop, state따라 runtime에서 javascript가 스타일을 동적으로 생성한다.

ex) styled-components, emotion

우리 컴포넌트에서 알아보기

prop에 따라 class가 바뀌고 그에 따른 stylesheet가 자동 생성되는 것을 확인할 수 있다.

동영상 서비스가 종료되어 해당 콘텐츠를 재생할 수 없습니다.

성능 심층 분석

Spot : Emotion 에서 Sass로

멤버 브라우저 화면은 20명의 유저를 보여줄 것이며,
리스트 아이템을 감싸던 React.memo를 제거했습니다. 그리고,
맨 위에 있는 <BrowseMembers> 컴포넌트가 1초마다 강제로 렌더링하도록 하고, 처음 10개의 렌더링 시간을 기록합니다.

With Emotion : React DevTools를 사용해 페이지를 프로파일링 했고 처음 10번의 렌더링 시간 평균은 54.3ms 였습니다.
Without Emotion : 위에서 설명한 것과 동일한 테스트를 반복했고 처음 10개 렌더링의 평균으로 27.7ms를 얻었습니다. 이는 원래 시간보다 48% 감소한 값입니다!

Airbnb : Sass에서 CSS in JS(react-with-styled)를 거쳐 Linaria로

런타임 프레임워크 (react-with-styles, Emotion)와 빌드 타임 프레임워크 (Linaria, Treat)로 나누어 측정했고
성능 향상은 주로 빌드시 JS에서 정적 CSS 파일로 스타일을 추출하는 Linaria 덕분에 이루어졌으므로 JS 번들 또는 런타임 CPU 오버헤드가 없으므로 거의 제로에 가까운 런타임 Treat보다 약간 우위에 있습니다

결론

코드 관리와 생산성에 있어서는 ‍♀️ CSS in JS 가 우수하다.
- className 규칙을 만들 필요나 팀원간의 유지해야하는 비용 소모가 적다.
- 자바스크립트 변수와 리액트 props와 state를 이용해 다이나믹 스타일링에 제한없이 개발하기때문에 속도가 빠르다.
- 중복 코드를 방지를 방지할 수 있다.
렌더링 퍼포먼스에 있어서는 ‍♀️ CSS in CSS 가 우수한 편이다.
- 런타임에서 css를 생산할 필요가 없기때문에, 런타임 오버헤드를 줄일 수 있다.
- 브라우저에서 리액트가 렌더링 하는 동안 모든 프레임에 대해 모든 CSS 규칙을 효과적으로 재계산하게 할 필요가 없다.

near-zero runtime

stitches.js : stitches.js는 styled-components와 유사한 api를 가진 css-in-js라이브러리이지만 near-zero runtime 을 표방하고 있습니다. 단어 그대로 runtime을 아예 가지지 않는 것은 아니지만, component prop에 의한 interpolation을 최소화하는 방향의 API를 제공합니다.
tailwind + twin.macro : tailwind에 emotion css같이 사용할 수 있도록 추가된 형태로 최초에 로드하는 CSS크기는 작지만, 이후 runtime overhead 발생하긴 한다.

카카오페이지 웹을 새로 개편할 때는 Emotion CSS를 사용함에 따라 발생하는 이런 문제들을 그대로 답습하면 안 된다고 생각했습니다. 우리가 극복해야 했던 문제들은 다음과 같습니다.

디자인 시스템을 위한 부가적인 코드가 실제 기능 코드를 침범한다. (Theme)
- 디자인 코드가 컴포넌트의 가독성을 크게 해치거나 (CSS-in-JS), 기능 코드와 파편화되어 추가 비용을 발생시킨다 (Styled-Component).

이 문제들을 해결하려면 다음과 같은 전제가 보장되어야 합니다.

디자인 시스템을 위한 부가적인 코드가 실제 기능 코드를 침범하지 않아야 한다. (적어도 실제 컴포넌트 내부 구현을 침범하면 안 된다)
디자인 코드가 파편화되지 않아야 하며, 컴포넌트의 가독성을 해치는 부분을 최소화해야 한다.

우리 팀은 Tailwind CSS라는 라이브러리가 이 전제들을 만족시키는 가장 적절한 해결책이라고 생각했고, 따라서 문제 해결을 위한 도구로 프로젝트에 tailwind를 도입하도록 결정했습니다. tailwind를 사용하면 디자인 시스템에서 정의한 네이밍을 사용하기 위해 컴포넌트 내에 어떠한 코드도 추가할 필요가 없으며, CSS-in-JS 방식과 유사하게 HTML 요소 자체에 디자인을 명시하기 때문에 기능 코드와 디자인 코드의 파편화를 막되 유틸리티(utility)라는 개념을 통해 가독성을 해치는 부분을 최소화할 수 있습니다.

나의 생각

만들고 있는 서비스에서 rendering 최적화가 필요하지 않은 정도의 컴포넌트들만 다룬다면 runtime overhead는 무시할만한 수준일 수도 있고, 인터넷 속도나 지역에 따라 runtime overhead가 유저에게 영향을 미칠 수도 있다. 그런데 오히려 runtime이 존재하지 않음으로써 이를 따로 해결해주어야 하는 상황을 만날 수 있다. 그렇기 때문에, 무조건 ‘좋다 나쁘다’로 나눌 수 없으며 서비스의 특성과 계획을 고려하여 알맞은 CSS 사용방법을 선택해야 할 것이다.

개인적으로는 서비스의 크기가 커지면 커질 수록 CSS in JS에 맞는 부분이라고 생각이 든다. stylesheet은 일정하고 그 일정한 stylesheet를 이용해 개발을 하면 좋지만, 현실적으로 서비스 규모에 따라 stylesheet의 양이 많아지는 경우가 많고….(컴포넌트도 늘고….) 그래서 페이지에서 진입해 불러오는 stylesheet리소스를 최소화하고 그 이후 유저의 액션에 따라 stylesheet생성 및 렌더링 퍼포먼스가 유저에게 느껴질 정도가 아니라면 문제가 없다는 생각도 든다. zero-runtime 혹은 near-zero runtime처럼 하이브리드하게 가는 것이 결국엔 좋아보이긴하다.

SPA가 크게 유행을 한 이유가 자바스크립트를 이용한 자연스러운 인터렉션와 스타일, jQuery처럼 직접 DOM을 조작하지 않고 virtural DOM을 사용한다는 점에서 떴다고 생각하는데, 그러면서 간과했던 SEO 라던가 렌더링 퍼포먼스 같은 것들을 보완하기위한 style 라이브러리나 Next.js같은 프레임워크에 초점이 맞춰지는 느낌이다.

참고

FE개발그룹에서는 Tailwind CSS를 왜 도입했고, 어떻게 사용했을까?

(번역) 우리가 CSS-in-JS와 헤어지는 이유

CSS-in-JS, 무엇이 다른가요?

Real-world CSS vs. CSS-in-JS performance comparison

Rebuilding our tech stack for the new Facebook.com

웹 컴포넌트 스타일링 관리 : CSS-in-JS vs CSS-in-CSS

Jamstack에서 스타일시트를 최적화하는 법

디자인 시스템을 개발하면서 알게 된 peerDependencies의 역할

jaddong — Mon, 10 Jun 2024 20:22:35 +0900

package.json에서는 우리가 해당 프로젝트에 대한 정보 및 의존 정보들을 작성하게된다.

name, verson, repository, scripts, dependencies, devDependencies 등의 정보가 json형태로 존재한다.

package.json에서 대부분 쓰는 항상 항목들만 쓰는 경우가 많을 것이다.

하지만 만약 공통 모듈 패키지나 라이브러리를 개발중이라면 peerDependencies에 집중할 필요가 있다는 걸 알게되었다.

1. 문제 발견

my-app 리액트 프로젝트에서 내가 개발한 라이브러리 my-packge와 another-package를 설치해 사용하려고했다.

아래와 같은 package.json를 작성하였다.

{
  "name": "my-app",
  "version": "1.0.0",
  "dependencies": {
    "react": "^17.0.0"
    "my-package": "^1.0.0",
    "another-package": "^1.0.0"
  }
}

my-app에서 yarn install을 하니 아래와 같은 warning을 발견할 수 있었다.

yarn install

warning "my-package@1.0.0" has unmet peer dependency "react@^17.0.0".
warning "another-package@1.0.0" has unmet peer dependency "react@^17.0.0".

하지만 동작에는 크게 문제가 없어보였다. 아마 리액트 버전이 같아서 그럴지도 모르겠다. ‍♀️

다른 경우를 찾아보니 실제로 종속성 에러가 나는 경우도 있었다.

하지만 warning이나 error는 가능하면 깨끗하게 없애고 싶어진다. 그래서 찾게 된 peerDependencies!!

2. 문제 파악하기

"Peer dependencies는 특정 패키지가 다른 패키지를 필요로 하지만, 그 패키지를 직접 포함하지 않고, 상위 프로젝트(패키지를 설치하는 프로젝트)에서 해당 의존성을 설치하도록 요구하는 방식" 이라고 한다.

이렇게만 보면 무슨 소린지 모를 수 있으니 직접 peerDependencies를 작성했을 때와 작성하지 않았을 때를 비교해보도록 했다.

peerDependencies를 작성하지 않았을 때 의존성 트리 확인하기

내가 만든 라이브러리인 my-package와 another-package는 react "^17.0.0"을 의존성으로 가지고 있고

my-app 도 똑같이 react "^17.0.0"를 의존하고 있다.

{
  "name": "my-app",
  "version": "1.0.0",
  "dependencies": {
    "react": "^17.0.0"
    "my-package": "^1.0.0",
    "another-package": "^1.0.0"
  }
}

{
  "name": "my-package",
  "version": "1.0.0",
  "dependencies": {
    "react": "^17.0.0"
  }
}

{
  "name": "another-package",
  "version": "1.0.0",
  "dependencies": {
    "react": "^17.0.0"
  }
}

npm ls react 를 커맨드창에 쳐보자.

위처럼 peerDependencies를 작성하지 않았을 때의 의존성 트리 살펴보면 아래와 같다.

my-package의 node_moules에도 another-package의 node_moudules 에도 똑같이 react가 설치되어진다! 무려 세 번!

my-app
├── node_modules
│   ├── my-package
│   │   └── node_modules
│   │       └── react (17.0.0) 
│   └── another-package
│   │   └── node_modules
│   │       └── react (17.0.0) 
│   └── react (17.0.0)
└── package.json

peerDependencies를 작성했을 때 의존성 트리 확인하기

peerDependencies는 이 라이브러리를 사용하게 될 프로젝트에게, react ^17.0.0 버전을 사용해주세요! 라고 알려주는 것과 비슷하다.

{
  "name": "my-package",
  "version": "1.0.0",
  "dependencies": {
    "react": "17.0.2",
  }
  "peerDependencies": {
    "react": "^17.0.0"
  }
}

{
  "name": "another-package",
  "version": "1.0.0",
  "dependencies": {
    "react": "17.0.2",
  }
  "peerDependencies": {
    "react": "^17.0.0"
  }
}

npm ls react 를 커맨드창에 쳐서 프로젝트에서 의존성 트리를 살펴보면 react가 하나로만 node_modules에 들어가게 된다.

deduped 라고 중복무시된 것을 확인할 수 있다.

my-app
├── node_modules
│   ├── my-package
│   │   └── node_modules
│   │       └── react (17.0.0) deduped
│   └── another-package
│   │   └── node_modules
│   │       └── react (17.0.0) deduped
│   └── react (17.0.0)
└── package.json

차이 요약

Peer Dependencies 사용 전: 각 패키지가 자체적으로 필요한 의존성을 포함하여 node_modules 폴더가 중복 설치된 라이브러리로 인해 커진다.
Peer Dependencies 사용 후: 상위 프로젝트에서 의존성을 관리하여 중복 설치를 방지하고, node_modules 폴더의 크기를 줄인다.

실제 코드로 라이브러리의 빌드 결과물에서 확인해보기

라이브러리에 peerDependencies 없이 빌드했을 때

my-package와 another-package에 peerDependencies에 react와 react-router-dom 를 넣지 않았을 때 dist/index.js 결과물을 보면 아래와 같다.

"var reactExports = {} ... " 로 시작하는 react 코드가 빌드 결과에 포함되어 있는 걸 확인할 수 있다.

이 경우 dist/index.js 을 용량은 180KB로 측정되었다.

라이브러리에 peerDependencies 에 react, react-router-dom 를 추가하여 빌드했을 때

my-package와 another-package에 peerDependencies에 react와 react-router-dom를 넣고 빌드를 하면, react가 아래와 같이 한 줄로만 보여진다.

"var reactExports = {} ... " 로 시작하던 약 2493줄의 리액트 코드가 var React = require('react') 으로 바뀌게된다.

그러다보니 index.js 파일의 용량이 확 줄 수 밖에 없는 것이다.

결론

결론적으로, peer dependencies를 사용하면 패키지 간의 중복 의존성을 줄이고, 빌드된 결과물의 용량을 효율적으로 관리할 수 있었다.

react와 react-router-dom만 peer dependencies에 추가해도 라이브러리 번들 결과를 약 50%나 줄일 수 있었다.

또한 의존성 충돌을 방지하기 위해 의존성 트리를 확인하는 것이 좋을 것 같고, 특히나 react 가 포함된 라이브러리를 리액트 프로젝트에 사용하는 경우 꼭 확인해야할 것으로 보인다.

css 애니메이션, position대신 transform으로 하면 좋은 이유(예제 포함)

jaddong — Wed, 17 Apr 2024 15:01:31 +0900

reflow와 repaint가 많을수록 성능저하를 유발한다고 알고있는데, 이론으로 말고 실제로 구현과 측정을 통해서 어떤 차이가 있는지 알아보고 싶어서 테스트를 작성해봤다.

1. DevTool에서 성능(performance)탭에서 알아본다.

2. 레이아웃이 다시 되는지 확인한다. -> reflow를 확인한다.

relfow

생성된 DOM 노드의 레이아웃(너비, 높이 등) 변경 시 영향받는 모든 노드(자식, 부모)의 수치를 다시 계산하여 렌더 트리를 재생성하는 작업입니다.

repaint

reflow 과정이 끝난 후, 재생성된 렌더 트리를 다시 그리는 작업으로 수치와 상관없는 background-color, visibility, outline 등의 스타일 변경시에는 reflow 과정이 생략 된 repaint 작업만 수행합니다.

그냥 쉽게 해서 종이에 상자 그림이 있고 그걸 다시 그린다고 가정했을 때 아래와 같지 않을까 싶다.

step1 : 종이에 그릴 상자의 너비, 높이, 위치를 다시 계산한다. -> reflow
step2 : 상자를 빨간색으로 다시 칠한다. -> repaint

left로 박스의 위치를 이동시켰을 때

HTML 코드

<!DOCTYPE html>
<html lang="en">
	<head>
		<meta charset="UTF-8" />
		<meta name="viewport" content="width=device-width, initial-scale=1.0" />
		<title>Document</title>
		<style>
			@keyframes reposition {
				0% {
				}
				100% {
					left: 200px;
				}
			}
			body {
				margin: 0;
			}
			#box {
				width: 200px;
				height: 200px;
				background-color: black;
				position: absolute;
				left: 0;
			}
			.move {
				animation: reposition 3s ease-in forwards;
			}
		</style>
	</head>
	<body>
		<button id="button">Move!</button> // 버튼
		<div id="box"></div> // 박스
		<script>
			const box = document.getElementById("box");
			button.addEventListener("click", () => {
				box.className = "move";
			});
		</script>
	</body>
</html>

결과 영상

호출 트리를 보면 레이아웃에 11.0ms 가량 시간이 걸린 것을 확인할 수 있다.

결과 사진

이벤트 로그에서 "레이아웃"으로 검색하면 이동할 때마다 reflow가 발생함을 확인할 수 있다.

호출트리를 보면 레이아웃에 11.0밀리초가 걸린 걸 확인할 수 있었다.

이벤트 로그에서도 계속적으로 레이아웃 감지됨을 확인 할 수 있다.

transform으로 박스의 위치를 이동시켰을 때

HTML 코드

<!DOCTYPE html>
<html lang="en">
	<head>
		<meta charset="UTF-8" />
		<meta name="viewport" content="width=device-width, initial-scale=1.0" />
		<title>Document</title>
		<style>
			body {
				margin: 0;
			}
			#box {
				width: 200px;
				height: 200px;
				background-color: black;
				position: absolute;
				left: 0;
			}
			.move {
				transform: translateX(200px);
				transition: transform 3s ease-in;
			}
		</style>
	</head>
	<body>
		<button id="button">Move!</button>
		<div id="box"></div>
		<script>
			const box = document.getElementById("box");
			button.addEventListener("click", () => {
				box.className = "move";
			});
		</script>
	</body>
</html>

결과 영상

결과 사진

이벤트 로그에서 "레이아웃"으로 검색하면 reflow가 발생하지 않는 걸 확인할 수 있다.

호출트리를 보면 레이아웃이 없는 걸 확인할 수 있다.

이벤트 로그에서도 레이아웃는 없다.

작성한 단순한 코드여서 레이아웃에 11.0ms의 차이가 있지만, 상자를 50개라면 어떨까 궁금했다.

상자 50개로 다시 테스트해 본 결과

left로 구현했을 때 레이아웃에 19ms가 걸렸다.

left : 레이아웃에 19.0ms가 걸렸다.

transform으로 구현했을 때는 역시나 레이아웃에 소모되는 시간이 없다.

transform : 레이아웃이 없다.

결론

테스트용이라서 엄청 큰 차이는 없어보일 수 있으나, 코드가 복잡해지고 애니메이션이 많아진다면 영향을 미칠 수 있다는 생각이 들었다.

평소 애니메이션을 구현할 때 width, height, left, top 같은 property들을 지양하는 습관을 들이는 게 좋을 것 같다.

그럼 어떤 property가 reflow를 일으키는지 궁금할 수 있는데, 링크에서 참고할 수 있다.

transform은 composite로 구분되어 있는데, 이것도 나중에 알아봐야겠다.

- 참고링크 : https://wit.nts-corp.com/2017/06/05/4571

i18n(국제화 언어)리액트에서 적용하기

jaddong — Mon, 11 Mar 2024 17:44:18 +0900

목적

국제화(internalization)된 애플리케이션은 다양한 언어로 서비스를 할 수 있습니다. 그러기 위해서는 사용자의 언어/지역을 자동으로 감지하거나 사용자가 직접 선택할 수 있도록 합니다.

라이브러리 비교

React에서 사용할 수 있는 국제화(internalization, 이하 i18n) 라이브러리는 두 종류가 있습니다.

react-intl
react-i18next
- Next.js지원을 강화한 next-i18next

결론부터 말하자면 다음과 같습니다.

Next.js와 Server Side Rendering(SSR)을 사용해야 한다면 next-i18next
Next.js의 Static Site Generation(SSG)을 사용해야 한다면 react-i18next
- SSR이 필요해질 경우 next-i18next로 갈아타기 편리하기 때문
Next.js를 사용하지 않는다면 react-intl

셋팅

i18next

번역 기능을 제공하는 JavaScript 라이브러리로, React와 같은 프론트엔드 프레임워크와 독립적으로 사용될 수 있습니다. 이 라이브러리는 다국어 지원을 위해 필요한 핵심 기능을 제공하며, 텍스트의 번역, 다국어 문구들의 로딩과 캐싱, 언어 변경 등을 처리할 수 있습니다. i18next 는 다양한 환경에서 사용할 수 있으며, 웹 앱 뿐만 아니라 모바일 앱이나 서버 측 앱에서도 사용할 수 있습니다.

react-i18next(Quick start)

i18next 를 React 애플리케이션에서 쉽게 사용할 수 있도록 해주는 고급적인 React 바인딩 라이브러리입니다. react-i18next 는 i18next 와 함께 사용하기 위해 React 컴포넌트와 훅을 제공하여 React 앱에서 다국어 지원을 쉽게 구현할 수 있도록 도와줍니다.

주로 i18next 는 다음과 같은 구성 요소들로 이루어져 있습니다:

useTranslation: React 훅으로, 컴포넌트에서 다국어 텍스트를 가져오고 언어 변경을 처리할 수 있게 도와줍니다.
Trans: 다국어 텍스트를 렌더링하는 데 사용되는 컴포넌트입니다.
기타 추가적인 유틸리티와 컴포넌트들로 구성되어 있습니다.

i18next-browser-languagedetector

i18next-browser-languagedetector는 i18next 라이브러리의 브라우저용 언어 감지기입니다. 이것을 사용하여 웹 애플리케이션에서 사용자의 브라우저 언어를 감지하고, 해당 언어에 맞는 디폴트 값을 설정할 수 있습니다.

설치

yarn add react-i18next i18next i18next-browser-languagedetector

1. src/i18n/index.ts

src/i18n/index.ts

import i18n from 'i18next'
import { initReactI18next } from 'react-i18next'
import LanguageDetector from 'i18next-browser-languagedetector'

import {
  koHome,
  koGnb,
  enHome,
  enGnb,
  frHome,
  frGnb,
  jpHome,
  jpGnb,
} from '../locale'

// the translations
// (tip move them in a JSON file and import them,
// or even better, manage them separated from your code: https://react.i18next.com/guides/multiple-translation-files)
const resources = {
  ko: {
    home: koHome,
    gnb: koGnb,
  },
  en: {
    home: enHome,
    gnb: enGnb,
  },
  fr: {
    home: frHome,
    gnb: frGnb,
  },
  jp: {
    home: jpHome,
    gnb: jpGnb,
  },
}

i18n
  .use(LanguageDetector)
  .use(initReactI18next) // passes i18n down to react-i18next
  .init({
    resources,
    fallbackLng: 'en',
    supportedLngs: ['ko', 'en', 'fr', 'jp'],
		// language to use, more information here: https://www.i18next.com/overview/configuration-options#languages-namespaces-resources
    // you can use the i18n.changeLanguage function to change the language manually: https://www.i18next.com/overview/api#changelanguage
    // if you're using a language detector, do not define the lng option

    interpolation: {
      escapeValue: false, // react already safes from xss
    },
  })

export default i18n

2. src/main.tsx 에 import i18n 추가

src/main.tsx

import React from 'react'
import ReactDOM from 'react-dom'
import { BrowserRouter } from 'react-router-dom'

import {
  ContainerModalProvider,
  ProgressModalProvider,
  SnackbarProvider,
  ThemeProvider,
} from '@nwaycorp/global-designsystem'
import { nWeb3 } from '@nwaycorp/web3-react'
import './i18n' // 추가

import { App } from './App.tsx'

ReactDOM.render(
  <React.StrictMode>
    <nWeb3.ReactProvider>
      <BrowserRouter>
        <ThemeProvider theme={undefined}>
          <SnackbarProvider>
            <ProgressModalProvider>
              <ContainerModalProvider>
                <App />
              </ContainerModalProvider>
            </ProgressModalProvider>
          </SnackbarProvider>
        </ThemeProvider>
      </BrowserRouter>
    </nWeb3.ReactProvider>
  </React.StrictMode>,
  document.getElementById('root')
)

3. src/locale에 언어별 json 파일

src/locale/en/gnb.json

{
  "about": "about",
  "web3test": "web3 test",
  "designSystem": "design system",
  "connectWallet": "Connect Wallet",
  "disconnectWallet": "Disconnect Wallet"
}

src/locale/en/home.json

{
  "welcome": "Welcome to CCBB"
}

4. src/locale/index.ts 에서 json 파일을 export

import koHome from '../locale/ko/home.json'
import koGnb from '../locale/ko/gnb.json'
import enHome from '../locale/en/home.json'
import enGnb from '../locale/en/gnb.json'
import frHome from '../locale/fr/home.json'
import frGnb from '../locale/fr/gnb.json'
import jpHome from '../locale/jp/home.json'
import jpGnb from '../locale/jp/gnb.json'

export { koHome, koGnb, enHome, enGnb, frHome, frGnb, jpHome, jpGnb }

5. src/constants.ts에 화이트 리스트 language 상수 선언

src/constants.ts

export const languages = [
  {
    label: 'English',
    value: 'en',
  },
  {
    label: 'French',
    value: 'fr',
  },
  {
    label: 'Korean',
    value: 'ko',
  },
  {
    label: 'Japanese',
    value: 'jp',
  },
]

사용법

useTranslation

i18n에서 제공하는 hook

const { t, i18n } = useTranslation(['gnb'])

return (<>
    <Typography>{i18n.language}</Typography> // 현재 lanuage 상태를 보여줌
    <Typography>{t('about')}</Typography> // gnb.about를 불러옴
</>  
)

SelectLanguage

디자인 시스템의 Select 컴포넌트를 활용한 언어를 변경하는 컴포넌트

import { useState } from 'react'
import { useTranslation } from 'react-i18next'

import { Select } from '@nwaycorp/global-designsystem'

import { languages } from '@src/constants'

export const SelectLanguage = () => {
  const { i18n } = useTranslation()
	const initialIndex = languages.findIndex(
    (lang) => lang.value === i18n.language
  )
  const [selectedIndex, setSelectedIndex] = useState<number>(initialIndex)

  const onClickLanguageChange = (index: number) => {
    setSelectedIndex(index) // 선택된 index 값
    i18n.changeLanguage(languages[index].value) // 선택한 언어로 변경
  }

  return (
    <Select
      id="language"
      items={languages}
      onSelect={onClickLanguageChange}
      selectedIndex={selectedIndex}
      size="s"
    />
  )
}

결과

나중에 추가하면 좋을 사항

google sheets 연동으로 번역가와 소통 줄이기 : NHN 국제화(i18n) 자동화 가이드
- https://www.wooslog.com/blog/internalization-automation
- https://www.rldnd.net/react-i18next--

- 참고 문서

https://myeongjae.kim/blog/2020/04/12/react-internationalization-libraries-comparison

https://medium.com/ms-club-of-sliit/internationalization-using-i18next-with-react-typescript-d7c443df3be4

리액트에서 DOM 사이즈 줄이는 최적화 방법

jaddong — Wed, 10 Jan 2024 16:57:38 +0900

어셋 최적화를 포함한 웹서비스에서의 최적화에 관심을 가지게 되면서 작업했던 것 중 하나이다.

아이템 리스트에서 처음에 썸네일 이미지가 보이기 전에 스켈레톤 UI를 보여주곤 한다. 그래서 스켈레톤 컴포넌트를 공통으로 쓰고 있었다. 그러다 보니 단순 이미지 엘리먼트뿐만 아니라 스켈레톤 UI의 DOM도 포함됨으로써 시각적으로 좀 느린 느낌이 느껴졌다!

물론 사용자 입장에서는 크게 느끼지 못할 수 있으나, 개발자 입장에서는 사소한 느린 로딩도 알아채기가 쉽다....

그래서 찾게 된 방법이다. 특히나 emotion이나 styled-component 같은 CSS-in-JS를 사용한다면 DOM구조가 나도 모르게 엄청 깊어지는 걸 알 수 있다. 그래서 이 최대한 DOM요소를 줄여 로드되는 시간을 줄이고자 했다.

DOM 사이즈가 중요한 이유

일반적으로 DOM이 클수록 처음에 해당 페이지를 렌더링하고 나중에 렌더링을 업데이트하는데 더 많은 비용 (Recalucate Style, Pre-Paint 등)이 든다.

요소 삽입
요소 삭제
스타일 수 정리

DOM 사이즈 측정하기

1. Lighthouse 사용

실행하면 현재 페이지의 DOM에 대한 통계가 '진단' 제목 아래의 '과도한 DOM 크기 방지' 감사에 표시된다. Lighthouse에 따르면 페이지의 DOM 크기는 노드가 1,400개를 초과하면 과도한 것이다.

2. JavaScript 콘솔 사용

이 코드에서는 DOM의 HTML 요소 수만 포함되어 있습니다 . DOM의 모든 노드를 포함하지는 않는다.

document.querySelectorAll('*').length;

3. Dev Tool 성능 모니터 도구 사용

이 도구를 사용하면 현재 DOM 크기와 함께 레이아웃 및 스타일 작업(및 기타 성능 측면)을 연관시킬 수 있다.

DOM 크기를 어떻게 줄일 수 있나요?

불필요한 마크업 줄이기
DOM 깊이를 줄이기
Fragment 사용
모던 레이아웃 css 사용(flexbox, grid)

로드 측정 하기

조건

DOM요소 깊이를 줄이기 전 후를 측정했다.
인피니티 스크롤이 포함된 페이지였는데 우선 스크롤을 하지 않은 첫 로드만 측정했다.
로컬에서 측정한 것이라… 속도는 실제 운영과 다를 수 있습니다.
성능 통계, lighthouse로 측정했다.

데브툴에서 페이즈 로드 측정하는 방법

결과

로딩한 Insight를 보면 생각보다 많이 감소됨을 확인할 수 있었다. 1초대 미만으로 줄였지만 이미지가 엄청 크거나 양이 많아지면 이 갭은 훨씬 더 커지게 될 것이다. 간단한 컴포넌트라도 DOM의 깊어지지 않도록 설계 및 스타일하는 것이 매우 중요한 부분이라는 것을 알게 되었다.

FCP : 3.23s → 2.7s (0.53s 감소! ✌️)
LCP : 7.56s → 6.8s (0.76s 감소! ✌️)
DOM의 HTML 요소 수 : 2847 → 2104

DOM 최적화 전

DOM 최적화 후

DOM 최적화 전

DOM 최적화 후

참고

https://web.dev/dom-size-and-interactivity/

큰 DOM 크기가 상호작용에 미치는 영향과 이에 대해 취할 수 있는 조치 | Articles | web.dev

큰 DOM 크기는 상호작용이 빠른지 여부에 영향을 미칠 수 있습니다. DOM 크기와 INP의 관계, DOM 크기를 줄이기 위해 취할 수 있는 조치 및 페이지에 DOM 요소가 많은 경우 렌더링 작업을 제한하는 다

web.dev

사파리에서 webm 영상 백그라운드가 투명하게 나오지 않는 이슈

jaddong — Thu, 4 Jan 2024 18:56:49 +0900

웹에서 비디오 최적화를 위해서는 webm 확장자를 사용하는 것이 좋았다. 하지만 사파리 브라우저에서 자동 재생 이슈와 배경이 투명한 영상이 정상적으로 보이지 않고 까맣게 백그라운드 처리가 되는 이슈를 발견해서 처리하는 과정을 설명해봤다.

비디오 최적화하기

하나의 소스를 제공하는 것이 아니라, 최적화를 위해 여러 영상을 제공하고 브라우저가 렌더링 할 수 있는 영상을 사용한다.

아래의 예시에서는 브라우저가 webm 영상을 렌더링할 수 있는 경우 선택한 영상 파일이다. 그렇지 않으면 다음 요소로 이동하여 두 번째 요소는 mp4 형식의 영상을 가리키게 된다 . 브라우저가 mp4 영상을 렌더링할 수 있는 경우 해당 영상 파일을 사용하고 webm의 용량이 mp4보다 훨씬 작아 우선순위가 높기 때문에 먼저 선언해주면 된다.

<video controls>
  <source src="https://storage.googleapis.com/web-dev-assets/video-and-source-tags/chrome.webm" type="video/webm">
  <source src="https://storage.googleapis.com/web-dev-assets/video-and-source-tags/chrome.mp4" type="video/mp4">
  <p>Your browser cannot play the provided video file.</p>
</video>

자동 재생 정책(링크)

사용자의 관점에서 경고 없이 자발적으로 소음을 내기 시작하는 웹 페이지나 앱은 거슬리거나 불편하거나 불쾌할 수 있다. 그 때문에 브라우저는 일반적으로 특정 상황에서만 자동 재생이 성공적으로 발생하도록 허용한다.

일반적으로 다음 중 하나 이상 이 참인 경우에만 미디어 자동 재생이 허용된다고 가정할 수 있다 .

오디오가 음소거되었거나 볼륨이 0으로 설정되어 있는 경우
사용자가 사이트와 상호작용 하는 경우(클릭, 탭, 키 누르기 등).
사이트가 허용된 경우 이것은 브라우저가 사용자가 미디어를 자주 사용한다고 판단하는 경우, 자동으로 발생하거나 기본 설정 또는 기타 사용자 인터페이스 기능을 통해 수동으로 발생 가능.
자동 재생 권한 정책을<iframe>을 사용하여 문서에 자동 재생 지원을 부여하는 경우.

사파리 브라우저 이슈

내가 적용한 영상이 배경이 투명한 상태에서 오브제가 자동재생으로 움직이는 영상이었는데, 사파리 브라우저에서 배경이 까맣게 보이는 이슈가 있었다. 그래서 이게 사파리 버전 이슈인건가 해서 회사에 있는 몇 가지 브라우저를 버전 별로 확인해봤고 아래와 같은 특징을 발견했다.

1. 사파리에서 webm을 불러올 경우 백그라운드가 투명하게 되지 않는 경우, mp4를 불러오면 배경이 투명한 정상적으로 영상 재생됨.

버전 16.5.1(18615.2.9.11.7)

2. 사파리에서 webm이든 mp4든 NotAllowedError: The request is not allowed by the user agent or the platform in the current context, possibly because the user denied permission. 에러가 나면서 아예 영상이 자동 재생되지 않고 이미지만 보이는 경우 → 사파리 정책에서 자동재생을 막고 있음

버전 15.5(17613.2.7.1.8)
버전 16.3(18614.4.6.1.6)

해결방법

완벽하게 처리는 될 수 없었지만, 최대한 webm을 로드할 수 있도록 + 유저입장에서 불편하지 않도록 하는 방향으로 아래와 같이 처리했다.

영상은 webm과 mp4를 기본적으로 제공하는 걸로 했다.
webm를 소스를 우선적으로 불러와 재생한다. 최적화를 위해!
브라우저를 detect하여 mac OS + safari의 경우 mp4소스를 우선적으로 불러와 재생하도록 한다. (영상은 webm에 비해 무겁겠지만 어쩔 수 없었다ㅠㅠ)
2번 혹은 3번에서 play에 에러가 있으면 영상없이 대체 이미지가 fallback 되도록 했다.

출처

Autoplay guide for media and Web Audio APIs - Web media technologies | MDN

Automatically starting the playback of audio (or videos with audio tracks) immediately upon page load can be an unwelcome surprise to users. While autoplay of media serves a useful purpose, it should be used carefully and only when needed. In order to give

developer.mozilla.org

<video>: The Video Embed element - HTML: HyperText Markup Language | MDN

The <video> HTML element embeds a media player which supports video playback into the document. You can use <video> for audio content as well, but the <audio> element may provide a more appropriate user experience.

developer.mozilla.org

리액트에서 라이브러리없이 간단하게 이미지 최적화하기

jaddong — Wed, 3 Jan 2024 16:10:00 +0900

서비스가 심미적이나 기능적으로 모두 구현되었다고 끝이 아님을 대부분 개발자들이 알고 있을 것이라 생각한다. 그중에 꼭 짚고 넘어가야 할 것이 어셋들(image, video, sound 등)에 대한 성능 최적화 작업이다. 성능 최적화 작업은 프론트엔드, 벡엔드, 디자이너 단에서 모두 각자의 방식으로 작업이 가능하나 그중 나는 프론트엔드 쪽에서 작업한 경험을 간단하게 정리해 보았다.

이미지 최적화하기

svg

svg 이미지는 sources로 사용하는 것보다 svg그대로 사용하는 것이 성능에 좋다.

import { ReactComponent as Logo } from "assets/icons/logo_bg.svg";

const LogoComponent = () => {
  return (
      <Logo title="logo image" />
  );
};

sources

하나의 소스를 제공하는 것이 아니라, 최적화를 위해 여러 이미지는 제공하고 브라우저가 렌더링 할 수 있는 이미지를 사용한다.

아래의 예시에서는 브라우저가 AVIF 이미지를 렌더링할 수 있는 경우 선택한 이미지 파일이다. 그렇지 않으면 다음 요소로 이동해 두 번째 요소는 WebP 형식source 의 이미지를 가리키게 된다. 브라우저가 WebP 이미지를 렌더링할 수 있는 경우 해당 이미지 파일을 사용하고 그렇지 않으면 img에 있는 이미지 파일(JPEG)로 대체된다.

<picture>
  <source srcset="image.avif" type="image/avif">
  <source srcset="image.webp" type="image/webp">
  <img src="image.jpg" alt="A description of the image." 
    width="300" height="200" loading="lazy" decoding="async">
</picture>

WebP 파일이 PNG 파일보다 26% 작고 JPEG 파일보다 최대 34% 작기 때문에 매우 빠른 로딩 시간을 제공한다.

Can I Use 에 따른 글로벌 WebP 및 AVIF 지원 수치는 다음과 같다.
- WebP : 웹 사용자의 약 96.30%가 WebP를 지원하는 브라우저를 사용하고 있습니다.
- AVIF : 웹 사용자의 약 79.81%가 AVIF를 지원하는 브라우저를 사용하고 있습니다.

lazy

true로 설정하면 페이지에서의 위치에 관계없이 리소스를 즉시 로드하지 않고 뷰포트로부터 계산된 거리에 도달할 때까지 리소스 로딩을 지연시킨다. 스크롤 해야 보이는 이미지의 경우는 lazy를 처리하는 것이 첫 로딩에 부하를 줄일 수 있다.

<img src="image.png" loading="lazy" alt="…" width="200" height="200">

https://storage.googleapis.com/web-dev-assets/native-lazy-loading/lazyload.webm

동영상 서비스가 종료되어 해당 콘텐츠를 재생할 수 없습니다.

srcSet

디스플레이 사양(1x, 2x, 3x) 에 따라 w 디스크립터(Width descriptor)를 사용해 포트 너비에 최적화된 이미지를 선택해 출력할 수 있다. 다른 해상도의 이미지를 각각 제공하는 것이 시각적으로도 좋고 데이터 낭비도 줄여서 유저 경험에 긍정적인 효과를 줄 수 있다.

다른 확장자와 dpr에 따른 이미지가 필요하다면 아래와 같이 구현이 가능하다.

위의 이미지처럼 html 코드가 길어지기 때문에 공통적으로 사용할 수 있는 image 컴포넌트를 따로 만들어 구현하는 것이 서비스 전반적으로 적용하기에 훨씬 나았어서 구현했던 코드를 간단히 공유해본다. -> GitHub Link

import ImagePng from "assets/images/fallback.png";
import ImageAvif1x from "assets/images/image_1.avif";
import ImageAvif2x from "assets/images/image_2.avif";
import ImageAvif3x from "assets/images/image_3.avif";
import ImageWebp1x from "assets/images/image_1.webp";
import ImageWebp2x from "assets/images/image_2.webp";
import ImageWebp3x from "assets/images/image_3.webp";


const MainImage = () => {
  return (
      <Image
        src={ImagePng} // fallback 이미지
        sources={[
          { srcSet: `${ImageAvif1x} 1x, ${ImageAvif2x} 2x, ${ImageAvif3x} 3x`, type: "avif" },
          { srcSet: `${ImageWebp1x} 1x, ${ImageWebp2x} 2x, ${ImageWebp3x} 3x`, type: "webp" },
        ]}
        width="100%"
	/>
  );
};

출처

웹용 브라우저 수준 이미지 지연 로드 | Articles | web.dev

이 게시물에서는 로드 속성 및 이 속성을 사용하여 이미지 로드를 제어하는 방법을 다룹니다.

web.dev

사진 요소 | web.dev

이미지를 더욱 창의적으로 관리할 수 있습니다.

web.dev

AVIF vs WebP: Which Image Format Reigns Supreme in 2023?

AVIF and WebP are next-gen formats that reduce file sizes. However, you might not know which to choose. Here's our guide to AVIF vs WebP!

themeisle.com

Throttle와 Debounce 개념 알고 상황에 맞게 쓰기

jaddong — Thu, 2 Mar 2023 22:23:56 +0900

Throttle 과 Debounce 의 필요성이 나온 이유

1. 검색창에서 "떡볶이"를 검색할 때

타이핑을 할 때마다 텍스트 필드 하단에 입력한 검색어와 맞을 만한 추천 검색어를 하단에 보여주게된다. 이런 경우 매번 입력할 때마다 api를 호출해본다고 생각해보자. 사용자 경험으로는 추천 검색어를 바로 볼 수 있기 때문에 좋을 수는 있으나, 사용자의 의도와 무관한 요청이 계속 된다면 이것은 성능적으로 매우 좋지 않은 결과가 있을 수 있다. 또한 api의 호출이 잦아 로딩이 길어진다면 사용자의 경험에도 안 좋은 영향을 줄 수 있다.

2. Infinite scrolling page(무한 스크롤 페이지)

사용자가 스크롤을 할 때마다 새로운 컨텐츠가 하단에 무한으로 보여지는 되는 UX는 요즘 어디서나 쉽게 찾아볼 수 있다.(트위터, 인스타그램 등)사용자가 스크롤을할 때 footer와의 거리를 계산해서 컨텐츠를 불러오는 온다고 생각해보자. 그렇다면 onScroll 이벤트가 계속 일어날때마다 footer와의 거리를 계산해서 api를 호출할 것인가? 이것 또한 api호출이 무분별하게 많아질 수 있으므로 성능상이 이슈가 있을 수 있다.

3. 티켓팅 결제나 댓글을 등록할 때 등록 버튼을 여러번 연속으로 클릭한다면?

요즘은 거의 없겠지만 댓글을 등록을 할 때 등록을 여러번 클릭해 동일한 댓글이 두 번 달린 경험이 있을 것이다. 등록버튼을 클릭하고 바로 disabled하거나 막지 않으면 동일한 폼을 여러번 submit하게 되어 의도와 다르게 여러번 게시될 수 있다.

그래서 이런 문제점을 보완하고자 Throttle 과 Debounce개념이 나왔다. 이벤트가 발생할 때마다 function을 실행하게되면 성능상이 이슈가 있으므로, 이벤트가 발생되는 동안 function이 계속 실행되지 않도록 일정한 시간을 주는 것을 말한다.

Throttle 과 Debounce 이란

스크롤 예제 하나로 아주 쉽게 이해할 수 있다.

1. Nothing : 스크롤할 때마다 function이 실행

2. Throttle : 스크롤을 할 때 일정한 시간 간격을 두고 정기적으로 function을 실행

3. Debounce : 아무리 많은 스크롤해도 모두 무시하고 특정 시간 사이에 어떤 스크롤도 발생하지 않았을 때 딱 한번만 마지막 function을 발생시키는 기법

Throttle 과 Debounce 원리

loadsh에 있는 throttle과 debounce를 코드를 까보면 이런 식으로 구현되어 있다.

debounce의 경우 이벤트가 실행되었을 때 일정 시간을 기다렸다가 이벤트를 수행하도록 만들고, 일정 시간 내에 같은 이벤트가 또 들어오면 이전 요청을 취소하는 방식으로 구현한다.

function debounce(callback, delay) {
  let timer;
  return function () {
    clearTimeout(timer);
    timer = setTimeout(() => {
      callback.apply(this, arguments);
    }, delay);
  };
}

throttle은 타이머가 없을 경우 타이머를 설정하고, 타이머가 있을 경우 아무런 동작도 하지 않도록 하여 일정 시간 이후에 이벤트가 1번 실행되도록 구현한다.

function throttle(callback, delay) {
  let timer;
  return function () {
    if (!timer) {
      timer = setTimeout(() => {
        callback.apply(this, arguments);
      }, delay);
    }
  };
}

Throttle 과 Debounce 를 언제 사용해야하나

throttle이나 debounce는 사실 정답이 없고 상황에 맞춰서 사용해야한다.

검색창에 타이핑을 할 때 100ms 마다 자동완성검색창이 나왔으면 한다면 throttle을 사용해야하겠고, 어느정도 타이핑을 다 입력하고 이벤트가 멈췄을 때 자동완성이 보이는 걸 원한다면 debounce를 사용하면 되겠다.

하지만 보편적으로 쓰이고 있는 경우는 아래와 같다.

Throttle

- 무한 스크롤 기능 : SNS에서 자주 쓰이는 무한 스크롤 기능에서는 debounce보다 throttle이 적합하다. 유저가 스크롤링을 멈출 때까지 기다렸다가 새로운 글을 불러오는 것보다는 유저의 스크롤이 어느 정도 내려왔을 때 미리 글을 불러오는 것이 좀 더 좋은 경험을 제공할 수 있기 때문이다.

- 브라우저 resize : resize 이벤트는 빈번하게 발생될 수 있기 때문에, 이벤트 핸들러는 DOM 수정과 같은 계산이 많이 필요한 연산을 실행하지 않아야 한다. 대신에 이벤트를 스로틀(throttle) 하는것이 좋다. -> MDN 사이트

Debounce

- toggle버튼 : 알림설정 toggle 버튼은 수시로 쉽게 수정할 수 있다. 이 경우 toggle 이벤트 리스너에 어느 정도 debounce를 줘서 마지막으로 일어난 toggle의 요청만 처리하는 것이 유저에게 좋은 경험일 것이다.

- 자동완성 검색어 : 한 글자씩 타이핑할 때마다 api를 호출하여 자동완성 검색을 하단에 바뀌도록 보여주는 것보다는 어느정도 단어가 완성된 후 자동완성을 제공해주는 것이 성능상에도 유저의 경험에도 더 적절할 것이다.

여담

전에 회사에서 사내에서 사용하는 백오피스의 버튼에 debounce나 throttle같은 기능을 해놓지 않아 버그처럼 보였던 경험이 있다. 그리고 scroll에 따라 element의 스타일이 변경되는 작업도 해보았어서 이번 공부를 통해 이벤트 핸들링에 대해 더 예민하게 봐야할 필요가 있다는 생각이 들었다. debounce나 throttle는 이벤트나 함수들의 실행되는 빈도를 줄여서 성능상의 유리함 가져기도 하지만 유저의 경험에도 직접적으로 영향을 줄 수 있기 때문이다.

참고

- https://webclub.tistory.com/607

- https://css-tricks.com/debouncing-throttling-explained-examples/

- https://pks2974.medium.com/throttle-%EC%99%80-debounce-%EA%B0%9C%EB%85%90-%EC%A0%95%EB%A6%AC%ED%95%98%EA%B8%B0-2335a9c426ff

- https://medium.com/@kwoncharles/debounce%EC%99%80-throttle%EC%9D%98-%EC%B0%A8%EC%9D%B4-34845fbfa1ff

Throttle 와 Debounce 개념 정리하기

Throttle 와 Debounce 라는 개념 을 알게 되어 이를 정리해보고자 한다.

pks2974.medium.com

Debouncing and Throttling Explained Through Examples | CSS-Tricks

The following is a guest post by David Corbacho, a front end engineer in London. We've broached this topic before, but this time, David is going to drive the

css-tricks.com

디바운스(Debounce)와 스로틀(Throttle ) 그리고 차이점

Throttle, Debounce & Difference 스로틀(Throttle)과 디바운스(Debounce)란 무엇일까? 이 두 가지 방법 모두 DOM 이벤트를 기반으로 실행하는 자바스크립트를 성능상의 이유로 JS의 양적인 측면, 즉 이벤트(event)

webclub.tistory.com

rollup 빌드 결과 파일 cjs, esm 차이, package.json, rollup.config.js

jaddong — Sun, 5 Feb 2023 19:58:17 +0900

현재 회사에서 디자인시스템을 모노레포로 만드는 작업을 하고 있다. 모노레포에 있는 각각의 라이브러리들을 rollup을 통해 번들링이되는데, 지금 모노레포와 rollup 관련해서 꽤나 삽질을 하고 있다. 그래도 배우는 것이 있어서 정리해보고자 한다.

현재 rollup.config.js파일이다. 여기선 결과물의 경로나 format을 정할 수 있다 cjs로 선택되어 있는 상태이다.

// rollup.config.js
output: {
    dir: "lib",
    format: "cjs",
    exports: "named",
  },

이렇게 나온 번들 결과물을 package.json에서 사용하겠다고 지정을 한다.

main은 이 라이브러리를 사용할 때 참조할 파일이고, types는 타입스크립트 파일이 되겠다.

그러면 module와 esm은 뭐고 왜 필요하지라는 궁금증이 생기게 되었다.

// package.json
{
  ...
  "main": "lib/index.js",
  "module": "lib/index.esm.js",
  "types": "lib/index.d.ts",
  ...
 }

여기서 우선 esm과 cjs의 차이를 알아보면 우선 코드상에서 import, export할 때의 차이가 있다는 걸 알 수 있다.

리액트로 개발하는 개발자라면 esm이 눈에는 더 익숙할 것이다.

이 외에도 차이가 다양하니 여기서 자세히보면 되겠다.

CommonJs (CJS)

// util.js
module.exports = (x, y) => x + y;

// main.js
const whateverWeWant = require('util');
console.log(whateverWeWant(2, 4));

ECMAScript Modules (ESM)

// util.js
export const sum = (x, y) => x + y;

// main.js
import { sum } from 'util'
console.log(sum(2, 4));

그래서 라이브러리의 빌드 결과로 나온 index.js 외에 index.esm.js는 왜 필요한 것인가?

main

라이브러리 빌드 결과의 메인 파일로 어떤 프로젝트에서 이 라이브러리를 설치하게되면 index.js 파일을 참조하게된다.

module

이 라이브러리를 설치한 프로젝트를 빌드할 때, index.esm.js를 참조해 빌드하게된다.

ems는 트리쉐이킹이 가능해 JavaScript 번들의 사이즈를 줄여서 렌더링이 중단되는 시간을 최소화는 효과가 있다.

위의 설명보다 자세히 예시를 들어보겠다.

프로젝트에서 아래와 같이 libraryA라는 라이브러리를 설치했다고하자.

import { Button } from "libraryA";

로컬에서 개발할 때 command나 ctrl을 누르상태로 libraryA 부분을 클릭하면 node_modules에 해당 라이브러리의 index.js파일을 가리키는 것을 확인할 수 있다. main에서 지정한 데로 index.js 파일에서 import가 된다는 것이다.

여기서 import로 불러오든 require로 불러오든 상관이 없다! 자세한 건 여기서 확인할 수 있다.

This diagram summarizes the above rules.

그런데 module에서 선택한 esm의 경우는 개발할 때가 아닌 번들링할 때 참조가 이뤄진다. 프로젝트 완성 후, 완성한 프로젝트를 번들러로 빌드를 할때 libraryA의 package.json의 module에서 지정한 esm형식을 참고해 빌드가 이뤄진다. 그리고 esm은 트리쉐이킹 가능해서 빌드할 때 프로젝트에서 libraryA에서 사용한 것만 긁어서 빌드가 된다.

위의 경우 Button만 import했다면 Button만 골라서 빌드가 된다는 것이다.

일반적으로 CommonJS형태는 트리쉐이킹을 할 수 없다. lodash를 예로 들면, lodash는 CommonJS 형태로 번들링되어 배포되기 때문에 webpack의 기본설정으로는 lodash를 트리쉐이킹 할 수 없다. 트리쉐이킹을 위해서는 babel-plugin-lodash을 사용하거나 lodash-es를 사용하는 것을 추천한다.

그래서 결론은 라이브러리를 만들 때 cjs와 esm을 둘다 제공해주는 것이 좋고 esm버전이 프로젝트의 번들사이즈를 줄이는 데 도움을 줄 수 있다는 것이다.

참고

- https://roseline.oopy.io/dev/translation-why-cjs-and-esm-cannot-get-along

- https://pencilflip.medium.com/using-es-modules-with-commonjs-modules-in-node-js-1015786dab03

- https://maeng2418.github.io/development/library_deploy/

- https://toss.tech/article/commonjs-esm-exports-field

CommonJS와 ESM에 모두 대응하는 라이브러리 개발하기: exports field

Node.js에는 두 가지 Module System이 존재합니다. 토스 프론트엔드 챕터에서 운영하는 100개가 넘는 라이브러리들은 그것에 어떻게 대응하고 있을까요?

toss.tech

라이브러리 배포 cjs? ejs?

개요 언젠가 한번 나만의 라이브러리를 만들어서 배포해보고 싶다는 생각을 갖구있다가 이번에 디자인시스템 개발을 도전하게 되었다. 리액트 컴포넌트 기반으로 디자인시스템 개발에 대한 자

maeng2418.github.io

Using ES modules with CommonJS modules in Node.js

This is not meant to be a comprehensive overview of ES modules and CommonJS modules — I do not go into depth about what modules are and…

pencilflip.medium.com

[번역] 왜 CommonJS와 ES Modules는 함께 쓸 수 없는가 | 내 라이브러리에서 esm과 cjs를 동시에 지원하는

Dan Fabulich의 Node Modules at War: Why CommonJS and ES Modules Can’t Get Along 을 번역한 글입니다. 이미지나 설명이 필요한 부분은 추가로 덧붙여 놓았습니다.

roseline.oopy.io

Multiple Pointers - countUniqueValues(고유값세기 - 다중포인터)

jaddong — Sun, 29 Jan 2023 22:41:20 +0900

문제

Implement a function called countUniqueValues, which accepts a sorted array, and counts the unique values in the array. There can be negative numbers in the array, but it will always be sorted.
정렬이 되어있는 배열에서 고유의 값들의 갯수를 세는 함수를 실행하라. 배열에는 음수가 있을 수 있으나 항상 정렬이 되어있다.

Examples:
countUniqueValues([1,1,1,1,1,2]) // 2
countUniqueValues([1,2,3,4,4,4,7,7,12,12,13]) // 7
countUniqueValues([]) // 0
countUniqueValues([-2,-1,-1,0,1]) // 4

Note:
Time Complexity - O(n)
Space Complexity - O(n)

나의 코드

시간복잡도는 O(n) 이어야 하므로 for 문이 이중이면 안된다.
이중포인터(i,j)를 가지고 값을 비교해가며 두 값이 다를 경우에 j값을 i+1값에 넣어가며 전진한다.

function countUniqueValues(arr){
    if(arr.length === 0){
        return 0;
    }
    
    var i = 0;
    for(var j= i+1; j<arr.length; j++){
        if(arr[i] !== arr[j]){
            arr[i+1] = arr[j];
            i++;
        }
        if(j === arr.length -1){
            return i+1;
        }
    }
   

}

console.log(countUniqueValues([1,1,1,1,1,2]))

강의에서의 정답

나의 코드는 문제에서의 조건, 결과가 맞았다.
그러나 for문 안에서 j와 arr의 길이를 비교하는 조건문은 필요가 없었다. 어짜피 j는 arr끝까지 가야 탐색이 끝나는 것이기때문에 필요없는 구문을 넣었다는 점이 아쉬웠다.
그리고 for문 안에서 i도 ++을 먼저했으면 되는데, i값을 증가시키는 연산을 두번이나 한 셈이어서 이것도 수정하는 것이 좋겠다.

function countUniqueValues(arr){
    if(arr.length === 0) return 0;
    var i = 0;
    for(var j = 1; j < arr.length; j++){
        if(arr[i] !== arr[j]){
            i++;
            arr[i] = arr[j]
        }
    }
    return i + 1;
}
countUniqueValues([1,2,2,5,7,7,99])

강의 : https://www.udemy.com/share/106X8E3@Lt-njJ7uYB8WJ1Fa57QDkC-Jt8Jccl8YSfNg-Ss97_zbUJPT4bPNz4Cynqye826R/