8/29 - Server Component와 CSS-in-JS

Emotion 사용에 대한 고민

[classpick 개발일지 #1] Next.js13으로 마이그레이션하기 - emotion 써도 되나? 고민하기 (velog.io)

[classpick 개발일지 #1] Next.js13으로 마이그레이션하기 - emotion 써도 되나? 고민하기

해당 글을 읽으며 server component 에 대한 개념을 알게 되었다.

 

Next) 서버 컴포넌트(React Server Component)에 대한 고찰 (velog.io)

Next) 서버 컴포넌트(React Server Component)에 대한 고찰

윗글에서는 또한 이번 Next.js 13버전으로 올라감에 따라, App Routing을 기본적으로 권장하게 되었는데,

여기서 사용되는 app directory의 내부의 컴포넌트는 기본적으로 server compoent 방식으로 작동된다고 한다.

 

여기서부터는 그저 나의 생각으로만 정리한 글이다.

server component는 서버에서 React로 동작한 결과(즉, 상호작용적이지 않은 정적인 결과일 것임)에 포함될 것이다.

그런데 CSS-in-JS 프레임워크는 js파일 내부에 작성되어, 스크립트 파일이 동작되며 스타일을 적용할탠데,

유의할점은 Next.js는 페이지에 해당되는 js파일을 수행한 결과를 클라이언트에게 전달하는 프레임워크 라는 것이다.

 

정확히 이것이 원인인지는 모르겠지만, 문제는 그러한 작동 원리 때문에, CSS-in-JS 프레임워크를 사용하려면, Next.js는 js파일을 읽어가며, CSS-in-JS로 표현된 스타일 내용까지 적용된 마크업 결과를 클라이언트에게 전달해야 할 것이다.

 

아마 이러한 원리 때문에 서버에서 동작되어 결과로만 보내지는 server component에서는, 런타임에 동적으로 style 내용을 추가, 조정하게 설계되어있는 CSS-in-JS 스타일이 적용에 문제가 생길 수 있다고 생각한다.

(이런 맥락으로 생각하면, 런타임에 작동되는 client component는 CSS-in-JS의 적용에 문제가 없는 것이 당연하다. 브라우저에서 보는 화면에서 <style>의 내용이 변경되면 결과로 나타나서 그대로 사용자가 보기 때문.)

 

이러한 Next.js에서의 문제때문에 CSS-in-JS 프레임워크에 대해서 더 자세히 찾아보도록 했다.

(번역) 우리가 CSS-in-JS와 헤어지는 이유. 원문… | by Jung Han | Medium

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

저번 프로젝트에서 css module를 통해 스타일을 구성했었는데,

이때 단점이 자바스크립트 변수 값으로 특정 값들을 저장하여 사용하고 싶었는데,

scss에서도 어느정도 사용가능 했지만, 다크모드같이 유기적인 변환이 복잡하다는 단점이 있었다.

 

이번 프로젝트에서는

CSS-in-JS의 장점인 이런 css module의 단점을 깨고, 자바스크립트 파일 내에 스타일도 같이 작성하여

더 유기적인으로 코드를 작성할 수 있을 것 같아 emotion을 채택하였었다.

(또한, 윗 글에선 프로젝트 규모가 커질때, css파일이 많아 짐에 따라 직관적인 확인이 힘든 문제가 생기지 않는 것도 장점으로 뽑았다.)

 

단, 윗 글의 논의와 같이

CSS-in-JS는 컴포넌트가 렌더링 될 때 CSS-in-JS 코드를 일반 CSS스타일로 변환하는 데의 소요가 생기고,

번들에 대한 약간의 용량 (7kb정도) 를 더 보내야 된다는 단점이 있다.

이 글의 고민과도 같게, SSR에서의 적용 문제 또한 지적하였다.

 

그래서 나는 결론적으로 사용하기로 한 Emotion을 다른 것으로 대체하기로 하였다.

CSS-in-JS 라이브러리들에 대한 고찰 (velog.io)

CSS-in-JS 라이브러리들에 대한 고찰

 

Emotion이 Next.js에서 특히 문제가 되었던 점은, Next.js가 SSR 방식으로 지원되는 프레임워크였기 때문이다.

Emotion은 클라이언트의 런타임 시간에 <style> 태그에 style을 추가하는 방식으로 작동한다.

그렇기 때문에 서버에서 결정되는 server component와는 제대로 호환되지 않는다고 생각하였다.

 

이를 대체할 라이브러리로 vanilla extract을 사용해보려 한다.

vanilla extract은 같은 CSS-in-JS의 라이브러리지만 zero-runtime 방식이다.

런타임 시간에 style을 조정하는 것이 아닌, css 스타일시트를 작성하여 런타임 시간에는 style 내용을 변경하지않고, css 변수를 통해 조정되는 방식으로 작동한다.

 

그렇기 때문에, SSR 방식에 더 친화적이라고 생각한다.

css 변수를 이용하는 방식이기 때문에 css 변수를 지원하지 않는 브라우저와의 호완성 문제가 있긴하지만

우선은 Next.js를 통한 개발을 진행하는 것을 1순위 목적으로 두려고한다.