https://facebook.com/groups/graphql-kr logo
Join Slack
Powered by
This message was deleted.
# 질문
s
This message was deleted.
t
저는 내부 공용 컴포넌트 (디자인 시스템 등등)는 SCSS + CSS Modules로 하고 프로덕트는 CSS-in-JS 선호해요
https://github.com/callstack/linaria 이런 솔루션을 얼마전에 찾아서 도입해볼까 고민하고 있어요 ㅎㅎ
👍 2
u
오 답변 감사합니다! 디자인 시스템은 저도 SCSS가 맞는것 같은데 CSS in JS가 성능적으로 이슈가 없을까요?
t
넵 ㅎㅎ 애니메이션을 props로 처리하지만 않으시면 충분해요
u
그렇군요, 그러면 저 linaria 이전에는 styled-components 나 emotion 사용한 프로덕트가 있으신가여?
t
네 저희 당근마켓 웹뷰는 전부 emotion이에요
당근마켓 - "내근처" 탭이 emotion 기반입니다
u
웹뷰라 하심은 모바일에서 볼 때인가요?
t
네네
u
아 그러면 emotion (CSS in JS) 사용하시면서 SCSS 보다 어떤게 편하다고 느끼셨나요?
t
모든면에서 좋은거같아요 ㅎㅎ class로 처리안하다보니까 그때그때 동적으로 height를 정해준다던지도 할 수 있게 되구요!
u
답변 감사드립니다! 🙂
a
틈새질문드립니다;; 디자인 시스템에서 scss 사용하는 것은 번들사이즈에 대한 이점이 맞나요??
t
네네 그것도 그렇고 저희는 한 제품을 만드는데 기술 스택 선택을 각 프론트엔드 개발자가 알아서 하고있거든요 ㅎㅎ 만약에 어떤 개발자분이 emotion을 안쓰는데, 공용 컴포넌트를 쓰게되면 번들사이즈가 커질꺼같아서, 일단 공용 컴포넌트들은 CSS Module로 하고 있어요.
a
아 감사합니다!!! dx 도 챙기면서 번들사이즈도 작게가져가는 거슨 저 리나리아(?)가 희망일까요
y
리액트 알못인데, linaria는 그냥 styled-component랑 무슨 차이가 있는건가요? 겉보기에는 비슷해보여서요 ㅎㅎ
t
Copy code
@linaria/webpack-loader
를 이용해서, CSS 파일로 뽑아낼수있습니다 ㅎㅎ
ohh 2
y
오,, 그러면 css 파일 뽑아내서 다른 프론트엔드 라이브러리(혹은 프레임워크) 에서도 활용이 가능하겠네요…
t
CSS Class 이름이 뒤죽박죽이라 그건 힘들지 않을까요? ㅎㅎ
y
아, 그런가요? 그러면 css 뽑아내는 게 어떤 이점이 있는건가요? (정말 알못이라.. 👀)
h
Zero-runtime CSS-in-JS 라고 하는데요
쉽게 생각하면 API 스타일은 Styled-Component 인데 실제 동작은 SCSS 같은 녀석이라고 보시면됩니다.
Linaria는 아예 코드 의존성 분석이랑 추출 실행까지 다 하기 때문에
컴파일타임에 쓸 유틸리티를 JS로 작성할수 있다는게 장점이고
런타임이 없다는게 장점이자 단점이죠
조금 치명적이라고 생각하는 단점은
저거 만든 Callstack 이라는 팀이 RN만 쓰는 팀이라
Linaria 개발이 뜸해요
Linaria는 아예 코드 의존성 분석이랑 추출 실행까지 다 하기 때문에
그리고 이 부분 복잡성 문제때문에 좀 프로덕션에서 쓰기 어렵다는 부분이 있었는ㄷ데 v2 나오고서는 테스트를 못해봤네요
Linaria 는 거의 동적분석이고
https://compiledcssinjs.com/ 이런애들은 순수 정적 분석
저는 개인적으로 작은 런타임이 존재하는 + Atomic CSS 를 지원하는 라이브러리를 선호해요
최근 가장 즐겁게 쓰고 있는건 이친구입니다. https://stitches.dev/
CSS in JS가 성능적으로 이슈가 없을까요?
CSS 삽입할 때 JS 런타임 비용은 생각보다 사소할 수 있습니다 (사이트마다 케바케지만) Emotion/SC 는 Stylis 라는 경량 CSS 파서에 의존하는데 이친구가 굉장히 빨라서 런타임 벤치마크 돌려도 CSS Module 쓰는거랑 별 차이가 안나요. 오히려 output 을 사이트 워터폴에 어떤식으로 통합하는지가 더 중요합니다
👍 1
왜 런타임이 있는걸 선호하는지를 여기다가 적어놨어요 https://blog.cometkim.kr/posts/css-optimization-in-jamstack/
공유하는 라이브러리를 만들때 제일 권장드리고 싶은 방식은, 최대한 구성이 유연한 런타임 라이브러리 선택해 미리 합의를 갖춰놓는 겁니다. (ex. emotion)
가령 emotion 처럼 리액트에 깊게 통합될 수 있는 라이브러리들은 뭘 할 수 있냐면
컴포넌트 렌더링할 때 스타일 통합되는게 대표적으로 두가지 방식이 있는데요. • CSS Extraction • Interleaving style tag
CSS Module 이나 SCSS 같이 정적인 친구들은 선택지가 없어요 무조건 사전 extraction 입니다.
그리고 글에 기술한거처럼 CSS Extraction을 했을 때 Zero runtime 라이브러리들은 리액트 렌더링 맥락에 따른 추가적인 최적화를 할 수가 없습니다.
더군다나 여느 OOCSS 들이 그렇듯이 중복이 많아서 코드베이스에 따라 CSS 사이즈가 가파르게 커져요
페이스북은 이걸 Atomic CSS 로 해결했다고 발표했었죠
물론 Atomic output 이면서 Zero runtime 접근방식 취하는 라이브러리도 상당히 많고요
다만 접근방식에 따라서 얻고 잃는것들이 많으니 검토를 꼼꼼히 해보시는걸 추천드리고
본심: 진짜 왠만하면 그냥 회사에선 이모션 쓰세요
zzzz 1
(물론 이것도 타입스크립트 이슈 생각하면 갈아버리고 싶지만...)
CSS Module 이나 SCSS 같이 정적인 친구들은 선택지가 없어요 무조건 사전 extraction 입니다.
아 Atlassian 의 compiled-css-in-js 라이브러리는 또 독특해서 예외입니다
y
엌… 생태계가 참 복잡하네요… ㅋㅋㅋ
h
이쪽(CSS-in-JS) 맥락 상당히 넓죠 ㅋㅋ
필드에선 선택지가 많이 좁혀지긴 합니다
y
기승전 emotion 인건가요
h
• 리액트만 씀, 런타임 필요 -> Emotion or Styled-components • 런타임 없어야 함, 유틸리티 first 선호 -> Tailwind • 컴포넌트 우선, 철저히 theme 기반으로 스타일링 함 -> 자체 디자인 시스템 라이브러리
여기서 런타임이랑 디자인 시스템이랑 맥락이 애매하게 걸쳐서
따로 보면 알아야할(?) 내용이 더 많긴 합니다
또 디자인시스템 라이브러리 만드는데서 런타임도 만드는 경우도 많고요
어떤 디자인 시스템이 어떤 런타임에 의존하는지도 보셔야합니다
가령 • Material-UI: JSS (차세대에 뭐쓸지 반년째 싸우는중) • Uber Base: 과거 Emotion -> 현재 Styletron • Antd: Less 기반 스타일 시트 유틸리티 등등...
아예 스타일 없는 headless component로 접근성 중시한 빌딩블럭만 만드는 추세도 있는 것 같고요
a
ㅋㅋ안그래도 https://github.com/mui-org/material-ui/issues/21453#issuecomment-751872986 요거 유심히 보고 있었는데,, 이모션으로 하는 것 같더라고요??
h
MUI인가요
a
아 이건 다른 이슈를 링크했네요
h
이거 보시면 대략 상황이
너무 오랫동안 끝나지 않는 전쟁을 하고 있어서
a
이쪽진영은 진짜 토론을 빡시게 하는 느낌이에요
뭐 작은거 결정할떄두
h
중간에 우리 styled-components 간다! 했다가 와장창이라서
JSS 잘쓰고 있는데 왜버리냐... emotion 이 낫지 않냐... 아님 또 뭐가 낫지 않냐... 사실 성능이 어떻다.... 벤치마크 잘못짠거다 등등
👀 1
a
느낌상으로는 추세가 sc 를 꺼리고 웬만하면 이모션을 쓰는 느낌,,
왜그런진 몰겠네용,,
h
꺼리는지는 모르겠지만
emotion 이 훨씬 잘 만든건 맞습니다. (예전엔 가파르게 발전했는데 요즘은 되려 느려진거 같긴함)
그거 아시나요
sc도 내부적으로는 emotion을 써요
정확히는 emotion 의 코어모듈 몇개를 의존하고있죠
a
충격과 공포네요
y
ㅋㅋㅋㅋㅋㅋ
h
아마 stylis 포크도 둘이 공유할걸요
y
재밌네요
a
그럴거면 통합하믄 안대나,,
h
최적화는 sc가 더 빨리 달성했고 emotion 11은 진통을 겪고 있죠
이모션 마이그레이션 너무 고통스러움
둘이 서로 영향을 준부분이 너무 많아서 emotion 버전 9 & sc 버전 4 부터는 둘이 구분하는게 별 의미가 없어졌죠
a
저는 그냥 MUI 를 헤비하게 쓰는 입장에서 MUI컴포넌트 딥하게 스타일 오버라이드할땐 makeStyles(JSS) 쓰구 간단간단한건 sc 쓰고 요러고 있었어요
h
사실 JSS도 확장성이나 이런저런 측면에서 상당히 괜찮은 물건이였는데
a
JSS 만든이가 MUI 멤버여서 그런지 초반에 씨게 밀더라구요
h
MUI가 거의 짊어지다시피 했으니 생태계 자원을 빌린다기 보단 생태계가 유지보수를 떠안은 듯한 그림이 되서
a
그러게요 거의 여기 말고는 쓰이는데가..??
h
아 근데 emotion DX도 상당히 구리죠
CSS in JS API의 미래를 엿보고 싶으시면
작은 프로젝트라도 Stitches 를 써보시죠
케헤헤
a
따끈따끈한 라이브러리네욤
h
뜨끈뜨끈 합니다
최신 생태계 연구들을 반영하면서도 DX를 철저히 고민한 라이브러리죠
아니면 원래질문인
SCSS를 선호하시나요 아니면 CSS in JS를 선호하시나요?
에서 중간쯤 되는 녀석도 있는데요
(이름이 기억 안나서 끙끙대는중
대충 타입스크립트로 쓸 수 있는 CSS Module 같은 거 라 생각하시면 됩니다.
seek-oss 이쪽도 나름 라이브러리 명가라 DX가 나쁘지 않아요
y
엌… 엄청나군요… css-in-js 생태계의 계속 거대한 우주 속으로 빨려들어가는 기분….
a
항상 생각나는게 태초는 그래도 이곳이 아닐까요 https://blog.vjeux.com/2014/javascript/react-css-in-js-nationjs.html
h
최초로 유행한 건
Radium 아니면 Glamor 일거같은데
a
오 Radium 은 옛날에 들어봤던거 같네여,, 왜찾아봤더라,,
y
css-in-js 역사 공부하는 느낌이네요 ㅋㅋ
일타강사 혜성님
u
혜성님 많은 말씀을 해주셨군요.. 감사합니다! 뭔가 결론은 필드에서 쓸만한 건 emotion 인것 같네요
l
시간이 많이 지났지만 뜬금없는 질문을 하나 하고 싶습니다. 혹시 scss가 디자인시스템을 만들때 번들 사이즈의 이점이 있는 이유가 무엇인가요?
h
어떤 이점을 말씀하시는지 잘 모르겠네요. 일단 JS 사이즈에 영향을 주지 않는 점이 있겠죠.
t
혹시 scss가 디자인시스템을 만들때 번들 사이즈의 이점이 있는 이유가 무엇인가요?
뭐 그럴 일은 많진 않지만, 디자인 시스템은 emotion을 쓰고 제품은 styled-components를 쓰면 ㅎㅎ 스타일 관련 라이브러리가 두개가 들어가겠죠?! 저희같은 경우는 외부 업체에 라이브러리를 제공해야하는 상황이여서, 번들 최적화하는 겸해서 emotion을 걷었어요 ㅎㅎ
h
참고로 "번들"에는 css도 들어갑니다. 버젯 잡을 때 critical resources 기준으로 잡는걸 추천드려용
👍 1
물론 pre-extracted css가 브라우저에서 압도적으로 효율적으로 동작하긴 하지만 그럼에도 불구하고
세부적인 수행성능이 별로인데도 사용자 지표가 더 낫게 나오는 경우가 비일비재합니다. https://jantimon.github.io/css-framework-performance/
u
디자인 시스템은 scss 를 쓰면서 구현에는 emotion 을 쓰려고 하는데 딱히 상관 없겠죠?
근데 emotion을 사용하면 
/** @jsxImportSource @emotion/react */
 이걸 계속 넣어줘야 하는군요 🤔
css in js 도 naming issue 문제 수준은 기존 css/sass 의 클래스명 짓는 이슈와 동일한 것 같네요. 컴포넌트 네이밍을 계속 다르게 해줘야 해서 굳이 css in js 가 sass 보다 좋진 않은 것 같아여
지금 둘 중에 고민하고 있는데 이게 맞을까요? 🤔
a
컴포넌트 네이밍을 다르게 하신다는게 구체적으로 어떤 부분인가요??
u
예를 들어, 
<Button />
이라는 컴포넌트를 만들고 그에 관련된 컴포넌트로 밖을 묶는 안에 집어 넣든, 중복되지 않게 컴포넌트 네이밍을 해야 하고 어떤 스타일링을 할때든 컴포넌트를 만들어야 하니까 해당 이름을 짓는데도 결국 고민을 한다는 겁니다!
a
음 제 생각에는 컴포넌트명이 충돌한다는 건 추상화가 잘못되어있다는 신호로 볼 수 있지 않을까요?
같은 Button 에서 스타일링이 약간씩 달라지는 경우는 prop adapting 으로 해결을 보통 하실거구요
기존 css/sass의 global scope 상태에서 네이밍 충돌을 방지하기 위해 고유이름을 짓는거랑은 그래도 차원이 다른 것 같습니다
u
음.. 전 일단 네이밍 충돌 방지는 상관 없는게 sass + css module 을 사용하면 해결이 되구요. 클래스 명을 짓는 것 자체와 컴포넌트 명을 짓는 것 자체를 비교했습니다. 결국 특정 HTML 엘리먼트를 스타일 부여해서 렌더링 하는데 두 방법다 컴포넌트 명과 클래스 명이 필요하니까여
a
음 .. 어떤 이슈를 해결하시는 건지 대략 짐작이 안가서 저는 도움이 안될 것 같네요 혜성님 등장을 기대하며 저는 총총,,
u
이슈는 간단한데요, 웹뷰를 구현해야 하고 따라서 성능이 중요한데 css in js 가 좋을지 scss 가 좋을지 고민중입니다.. 둘 다 장단점이 있어서요.. 어쨌든 답변 감사합니다 🙇‍♂️
🙏 1
h
이것도 웹뷰에서 어떻게 처리하느냐에 따라 너무 달라져서 뭐라 말씀드리기가 어렵네요. Emotion 쓰시면 어느쪽이던 옵션이 있으니 권장드립니다
Css prop 형태로 쓰시면 이름짓는거 걱정 안하셔도 될거같고
Jsx pragma는 바벨 플러그인 설정하시면 안넣어도됩니다.
Emotion 컴포넌트/프래그먼트 이름짓는게 css module 이름 짓는거랑 뭐가 다른지 일단 모르겠네요
u
답변 감사합니다 혜성님!
근데 확실히 css extraction 이 불가능한게 걸리긴 하네요 🤔
h
어디서요?
u
emotion이여
h
하시면 돼요
scss 쓸 때랑 다를거 없습니다
u
되나요? 이슈 찾아보니까 안된다고 나와있어서…
h
u
h
네 바벨 트랜스폼 해줘야합니다만
이모션 지원여부랑 관계없이 다른도구로도 항상 할 수 있습니다
저는 react-snap 으로 캡쳐해서 정적렌더링할때 했었고... 바벨 트랜스폼할 때 추출해서 mini extract loader 태워도 될거고... 다른 방식으로도 충분히 가능해요
그리고 위에 쭉 언급했듯이 pre extracted css 가 항상 좋은건 아닙니다. emotion 의 결정도 많은 리액트 앱에서 충분히 합리적이에요
u
mini-css-extract-plugin 걸려면 웹팩 설정 건드려야 하는데 CRA 에선 한계가 있겠네요 craco 같은 툴 사용하면 불안정하니…
h
u
css 추출이 좋지 않을 때는 어떤건가요? FCP 때문에 할려고 하는거라서
h
즐겨쓰는데 아주 좋습니다
아니면 react-snap 쓰세요
u
아 저것도 봤는데 경고에 써있다시피 불안정한데 딱히 신경쓸 필요없나요?
react-snap 도 알아봐야 겠네요..
h
딱히요.. 뭐하는지만 알면 충분하다고 생각하는데
저는 즐겁게 쓰는편
"불안정" 은 동작에 대해 언급하는게 아니라
업스트림 변경에 취약하다는 점을 언급하는거라
그럴 수 있죠
일단 1년 넘게 동작을 보장하지 못할만한 격한 변경사항이 CRA쪽에서 나오진 않았어요
u
아 업스트림 취약점이군요.. 그럼 괜찮을 것 같네요
h
emotion의 interleaving 방식에서 css 추출했을 때
FCP에는 별 영향 없을텐데요
미미할건데
FCP 고려하시는거라면 더더욱 react-snap 으로 정적 렌더링하는걸 강추드리고요
여기서 inlineCss 기능까지 키셔도 될듯
css 추출이 쥐약인건 뭐 일단 코드스플리팅이나 스트리밍 렌더링 같은 케이스가 제일 대표적일 것 같네요
u
지금 잠깐 찾아보니 SEO 때문에 쓰는 것 같은데 속도에도 영향을 주는가 보군요
h
SEO요?
어.. SSR/SSG를 주로 SEO때문만에 하진 않죠? 흔한 미스컨셉션 같은데
u
그렇긴 하네요 그러면 emotion 의 철학대로 extraction 안하고 react-snap 을 써봐야겠습니다.. 감사합니다.
h
관련 주제로 제가 최근에 여기서 신나게 떠들었는데 extracted vs interleaving 관련해서도 이 즈음에 내용이 있습니다. https://www.twitch.tv/videos/859863677?t=00h58m59s
u
오 한번 보겠습니다. 🙇‍♂️ 감사합니당 어제 벨로퍼트님 방송에도 계시더군요 ㅋㅋ
h
벨로퍼트님 방송 매일 밥먹으면서 봐요 ㅋㅋㅋ
ohh 1
u
react-snap 리드미를 읽고 왔는데 코드 스플리팅 할 때 이슈가 있을 수 있군요 그리고 
inlineCss
옵션은 experimental 이라 사용하긴 힘들겠네여 ㅠ
h
음 전 잘썼는데
2년전에
Experimental 의 의의는 쓰지말라가 아니라 뭐하는지 알고 써라 라고 생각해요
코드스플리팅도 잘 했었어요
만 2년은 아니군요 암튼 이게 snap 이랑 suspense 로 스플리팅해서 개선했던 워터폴입니다. https://twitter.com/KrComet/status/1106113828037713921?s=19
u
그렇군요 자세한 설명 감사합니다!
h
심지어 react-snap 패키지의 존재를 몰라서 똑같은걸 직접구현한 개삽질도... https://twitter.com/KrComet/status/1103193313006387200?s=19
u
엄청나시군요 ㄷㄷ
h
아무튼 접근방식 원리랑 효과를 이해하는게 더 중요할거같습니다
👍 1
단순히 도입하면 좋아진다는 기대보단 결국은 다 해서 측정해봐야해요
일례로 제가 emoji picker 구현때문네 몇가지 컴포넌트를 벤치마킹 한적이있는데
지금보이는 Slack의 emoji picker 는 리액트 컴포넌트인데 리스트 버추얼라이징도 하고 접근성 지원하느라 기능 이것저것붙어서 굉장히 복잡해보이거든요
반면 Emoji mart 라는 패키지도 있는데 얘는 순수 HTML 기능만으로 거의 구현해서 리액트 수준에서는 한번 마운트 후에 리렌더링이 거의 없어요
실제 overroll perf 측정해보면 결과가 재밌습니다
리액트 리렌더링 없는게 무조건 좋을거라 예상했는데
실제로는 마운트 비용이 압도적으로 비싸져서 종합적으로는 큰차이가 없었고
순수 HTML/CSS 렌더링이 브라우저에서 효율적이긴 한데 그것도 어느 정도까지였어요
u
마운트 비용이 리렌더링 비용을 압도할 수도 있군여
h
JS실행 비용 vs 페인트 비용 의 비율만 뒤집히고
오버롤 퍼포먼스가 비슷했죠. 다른 지표에사 생각해보면 더 따질게 많은데 html 구현은 js 비용을 줄여 tti 를 얻겠지만 반대로 critical html resource 를 낭비해요
사실 슬랙이 직접 여러가지 기능 구현과 최적화의 복잡성 감당하는거 희생만 하고 리액트로 목표를 잘 당성한 케이스 같고
덕분에 이후에 뭐 여러가지 확장에서 더 자유롭겠죠
암튼 좀 샜는데
제가 뭐가 좋다고 단정할 수 없늦게 앱 아키텍쳐 내지 통합방식에 따라 달라질수있고
개발 리소스에 따라서도 좌우됩니다 뭐든 그렇죠
특히나 UX랑 직결되는 부분은 은총알이 앖어요 무조건 실험과 측정입니다
가령 CSS Extraction 만 놓고 봐도 웹 퍼포먼스에서 크리티컬 패스 용량 줄이라고 얘기하는데 FCP 때문에 반대로 용량 키우잖아요
u
“No Silver Bullet” 은 역시 띵언이군요.. 다들 장단점이 있는 건 맞는것 같습니다 계속 알아봐야겠네요..
Open in Slack
PreviousNext
Powered by