Material-ui: [RFC] 스타일이 지정된 구성 요소로 마이그레이션

@kybarg 문제를 열어주셔서 감사합니다! CSS-in-JSS는 움직이는 분야입니다. 과거에 선택한 사항은 문제와 솔루션이 변경됨에 따라 더 이상 유효하지 않을 수 있습니다.

스타일이 지정된 구성 요소가 과거에는 왜 없었습니까?

JSS를 선택하기 전에 사용 가능한 다양한 스타일링 솔루션을 비교 했습니다.

다음과 같은 이유로 styled-components 를 선택하지 않았습니다.

• 추상화 비용. css-in-js-perf-tests 는 좋은 리소스이며 스타일이 지정된 구성 요소는 내부적으로 매력을 사용합니다.
  
  
  
  • JSS의 경우 22kb보다 압축 해제된 126kb
  
  
  • 첫 번째 페인트 시간이 더 느립니다. https://github.com/MicheleBertoli/css-in-js 의 동등한 데모에서 처음 페인트하는 시간을 비교하면 JSS가 40% 더 나은 성능을 보입니다.
  
  
• className 및 CSS 딥 셀렉터 기능을 노출하면 성능을 구현할 수 있습니다. 예를 들어 <Grid /> : #6010.
• 서버 측 렌더링 동시성 은 불가능합니다. JSS는 각 요청에서 스타일을 수집하기 위해 새 인스턴스를 인스턴스화하는 동안 싱글톤에 의존하여 스타일을 수집합니다. 스팀은 정말 제한적입니다.

사실 @nathanmarks 가 인라인 스타일에서 벗어나기 시작했을 때 styled-components 는 존재하지도 않았습니다.

비교표

글로벌 CSS 지원

https://github.com/cssinjs/jss-global 을 사용하면 다음과 같은 것을 작성할 수 있습니다.

const styles = {
  '<strong i="35">@global</strong> body': {
    color: 'green'
  }
}

재정의하기 쉬움

이게 어떻게 쉽지 않지? Material-UI 측에는 사전 정의된 사출 순서 테이블이 있습니다. 사용자 영역에서는 훌륭한 최음 재정의 API를 구현하는 최음제 를 사용할 수 있습니다.

래퍼 구성 요소 없음

Material-UI 측에는 래퍼 구성 요소가 없습니다. withStyles 를 사용할 수 있었지만 성능상의 이유로 사용하지 않습니다. 컨텍스트 구현을 추상화하기 위해 해당 고차 구성 요소를 사용자에게 노출합니다.

테마

우리는 내부적 으로 jss-theme-reactor를 사용합니다. JSS는 이를 가능하게 하는 저수준 API를 노출하고 있습니다.

ReactNative 지원

좋은 지적입니다. react-with-styles API는 매우 흥미롭습니다. 그것은 우리가 개선할 수 있는 것입니다!

미래

앞으로 가장 유망한 경로는 스타일 구현을 전환 할 수 있는 API를 갖는 것입니다. 그러면 다음과 같은 두 가지 이점이 있습니다.

• Material-UI는 어떤 스타일링 솔루션과도 덜 결합 됩니다.
• styled-components / aphrodite/... 를 사용하는 사용자는 내부적으로 사용되는 JSS 오버헤드 를 절약할 수 있습니다.

react-toolbox 가 해당 경로 를 따르고 있습니다. 내 유일한 관심사는 추가되는 오버 헤드입니다. 내 말은, 그만한 가치가 있습니까?

루프에 @kof 및 @mxstbr 을 추가하고 있습니다.

@kybarg 사실, 나는 당신이 제안하는 것을 완전히 이해하지 못합니다.
귀하의 질문에 따르면 react-jss 를 사용하고 있지 않습니다 .

우리라고 할 때 사용자 또는 Material-UI를 말하는 것입니까?

내 포인트는 다음과 같습니다.

• styled-components 는 JSS 코어보다 훨씬 높은 수준의 라이브러리이므로 애플리케이션 계층에서 확실히 사용할 수 있습니다.
• 위의 비교표는 JSS core가 아닌 react-jss에 대한 것으로 Max의 주관적인 의견입니다. 그것은 부분적으로 사실이 아니며 부분적으로는 우리가 표에서 볼 수 없는 특정한 관점에서 본 것입니다.
• 우리는 보다 효율적인 동적 스타일링을 위해 동적 규칙 렌더링 작업을 하고 있습니다. jss-theme-reactor가 이미 작업을 수행하고 있습니다. 단지 최적화 문제일 뿐이며, 이는 아마도 MUI와 별로 관련이 없을 것입니다.
• MUI가 내부적으로 사용하는 것은 최종 사용자가 전혀 걱정할 필요가 없습니다. 사용자가 수행해야 하는 모든 작업은 MUI가 내부적으로 무엇을 사용하고 있는지 또는 테마를 지정하기 위해 최소한 다소 규칙적인 cssinjs 구문을 사용하지 않고도 가능해야 합니다.
• MUI가 현재 지원하지 않는 사용 사례를 가져와서 해결해야 합니다. 저는 항상 통합 프로세스를 돕고 gitter에서 사용할 수 있게 되어 기쁩니다.
• 어쨌든 반응 네이티브 지원이란 무엇입니까? 웹 플랫폼의 하위 집합이 아닙니까? 그렇다면 제대로 작동해야 하고, 그렇지 않으면 JSS가 react-native를 지원하기 위해 무엇을 할 수 있어야 하는지 알려주십시오. 여기에 문제가 있습니다.

이 표는 실제로 매우 주관적이며 내 경험을 기반으로 합니다. FWIW, styled-components 는 타사 구성 요소 라이브러리와 함께 작동합니다.

import { Button } from 'material-ui'

const MyButton = styled(Button)`
  // Only these styles will be overridden
  background: red;
`

구성 요소가 내부적으로 일부 DOM 노드에 className 소품을 첨부하는 한 작동합니다.

const MaterialUIButton = (props) => {
  /* ... */
  // As long as props.className is attached, the above usage will work
  return <button className={`bla ${props.className}`} />
}

어쨌든 반응 네이티브 지원이란 무엇입니까? 웹 플랫폼의 하위 집합이 아닙니까?

아니요, 그렇게 쉬운 일이 아닙니다 😉 JSS에 대한 지원을 추가하는 것은 어렵지 않습니다. 스타일 개체를 StyleSheet.create() 에 전달하기만 하면 되기 때문입니다. CSS 문자열이 작동하도록 하려면 styled-components 측에서 조금 더 노력해야 합니다.

나는 지금 잠시 @javivelasco 와 이야기를 나누었고 그가 react-toolbox 와 함께 가는 곳을 좋아합니다. 그의 구현은 놀랍고 모든 타사 구성 요소 라이브러리가 이를 채택하는 것을 보고 싶습니다. 그가 여기에 그의 아이디어를 차임할 수 있도록 그를 핑!

서버 측 렌더링 동시성은 불가능합니다. JSS는 각 요청에서 스타일을 수집하기 위해 새 인스턴스를 인스턴스화하는 동안 싱글톤에 의존하여 스타일을 수집합니다. 스팀은 정말 제한적입니다.

전혀 관련이 없습니다. 이 문제 에 대해 이를 허용할 API에 대한 아이디어에 대해 언급하시겠습니까? 우리는 무엇을 할 것인지 결정하지 않았으므로 귀하의 의견을 매우 감사하게 생각합니다.

안녕하세요, gitter에서 이것에 대해 문의했습니다. 다른 사람들의 견해를 얻기 위해 여기에도 게시합니다.

나는 material-ui _next_가 커스텀 jss 솔루션에 막대한 투자를 하고 있다는 것을 알고 있습니다.
스타일이 지정된 구성 요소보다 jss를 사용하는 것의 심각한 이점을 발견한 사람이 있습니까?

jss는 데코레이터(injectstyles) 및 플러그인과 같은 여러 패턴을 가능하게 하기 때문에 좋지만 데코레이터, 사용자 지정 설정 및 플러그인이 필요하지 않기 때문에 styled-components의 직접적인 접근 방식이 훨씬 깨끗하다고 ​​생각합니다.

styled-comp에서 모든 구성 요소는 이미 스타일이 지정되어 있으므로 스타일을 전달할 필요가 없습니다. 다른 스타일을 생성하기 위해 평가할 수 있는 소품을 전달합니다.
설정 없음(createJss)
플러그인 없음(접두사)
JSON DSL 없음

누군가 이 스레드를 잠가야 합니다.

@rainice jss에는 데코레이터가 없으며 HOC는 react-jss의 구현 세부 사항이며 여기에서는 사용되지 않습니다.

왜 이것을 잠가야 합니까? 건전한 토론입니다 IMO

여기에 있는 최종 사용자 기반 콘텐츠(lib 관리자가 아님)는 매우 피상적이며 그들이 사용하는 것 뒤에 있는 코드 한 줄도 읽지 않았기 때문에 이해할 수 있습니다.

스타일링 솔루션의 선택에 대해 길게 논의했고 결정의 근거가 문서화 되었으며 다음 주요 릴리스를 위한 개발 작업이 진행 중이므로 유용한 문제가 아니므로 이만 마치겠습니다.

사람들이 닫힌 스레드에 계속 게시하지 않을 만큼 충분히 성숙하기를 바랍니다. 그러나 필요할 경우 잠글 수 있습니다.

덜 결합된 스타일링 솔루션을 사용하여 해당 스레드를 앞으로 이동할 수 있기를 바랍니다!
그러나 지금 우리의 우선 순위는 구성 요소의 마이그레이션/전반적인 개선을 끝내는 것이어야 한다고 생각합니다.

@mxstbr styled-components 감사합니다

구성 요소가 className 소품을 일부 DOM 노드에 내부적으로 연결하는 한 작동합니다.

이것은 mui:next 가 출시될 때 사용 가이드의 어딘가에 강조 표시할 가치가 있습니다. 이 댓글이 저를 구했습니다.

IE10용 Flex 스타일은 jss에서는 작동하지 않지만 매력처럼 스타일이 지정된 구성 요소에서는 작동합니다.

@yhaiovyi Material-UI는 IE10을 지원하지 않습니다.

공급업체 접두어 evtl. jss에 대해 곧 수정될 예정이지만 mui가 IE10에서 테스트되지 않은 경우 모든 문제가 해결된다는 의미는 아닙니다.

어쨌든 나는 지금까지 IE10에서 CSS flex를 사용한 다음 다른 문제를 찾지 못했습니다.

Material UI 스타일을 Styled Components로 재정의하는 3가지 방법이 있는 것 같습니다(더 쉬울 수 있지만 모든 것이 꽃은 아닙니다). 여기 내 요점 이 있습니다.

또한 몇 줄의 코드로 스타일이 지정된 구성 요소 API를 얻을 수 있습니다. https://material-ui-next.com/customization/css-in-js/#styled -components-api-15-lines-

styled-jss 도 사용할 수 있습니다(예: https://codesandbox.io/s/32mvjyjyxq ).

일반적으로 JSS의 유일한 단점 은 여기에도 말했듯 이 코드 편집기에서 자동 완성 기능이 없다는 것입니다. 그러나 이점이 있습니다. styled-components에서처럼 CSS를 js로 구문 분석하는 것은 약간 과부하

편집: 방금 위에서 언급한 문제를 발견했습니다. 흥미롭습니다.

짜증나는 것은 Mui의 컨텍스트와 withStyles HOC가 핵심 react-jss 및 styled-jss ThemeProvider https://codesandbox.io/s/32mvjyjyxq 와 잘 작동하지 않는 것 같습니다( Typography 하지만 작동하지 않습니다. 편집: nvm, 여전히 만지작거리고 있음)

나중에(v1 이후) src/styles/withStyles 및 MuiThemeProvider + JSSProvider 이중 레이어를 단순화하고 react-jss 및 styled-jss가 다음과 같이 좀 더 단순한 것을 갖는 것이 가치가 없는지 궁금합니다.

그것을 위해 완전히!

2018년 3월 13일 13시 55분에 "Cyril Auburtin" [email protected] 이 다음과 같이 썼습니다.

짜증나는 것은 Mui의 컨텍스트와 withStyles HOC가 재생되지 않는 것 같습니다.
핵심 react-jss 및 styled-jss ThemeProvider와 잘 어울립니다.
https://codesandbox.io/s/32mvjyjyxq

나중에(v1 이후) 단순화할 가치가 없는지 궁금합니다.
src/styles/withStyles 및 MuiThemeProvider + JSSProvider 이중 레이어

—
이 스레드에 가입했기 때문에 이 메시지를 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/mui-org/material-ui/issues/6115#issuecomment-372655385 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AADOWAbwLOnRoypx9ANCZnKyalZyD0M9ks5td8HNgaJpZM4L-GwD
.

styled-components에서와 같이 CSS를 js로 구문 분석하는 것은 약간의 과부하입니다.

CSS에 대한 객체 구문 분석이 :wink인 것처럼 문자열 구문 분석은 거의 동일한 속도이며 솔직히 중요하지 않습니다. https://github.com/A-gambit/CSS-IN-JS-Benchmarks/blob/master/RESULT.md

솔루션 | CSS 사용 | 인라인 스타일 사용 | 마운트 시간(ms) | 렌더링 시간(ms)
:--- | :--- | :--- | :--- | :---
...
스타일 구성 요소 | + | - | 182 | 146.84
스타일 구성 요소 분리 셀 | + | - | 213.53 | 152.39
...
반응-jss | + | - | 198.97 | 297.74

@mxstbr 런타임에 js로 작성된 전체 CSS 파서는 확실히 가격이 있습니다. 그 벤치마크는 비용을 측정하지 않습니다.

런타임에 js로 작성된 전체 CSS 파서는 확실히 가격이 있습니다.

물론, 하지만 문자열이 아닌 객체를 처리하는 완전한 CSS 파서 이상은 아닙니다. 게다가 실제 CSS 문자열에서 작동하는 CSS 파서는 오랫동안 최적화되고 탐색되었으며 객체를 처리하는 파서는 훨씬 적습니다. :붉히다:

파서가 있는 객체로 부트스트랩 CSS를 벤치마킹하는 것과 우리 파서인 스타일리스가 있는 부트스트랩 CSS를 벤치마킹하는 것에 대해 궁금합니다.

파서가 있는 객체로 부트스트랩 CSS를 벤치마킹하는 것과 우리 파서인 스타일리스가 있는 부트스트랩 CSS를 벤치마킹하는 것에 대해 궁금합니다.

예, 적절한 벤치마크가 될 것입니다. 제가 약간 테스트를 해보니 개체 작업이 10-20배 더 빨라졌습니다.

그러나 다시 말하지만 포함할 jss 플러그인에 따라 다르며 구문 설탕 플러그인이 많이 있습니다.

또한 TBH. 우리 모두가 ISTF로 옮겨가도 상관없습니다.

나는 약간의 테스트를 했고, 개체 작업은 10-20배 더 빠릅니다.

물론입니다. 하지만 10ms(스타일러스가 전체 부트스트랩 스타일시트를 구문 분석하는 데 걸리는 시간)와 응용 프로그램의 전체 CSS를 구문 분석하는 데 1ms가 소요되는 것은 전체적인 구조에서 중요하지 않습니다. 그것은 누군가의 앱을 만들거나 깨뜨리지 않을 것입니다.

어쨌든 필요 이상으로 많은 알림으로이 문제에서 짜증나는 사람들을 중지합시다.

ㅋ 이 벤치마크가 더 정확한 것 같습니다. http://necolas.github.io/react-native-web/benchmarks/ 첫 번째 구문 분석 후 캐시에 의존하지 않지만 확실하지 않습니다.

@mxstbr 이 문제는 현재 잠겨 있지만 약간의 건전한 경쟁은 모두에게 좋습니다. 언제든지 다시 오십시오. 문제가 토론을 위한 적절한 장소가 아닌 경우 gitter 채팅에서 저희를 찾을 수 있습니다.

이 문제는 1년이 넘었습니다. 얘들아, 댓글 그만 달자. 토론을 새 토론으로 이동할 수 있습니다. 토론이 시작된 후 많은 것이 변했습니다.

그러나 잠금 문제를 피하려고 노력합시다. 더 나은 결정을 내리기 위해 가능한 한 많은 피드백을 계속 수집해야 합니다.

나는 이것을 명확하게 전달하기 위한 도구로 문제를 잠그는 것은 괜찮다고 생각합니다. 아무도 이에 대해 화를 내지 않았으며 언론의 자유가 침해되었습니다. 이 경우 정말 괜찮습니다.

더 많은 피드백을 수집하기 위해 재개장 중입니다. 이것이 사람들이 여전히 관심을 갖고 있는 것인지 궁금합니다.

로드맵을 업데이트하는 데 결과를 사용할 개발자 설문조사 가 진행 중입니다.
스타일 솔루션에는 다음과 같은 요구 사항이 있습니다.

1. 번들 크기 . 우리는 사람들이 20KB의 압축 비용을 지불하지 않고도 단일 구성 요소를 사용할 수 있기를 바랍니다. 순위별:
   
   
   
   1. 감정은 이 방향에서 가장 좋은 후보입니다: 10kB gzipped . 그러나 소수의 사람들이 사용합니다. 다운로드 통계를 보면 80%가 스토리북에서 나온다고 ?
   
   
   2. styled-components 무게 약 16KB gzipped . 그의 장점은 그것을 사용하는 사람들의 수에서 비롯됩니다. 아마도 React 사용자의 20%?
   
   
   3. 반응 래퍼 가중치가 약 15KB인 JSS가 gzip으로 압축되었습니다. 다운로드 통계를 보면 Material-UI에서 많이 사용됩니다.
   
   
2. 성능 . 우리는 사람들이 우리의 구성 요소를 사용자 정의할 수 있기를 바랍니다. 가능한 한 빨라야 합니다. 내가 할 수 있는 벤치마크는 다음 순위를 산출합니다.
   
   
   
   1. 감정
   
   
   2. jss
   
   
   3. 스타일 구성 요소
   
   
3. 사용자 정의 API . 변형 사용자 정의는 쉬워야 하고 중첩 요소 사용자 정의는 쉬워야 하며 새 변형 추가는 쉬워야 합니다. 지금 우리는 classes API, theme.overrides API 및 전역 결정적 클래스 이름을 가질 수 있는 기능을 가지고 있습니다.
4. 상호 운용성 . !important 를 사용하는 것은 해결책이 아닙니다.
5. RTL 지원

나는 스타일 구성 요소, 감정 및 JSS만 언급했지만 linaria, SASS 등 다른 대안입니다.

Material-UI에서 사용하는 CSS-in-JS 라이브러리에서 작업할 시간이 있을 때 결정에 영향을 줄 수 있으므로 다음 두 가지 문제를 추가하는 것이 좋습니다.

• https://github.com/mui-org/material-ui/issues/15660
• https://github.com/cssinjs/jss/issues/1102
  간단히 말해서, 이 두 가지 문제는 개발 경험에 영향을 미치는 JSS의 불일치를 다룹니다.

@o-alexandrov JSS는 styled-components와 동일한 전략을 따르고 있습니까? 나는 당신의 요점을 이해하지 못합니다. 명확히 해주시겠습니까? 차이점이 뭐야? 어떻게 더 낫거나 가치가 있습니까?

@oliviertassinari
이전 메시지에서 styled-components 또는 다음과 같은 완벽한 균형을 갖춘 다른 CSS-in-JS 라이브러리의 사용을 평가하려는 아이디어를 환영한다는 점을 제외하고는 styled-components 에 대해 아무 말도 하지 않습니다.

• 개발 경험(익숙함 및 유연성, 추가 기여, 개발자의 실제 사용 등)
• 성능

위의 두 가지 문제에 대한 링크는 JSS 작업의 현재 부정적인 측면 만 논의합니다.
다음을 어디에서 보았는지 잊어버렸지만 결정을 내리려면 먼저 모든 유형의 벤치마크를 추가해야 결정을 더 쉽게 평가할 수 있다는 점을 잘 지적한 것으로 기억합니다.

개인적으로 다음을 좋아합니다.

• 훨씬 더 광범위한 커뮤니티 채택을 위해 jss 보다 styled-components .
  커뮤니티의 채택이 머티리얼 UI가 고려해야 할 핵심 측면이라고 생각합니다.

@o-alexandrov 좋습니다. 이 경우 첫 번째 댓글을 주제에서 벗어난 것으로 표시하겠습니다. v5에서는 핵심 구성 요소를 스타일링 솔루션에서 분리하려고 합니다. 나는 우리가 구성 요소의 네이키드, JSS, 감정, linaria 및 styled-components(기본값으로) 버전을 제공할 수 있기를 바랍니다. 그것이 비전입니다. 이제 구현이 어려울 것입니다!

번들 크기

styled-components 은 @5.0.0-beta.8 에서 12.3kB 를 개선하는 것으로 입증되었습니다.

사용자 정의 API

패키지 또는 외부 패키지에 https://github.com/styled-components/styled-components/pull/2625 를 도입하면 언젠가 필요할 수도 있는 스타일이 없는 구성 요소 API가 없기 때문에 Mui에 대한 API 패리티가 있다고 생각합니다. , 특히 레거시 시스템에서 하지만 Mui 자체에서 API가 그렇게 자주 필요하지 않을 것이라고 생각합니다.

그 밖에,

내 개인적인 경험 styled-components 이 우리에게 필요한 기능을 제공하기 때문에 어떤 정보를 수집하고 싶은지 잘 모르겠습니다.

상호 운용성.

이 맥락에서 당신에게 이것은 무엇입니까? 내가 아는 한 다른 프레임워크와 마찬가지로 styled-components 의 항목을 재정의할 수 있습니다.

RTL 지원

이것은 우리가 컴포넌트를 코딩하는 방식을 기반으로 하지 않습니까? styled-components 또는 CSS-in-JS 라이브러리는 정확히 무엇을 제공해야 합니까?

내 생각

속도

이전에는 다른 솔루션에 비해 느렸지만 기여자들의 지원과 놀라운 노력으로 JSS보다 훨씬 빨라졌습니다.

크기

v5 12.3kB from 16.2kB $에서 말했듯이 v5은(는) 이 주제에 대한 그들의 노력을 나타냅니다.

정통

API가 가장 대중적이어서 사람들은 익숙하지만, 실제로 styled(...) ... API를 사용할 때 대부분의 사람들은 실제 패키지가 아닌 API를 참조하여 styled-components 라고 부릅니다.

네이티브 반응

Mui는 웹이지만 사람들은 계속해서 styled-components 를 채택할 것입니다.

핵심 팀

Strong Core 팀은 오늘 81개의 이슈와 14개의 PR이 열렸고, 이것은 패키지를 사용하는 사람들의 수에 비해 좋은 숫자입니다.

또한 @mxstbr 과 같은 사람들은 실제로 spectrum 의 패키지를 사용하므로 패키지를 사용하는 실제 경험이 있습니다. 놀랍습니다. 즉, 실제로 패키지를 사용하는 느낌을 알고 있다는 것입니다.

받았다

글쎄, 더 좋을 수 없다 https://www.styled-components.com/docs/tooling

UI 작성자용

오늘날 디자인 시스템 구성 요소에 대한 styled-components 의 채택이 많이 증가하고 있습니다. Atlassian, GitHub, Orbit 등.

이것은 당신이 혼자가 아니기 때문에 Mui에 좋습니다. 그래서 아마도 사람들은 당신이 직면할 수 있는 잠재적인 상황을 이미 처리하고 그것을 처리하는 방법을 알아냈을 것입니다.

TL;DR

저는 styled-components 를 지지합니다.

CSS에 대한 개체 구문이 더 쉬워졌기 때문에 JSS를 좋아합니다. 때로는 게으르고 해당 스타일을 style={{styles.dialogTitle}} 인라인 스타일로 전달하기도 합니다. 나중에 리팩토링하기 쉽습니다.

styled-components https://material-ui.com/styles/basics/#styled -components-api와 같은 요소 래퍼를 사용하여 다양한 방식으로 사용할 수 있습니다.

@caub https://www.styled-components.com/docs/advanced#style -objects

나는 styled-components를 정말 좋아하지만 최근에 그것이 tree-shaking 작업을 일관되게 만드는 것을 어렵게 만드는 많은 문제를 소개한다는 것을 발견했습니다. 나는 material-ui 팀이 이 라이브러리에 대해 tree-shaking이 완전히 작동하도록 하기 위해 많은 작업을 했다는 것을 알고 있으며 분명히 이에 대한 회귀는 피해야 합니다.

다행히도 대부분의 트리 흔들기 문제는 babel-plugin-styled-components 를 사용하고 pure: true 를 설정하여 해결됩니다(https://www.styled-components.com/docs/tooling#dead-code-elimination 참조). ). 그러나 아직 몇 가지 남은 문제가 있습니다. 예를 들어:
https://github.com/styled-components/babel-plugin-styled-components/issues/245

다른 하나는 스타일 내에서 외부 도우미 기능을 사용하면 트리 흔들림이 중단될 수 있다는 것입니다(특정 기능을 무시하도록 terser/uglify를 구성하지 않는 한). 예:

const Button = styled.button`
  font-size: ${externalHelperFunction()};
`

나무 흔들기가 올바르게 작동하려면 이 모든 문제를 해결하는 것이 가능해야 한다고 생각하지만 확실히 까다로울 수 있으며 현재 상황에서 이상적인 방식으로 작동하지 않습니다. 나는 실제로 여전히 스타일이 지정된 구성 요소로 전환하는 것이 좋은 생각일 수 있다고 생각하지만 이러한 문제가 해결될 수 있는 경우에만 가능합니다.

@mbrowne 트리 흔들기 및 스타일 구성 요소 문제를 재현할 수 없습니다. 문제에는 재현 가능한 예가 포함되어 있지 않으므로 다음을 사용하여 복제하려고 했습니다.

// components.js
import React from "react";
import styled from "styled-components/macro";

const Wrapper = styled.div`
  color: blue;
`;

export function MyComponent() {
  return <Wrapper>styled</Wrapper>;
}

MyComponent.displayName = "FancyName";

export function OtherComponent() {
  return "only";
}

// App.js
import React from 'react';
import { OtherComponent } from "./components";

/* code */

기본 create-react-app . MyComponent 는 프로덕션 번들에 표시되지 않습니다.

rollup 에만 문제가 있습니까? 문제를 이해하기 위해 재현 가능한 예를 주시면 감사하겠습니다.

@eps1lon 스타일이 지정된 구성 요소에 정적 속성을 설정할 때 문제가 나타나는 것 같습니다. 시도해 볼 수 있습니까?

const Wrapper = styled.div`
  color: blue;
`;

Wrapper.displayName = "FancyName";

export function MyComponent() {
  return <Wrapper>styled</Wrapper>;
}

export function OtherComponent() {
  return "only";
}

@mxstbr 예, 두 경우 모두 styled-components가 번들로 제공됩니다. MyComponent 에 displayName 을 설정하는 동안 번들에 MyComponent 포함하지 않았지만 여전히 styled-components 포함합니다. 기본적으로 MyComponent 에 대해 수행된 모든 작업을 제거합니다. 이것이 내가 원래 제대로 트리 셰이크라고 생각한 이유입니다(방금 FancyName 검색했습니다.

그러나 여전히 styled-components 가 포함되어 있습니다. styled 호출을 부작용이 있다고 생각하더라도

import React from "react";
import styled from "styled-components";

export function Wrapper() {
  // nonsense
  return styled.div``;
}

export function MyComponent() {
  return <Wrapper>styled</Wrapper>;
}

export function OtherComponent() {
  return "only";
}

{ OtherComponent } 를 가져올 때 부작용이 없지만 스타일이 지정된 구성 요소는 여전히 번들에 나타납니다(매크로가 없는 경우에도 마찬가지입니다). 그래서 이것은 버그이거나 큰 것을 놓치고 있습니다. 조차

// Wrapper.js
import React from "react";
import styled from "styled-components";

export default function Wrapper() {
  // side-effect free module even if styled has side-effects
  const Component = styled.div``;
  return <Component />;
}

// components.js
// commenting this out removes styled-components from the bundle
export { default as Wrapper } from "./Wrapper";

export function OtherComponent() {
  return "only";
}

// index.js
import React from 'react';
import ReactDOM from 'react-dom';
import { OtherComponent } from "./components";
import * as serviceWorker from './serviceWorker';

ReactDOM.render(<OtherComponent />, document.getElementById('root'));

// If you want your app to work offline and load faster, you can change
// unregister() to register() below. Note this comes with some pitfalls.
// Learn more about service workers: https://bit.ly/CRA-PWA
serviceWorker.unregister();

styled-components (https://github.com/eps1lon/styled-components-shake)가 포함됩니다.

react-scripts, webpack 또는 styled-components의 버그일 수 있습니다. 어쨌든 이러한 문제를 디버깅하는 것은 재현 없이는 매우 어렵습니다.

이해가 됩니다. 조사해 주셔서 감사합니다.

이 사용 사례의 경우 styled-components 가 번들에 포함되어 있는지 여부가 중요하지 않다고 생각합니다(모든 구성 요소가 이를 사용해야 하므로). 오히려 사용하지 않는 구성 요소가 포함되는지 여부가 중요하지 않습니다. 그런 것 같으니 괜찮겠죠?

@mxstbr 중요한 문제가 될 수 있습니다. 스타일이 지정되지 않은 일반 구성 요소(Modal, Popper, TextareaAutosize, useMediaQueries 등)가 몇 가지 있습니다. 누군가 사용한다고 가정해 보겠습니다.

import { Modal } from '@material-ui/core';

SASS와 함께. 우리는 +20kB gzip이 아니라 +5kB gzip으로 증가할 것으로 예상합니다(오늘 현재).

그러나 @material-ui/unstyled 를 앞으로 푸시한다고 가정하면 실제로 사람들이 이 패키지를 사용할 수 있으므로 차이가 없을 수 있습니다.

@eps1lon 죄송합니다. 정적 속성 문제가 모든 구성 요소에 영향을 미치는 것처럼 보였기 때문에 다른 사람들이 더 쉽게 재현할 수 있을 거라고 생각했습니다... 문제를 유발하는 다양한 요인이 있는 것으로 나타났지만 적어도 몇 가지 간단한 경우 작동합니다.

여기에서 재현 가능한 데모를 만들었습니다.
https://github.com/mbrowne/CRA-error-template/tree/styled-components-tree-shaking
git clone --single-branch --branch styled-components-tree-shaking [email protected]:mbrowne/CRA-error-template.git

Component1만 트리가 올바르게 흔들리는 방식에 유의하십시오.

좋은 소식은 이러한 문제가 모두 해결될 수 있다고 생각하고 @mxstbr 이 여기에 매우 참여하는 것 같다는 것입니다. 저는 곧 최소한 정적 소품 문제를 해결할 PR 작업을 할 것입니다(저는 이미 작성한 별도의 Babel 플러그인을 사용하여 작동하는 POC가 있습니다).

트리 흔들기 문제를 해결하기 위해 babel-plugin-styled-components에 대한 PR을 열었습니다. 여기 누군가가 테스트를 돕고 싶다면 @mxstbr 이 그것을 환영할 것이라고 상상합니다(물론 저도 마찬가지입니다).
https://github.com/styled-components/babel-plugin-styled-components/pull/248

안녕하세요 여러분, 이 티켓은 현재 어디에 있습니까? 그것이 실제로 프로젝트가 v5에서 향하고 있는 방향이라면 MUI에 대한 몇 가지 스타일이 지정된 구성 요소를 작성하고 참여하게 되어 기쁩니다.

우리가 한 번에 이것을 하고 싶지 않다면 (나는 우리가 그것을 원하는지 의심스럽습니다). styled-components가 jss의 테마를 읽거나 jss가 styled-components의 테마를 읽도록 하는 것으로 시작해야 합니다. 목표는 구성 요소별로 스타일을 마이그레이션할 수 있다는 것입니다.

이것은 아마도 다른 분기에서 발생해야 합니다. 마스터의 모든 것을 한 번에 변경하고 싶지는 않지만 (v5에서) 한 번의 변경으로 릴리스해야 합니다. 그렇지 않으면 이것은 더욱 혼란스러워집니다.

댓글 삭제를 요청했습니다.

여러분, 저도 기여할 준비가 되었습니다... 별도의 브랜치를 하는 것이 현명한 것 같습니다... 해보자...!

@caprica-Six 에너지에 감사하지만 새 분기는 필요하지 않습니다. 우리는 스타일이 지정된 구성 요소 버전을 점진적으로 제공할 수 있어야 합니다(+ jss 및 감정)(v4 동안 불안정). 동시에 스타일이 지정되지 않은 스토리를 앞으로 이동할 수 있어야 합니다. 제출해야 하는 POC가 있습니다. Styled-components (v5 beta) + dynamic props는 우리가 JSS와 static 스타일을 가지고 있는 것보다 약간 느리지만 이것은 여전히 ​​허용되어야 합니다.

@oliviertassinari 우리가 참여할 수 있는 곳이 있습니까? 나는 어떤 일에 뛰어들기 전에 관리자가 나를 올바른 방향으로 안내해주기를 기다리고 있었습니다.

스타일 구성 요소보다 감정을 선호하지 않는 이유는 무엇입니까? 그 이유는 "[감정]을 소수의 사람들이 사용하는 것 같다. 다운로드 통계를 보면 80%가 동화책에서 나온다고?"라고 하는데 이것은 틀렸다. 그것은 styled-components( 비교 )보다 더 많이 사용되며 다운로드의 80%가 스토리북에서 오는 이유를 모르겠습니다. 확실히 동화책보다 훨씬 빠르게 성장하고 있습니다.

나는 스타일 구성 요소를 사용하는 데 지쳤고 (여러 문제로 인해) 대안을 찾았기 때문에 이 질문을 하고 감정을 발견했습니다. 나는 그것을 테스트했고 스타일이 지정된 구성 요소와 비교하여 장점만 찾았습니다.

더 가볍고 빠르며 더 많은 기능이 있습니다. 속성 전달, TypeScript 기본 제공(스타일 구성 요소에 비해 완벽하게 지원됨), 즉시 사용 가능한 Next.js SSR(_app. js 및 _document.js 파일, 처음 처리하는 데 1시간 소요)

게다가 styled-component보다 더 많이 사용되며 분명히 추진력이 있습니다.

@lcswillems 감성을 선호하는 분들을 위해 감성도 지원해야 한다고 생각합니다. 그러나 나는 그것이 기본값이어야한다고 생각하지 않습니다.

• "가벼운": 정확하지 않음: https://bundlephobia.com/[email protected](12.2kB ) vs https://bundlephobia.com/result?p=@emotion/ styled + https://bundlephobia.com/result?p=@emotion/core + https://bundlephobia.com/result?p=emotion-theming (공유 의존성을 고려하지 않은 13.1kB)
• "Next.js SSR out-of-the-box": 중요한 문제라고 생각합니다. 인라인

답변해 주시고 수정해주셔서 감사합니다.

• "라이터": 당신이 옳습니다
• "Next.js SSR 즉시 사용 가능": 이제 SSR을 즉시 사용 가능하게 만들 수 있는 이유와 수행 방식이 좋지 않은 이유를 이해합니다.
• "styled-components보다 더 많이 사용됨": 이것이 신뢰할 수 있는지 확실하지 않습니다. 그러나 내 출처도 신뢰할 수 없습니다.
• "더 빠름": 오래된 벤치마크만 보았으므로 아니오, 없습니다.

내가 직면한 주요 문제는 소품 전달/필터링입니다. https://github.com/styled-components/styled-components/issues/439 . 그것은 나에게 매우 자주 발생하며 매번 수동으로 필터링을 수행하는 것이 어렵습니다.

하지만 당신의 말을 보면 감정은 그다지 좋은 대안이 아닌 것 같습니다.

"가벼운": 정확하지 않음: https://bundlephobia.com/[email protected](12.2kB ) vs https://bundlephobia.com/result?p=@emotion/ styled + https://bundlephobia.com/result?p=@emotion/core + https://bundlephobia.com/result?p=emotion-theming (13.1 kB 없이

감정의 경우 css 소품 + @jsx pragma 대신 @emotion/styled 패키지를 사용하지 않을 가능성이 큽니다. 또한 emotion-theming 패키지가 필요하지 않을 수도 있습니다. ThemeContext 는 이미 @emotion/core 에 포함되어 있습니다. 따라서 12.2KB 대 6.5KB입니다.

인라인

궁금한 점이 있습니다. MUI가 아닌 구성 요소에 대한 @material-ui/styles 라이브러리 사용자에게 이러한 업데이트는 무엇을 의미합니까? 우리 회사에서는 이것을 styled-components 보다 의도적으로 선택한 대규모 내부 구성 요소 라이브러리의 기반으로 사용하고 있으며 매우 만족합니다.

@material-ui/styles 패키지에 대해 어떤 종류의 사용 중단이 계획되어 있는지 미리 확인하여 그에 따라 계획할 수 있다고 생각했습니다.

어쨌든, 당신이 계속 제공하는 모든 훌륭한 자료에 감사드립니다!

@nickjohnson-dev react-jss로의 마이그레이션은 간단해야 합니다. 조직에 효과가 있습니까?

@oliviertassinari 그럴 가능성이 높다고 생각합니다. 구성 요소 자체의 공개 API를 거의 동일하게 유지할 수 있는 한( classes prop 기반 로컬 재정의, 테마에서 가능한 전역 재정의) 구현 세부 정보를 변경하는 것이 문제라고 생각하지 않습니다.

MUI가 더 분리된 후 @material-ui/styles 에서 다른 스타일 옵션으로 마이그레이션하기 위한 공식 문서가 있을 것으로 예상합니까? 언뜻 보기에 @material-ui/styles 에서 활용하고 있는 react-jss 에 부족한 기능이 보이지 않지만 MUI 패키지가 수행하는 특별한 것이 누락되었는지 확실하지 않습니다. 무대 뒤에서.

@nickjohnson-dev 최선을 다하겠습니다.

내가 올바르게 이해하면 다음 문제가 발생합니다.
재사용 가능한 ComponentA 가 있습니다. $#$2 ComponentB 를 사용하는 ComponentA 를 만듭니다.

const ComponentA = ({className}) => (
  <div className={className}>
    <div className='inner' />
  </div>
);

const ComponentB = ({ className, classNameInner }) => (
  <div className={className}>
    <div className='inner'>
      <ComponentA className={classNameInner} />
    </div>
  </div>
)

const StyledComponentB = styled(ComponentB)`
     ???
`;

ComponentA 및 ComponentB 에 동일한 className='inner' $ 가 있는 요소가 있는지 확인하세요. ComponentB 에서만 .inner 요소를 타겟팅하려면 어떻게 해야 합니까?

@oliviertassinari님 , 안녕하세요, Material UI의 다음 버전을 위한 스타일링에 대한 모든 생각을 공유해주셔서 감사합니다.

그리고 Material UI에도 감사드립니다. 지금은 그 위에 디자인 시스템을 구축하고 있습니다.

styled-components 채택에 관해서는 이미 결정된 사항이며 그 목표를 향한 작업은 이미 시작된 것 같습니다.

그러나 @croraf 와 @lcswillems 가 관찰한 내용 중 일부를 공유합니다.

현재 머티리얼 UI 스타일링에서 좋은 점은 classes 속성입니다.

classes 입력이 공용 인터페이스의 일부이기 때문에 스타일 사용자 정의 및 유지 관리에 많은 도움이 되는 간단한 아이디어입니다. 예를 들어, 무언가를 사용자 정의해야 하고 & .Component-root 와 같은 선택기를 사용하는 경우 Component 가 버전 간에 해당 CSS 클래스를 유지한다는 보장은 없습니다. 적어도 <Component classes={{root: ....}} /> 가 있으면 인터페이스 변경에 대한 유형 검사 오류(TypeScript를 사용하는 경우)가 발생할 수 있습니다.

구성 요소 작성자로서 저는 공개된(지원되는) 클래스를 문서화하고 나머지는 문서화하지 않은 상태로 둘 수 있습니다.

style-components 를 약 2년 동안 사용했습니다. 대중적이고 많이 발전한 것이 사실입니다. 그러나 MUI 문서 예제에서 @crod 가 언급한 것과 동일한 문제를 봅니다. 하위 구성 요소에 스타일을 전파할 수 있기 때문에 하위 선택자 & .inner 를 사용하는 것은 매우 취약합니다(내 경험에 따르면 그것은 코너 케이스가 아닙니다 ... 그것은 나에게 몇 번 일어났습니다). 두 가지 가능한 솔루션은 다음과 같습니다.

• &.inner 를 사용한 다음 모든 곳에서 ${props.className}.inner 를 사용합니다. 나는 그것을 여러 번했고 쓰기가 고통 스럽습니다.
• > .inner 를 사용하지만 구성 요소 구조에 따라 다릅니다. 중간에 div 를 추가하면 끊어집니다.

JSS가 인기가 없는 것은 사실입니다. 나는 MUI 때문에 그것에 대해 배웠습니다. 그러나 styled-components 로 오랜 시간 작업한 후 MUI 스타일의 접근 방식이 신선하고 작업하기가 더 쉽다는 것을 알았습니다. HOC ... 적어도 그것은 내 개인적인 경험입니다). 감정은 현재 접근 방식과 다소 일치합니다. 그리고 귀하의 의견과 특정 경우에 JSS 성능에 대한 몇 가지 문제를 읽은 후 디자인 시스템에 감정을 사용할지 평가하고 있습니다.

그러나 styled-components 에 대해 확신을 갖고 있는 것을 보니 classes 소품을 사용하여 스타일 사용자 정의를 해결하는 방법에 대한 더 많은 예를 보고 싶습니다. 현재 MUI 문서에서 사용할 수 있는 문서는 위에서 언급한 문제를 공유합니다.

클래스 소품과 함께 styled-components 를 사용하는 다른 방법이 있습니까? 그것에 대해 어떻게 생각하세요?

JSS는 충분히 훌륭하고 사용하기 매우 편리합니다. 이사를 가야 하는 강력한 이유가 있습니까?

개인적으로 나는 styled-component가 일종의 후퇴라고 생각하고 JSS가 내가 정직하게 이 라이브러리를 사용하기 시작한 주된 이유라고 생각합니다.

@powerfulj 스타일 구성 요소보다 JSS를 선호하는 이유는 무엇입니까? 나는 두 가지 중 하나를 선택해야 했고 style-components가 나에게 더 나은 것 같았습니다.

@lcswillems
나는 그것이 새로운 구성 요소를 도입하지 않고 대신 속성에 대해 작동한다고 생각하기 때문에 그것을 좋아합니다. 스타일이 지정된 재사용 가능한 새 구성 요소가 정말로 필요한 경우 JSS 솔루션으로 쉽게 만들 수 있습니다.

또한 인라인 스타일에서 JSS 스타일로 변환하는 것이 더 빠릅니다. 일반적으로 구현 중에 인라인 스타일을 사용하고 더 커지고 재사용되면 JSS로 변환하기 때문에 저에게 편리합니다.

부정적인 측면은 (브라우저 devtools에서와 같은) CSS가 있고 이를 JSS로 변환해야 하는 경우 구문을 조정하는 데 더 많은 시간을 소비해야 한다는 것입니다. styled-component를 사용하면 더 빠르게 진행됩니다.

이 문제에 대한 내 발견을 공유하기 위해.
#16947에서 요구하는 대로 일부 데모를 styled-components로 마이그레이션하려고 했습니다. 문제는 기본 테마입니다. makeStyles 는 defaultTheme를 전달할 수 있는 옵션을 허용합니다. defaultTheme 를 제공하는 makeStyles 래퍼가 있습니다. 그런 다음 useStyles hook 은 ThemeProvider 가 테마를 제공하는지 확인하고, 그렇지 않으면 defaultTheme 를 주입합니다.

styled-components에는 그러한 기능이 없는 것 같습니다. ThemeProvider 가 없으면 defaultTheme는 .attrs 메서드로만 주입할 수 있습니다. makeStyles 래퍼와 유사한 것을 만들 수 있습니다.

import styledWithoutDefault from 'styled-components';
import defaultTheme from './defaultTheme';

const styled = Component => {
  return styledWithoutDefault(Component).attrs({ theme: defaultTheme });
};

export default styled;

그러나 .attrs 메서드는 ThemeProvider 제공하는 테마를 덮어씁니다. 그리고 저는 현재 이 문제를 해결하는 방법을 모릅니다.

또 다른 문제는 makeStyles 가 jss-plugin-default-unit 사전 설정을 사용하고 styled-components가 아닌 것 같습니다. 따라서 styled-components는 spacing() 함수의 값을 반환하기 위해 px 를 추가하지 않습니다.
마지막 문제에 대한 가능한 해결책은 styled-components가 아닌 Styled-JSS를 사용하는 것입니다.

여기에 귀하의 아이디어/제안이 있어 기쁩니다.

@fyodore82 .attrs 는 함수로 작동하므로(https://www.styled-components.com/docs/api#attrs 참조) 다음을 수행합니다.

```js
.attrs(({ 테마 = defaultTheme, ...props }) => ({ ...props, 테마 }))
````

@croraf

나는 그것이 새로운 구성 요소를 도입하지 않고 대신 속성에 대해 작동한다고 생각하기 때문에 그것을 좋아합니다.

Styled-components: css prop 의 정말 좋은 점을 놓쳤다고 생각합니다. CSS를 새로 만들 필요 없이 구성 요소에 CSS를 추가할 수 있습니다.

또한 인라인 스타일에서 JSS 스타일로 변환하는 것이 더 빠릅니다. 일반적으로 구현 중에 인라인 스타일을 사용하고 더 커지고 재사용되면 JSS로 변환하기 때문에 저에게 편리합니다.

CSS prop을 사용하는 경우 CSS prop이 있는 구성 요소에는 style 속성이 없고, 이미 스타일이 지정된 구성 요소로 변환되어 있으므로 class 가 있습니다. CSS가 더 커지고 재사용되면 새 구성 요소를 만들 수도 있습니다.

부정적인 측면은 (브라우저 devtools에서와 같은) CSS가 있고 이를 JSS로 변환해야 하는 경우 구문을 조정하는 데 더 많은 시간을 소비해야 한다는 것입니다. styled-component를 사용하면 더 빠르게 진행됩니다.

동의한다. 이것이 내가 그것을 사용하지 않은 주된 이유입니다. 온라인으로 작성된 CSS의 대부분은 JSS가 아닌 CSS로 작성됩니다. 따라서 StackOverflow의 일부 코드를 사용하려면 먼저 JSS로 변환해야 합니다. 이는 매우 고통스러운 작업입니다.

Styled-components를 사용하게 만든 다른 추가 인수:

• JSS를 작성하는 것이 더 고통스럽습니다. 따옴표를 추가해야 하고 구문 강조 표시가 없습니다(또는 찾을 수 없음).
• 초보자에게는 이해하기 어렵습니다. 모두가 CSS를 알고 있으므로 JSS의 경우가 아닌 Styled 구성 요소로 코드를 쉽게 읽을 수 있습니다(JSS 구문은 일반적으로 약간 이상하고 특히 의사 선택기 및 미디어 쿼리의 경우).
• 코드 가독성이 훨씬 떨어집니다. 이 점을 설명하기 위해 Styled 구성 요소로 이 Card 구성 요소 예제 를 다시 작성하여 얼마나 더 명확하게 사용할 수 있는지 보여줍니다.

JSS 버전:

import React from 'react';
import { makeStyles, useTheme } from '@material-ui/core/styles';
import Card from '@material-ui/core/Card';
import CardContent from '@material-ui/core/CardContent';
import CardMedia from '@material-ui/core/CardMedia';
import IconButton from '@material-ui/core/IconButton';
import Typography from '@material-ui/core/Typography';
import SkipPreviousIcon from '@material-ui/icons/SkipPrevious';
import PlayArrowIcon from '@material-ui/icons/PlayArrow';
import SkipNextIcon from '@material-ui/icons/SkipNext';

const useStyles = makeStyles(theme => ({
  card: {
    display: 'flex',
  },
  details: {
    display: 'flex',
    flexDirection: 'column',
  },
  content: {
    flex: '1 0 auto',
  },
  cover: {
    width: 151,
  },
  controls: {
    display: 'flex',
    alignItems: 'center',
    paddingLeft: theme.spacing(1),
    paddingBottom: theme.spacing(1),
  },
  playIcon: {
    height: 38,
    width: 38,
  },
}));

export default function MediaControlCard() {
  const classes = useStyles();
  const theme = useTheme();

  return (
    <Card className={classes.card}>
      <div className={classes.details}>
        <CardContent className={classes.content}>
          <Typography component="h5" variant="h5">
            Live From Space
          </Typography>
          <Typography variant="subtitle1" color="textSecondary">
            Mac Miller
          </Typography>
        </CardContent>
        <div className={classes.controls}>
          <IconButton aria-label="previous">
            {theme.direction === 'rtl' ? <SkipNextIcon /> : <SkipPreviousIcon />}
          </IconButton>
          <IconButton aria-label="play/pause">
            <PlayArrowIcon className={classes.playIcon} />
          </IconButton>
          <IconButton aria-label="next">
            {theme.direction === 'rtl' ? <SkipPreviousIcon /> : <SkipNextIcon />}
          </IconButton>
        </div>
      </div>
      <CardMedia
        className={classes.cover}
        image="/static/images/cards/live-from-space.jpg"
        title="Live from space album cover"
      />
    </Card>
  );
}

스타일 구성 요소 버전:

import React from 'react';
import styled from 'styled-components';
import { useTheme } from '@material-ui/core';
import MuiCard from '@material-ui/core/Card';
import MuiCardContent from '@material-ui/core/CardContent';
import MuiCardMedia from '@material-ui/core/CardMedia';
import IconButton from '@material-ui/core/IconButton';
import Typography from '@material-ui/core/Typography';
import SkipPreviousIcon from '@material-ui/icons/SkipPrevious';
import MuiPlayArrowIcon from '@material-ui/icons/PlayArrow';
import SkipNextIcon from '@material-ui/icons/SkipNext';

export default function MediaControlCard() {
  const theme = useTheme();

  return (
    <Card>
      <Details>
        <CardContent>
          <Typography component="h5" variant="h5">
            Live From Space
          </Typography>
          <Typography variant="subtitle1" color="textSecondary">
            Mac Miller
          </Typography>
        </CardContent>
        <Controls>
          <IconButton aria-label="previous">
            {theme.direction === 'rtl' ? <SkipNextIcon /> : <SkipPreviousIcon />}
          </IconButton>
          <IconButton aria-label="play/pause">
            <PlayArrowIcon />
          </IconButton>
          <IconButton aria-label="next">
            {theme.direction === 'rtl' ? <SkipPreviousIcon /> : <SkipNextIcon />}
          </IconButton>
        </Controls>
      </Details>
      <CardMedia
        image="/static/images/cards/live-from-space.jpg"
        title="Live from space album cover"
      />
    </Card>
  );
}

const Card = styled(MuiCard)`
  display: flex;
`

const Details = styled.div`
  display: flex;
  flex-direction: column;
`

const CardContent = styled(MuiCardContent)`
  flex: 1 0 auto;
`

const CardMedia = styled(MuiCardMedia)`
  width: 151px;
`

const Controls = styled.div`
  display: flex;
  align-items: center;
  padding-left: ${props => props.theme.spacing(1)}px;
  padding-bottom: ${props => props.theme.spacing(1)}px;
`

const PlayArrowIcon = styled(MuiPlayArrowIcon)`
  height: 38px;
  width: 38px;
`

마지막으로 JSS를 사용하는 이점을 찾지 못했습니다.

css 속성은 매우 훌륭하고 기본적으로 내가 언급한 단점을 해결합니다. (copycats form styled-components :D )

두 가지 예의 비교와 관련하여 읽기가 쉽지 않으며 구성 요소 수가 두 배로 늘어납니다.

@lcswillems

하나의 솔루션 또는 다른 솔루션에 대해 논쟁하지 않고 몇 가지 요점을 선택하십시오.

StackOverflow의 일부 코드를 사용하려면 먼저 JSS로 변환해야 합니다. 이는 매우 고통스럽습니다.

항상 완벽하게 작동하는 것은 아니지만 CSS를 CSS-in-JS로 변환하기 위한 VSCode 확장이 있습니다. 그럼에도 불구하고 나는 그것을 고통스럽게 부르지 않을 것입니다.

구문 강조 표시가 없습니다.

저는 이 주장이 잘 이해가 되지 않습니다. JS 개체일 뿐이므로 모든 편집기의 구문 강조 표시가 작동합니다.

(하지만 아마도 당신은 더 구체적인 것을 찾고 있습니까?)

두 예제의 비교와 관련하여 훨씬 더 읽기 쉽지 않습니다. className props의 부족은 틀림없이 깨끗하지만 구성 요소가 MUI 기본 구성 요소를 참조하는지 아니면 styled() 구성 요소를 상호 참조할 필요 없이 스타일이 변경된 구성 요소를 참조하는지 기본 JSX 코드 블록에서 명확하지 않습니다. 더 큰 구성 요소에서는 이것들을 멀리 제거할 수 있습니다.

styled() 호출은 (저를 위해) JSS 객체보다 읽기가 어렵습니다.

@powerfulj 스타일 구성 요소보다 JSS를 선호하는 이유는 무엇입니까? 나는 두 가지 중 하나를 선택해야 했고 style-components가 나에게 더 나은 것 같았습니다.

저는 Typescript 개발자이고 Typescript 개체에서 모든 것을 빌드하는 것을 선호하기 때문입니다. 특히 나는 스트링을 싫어한다.

차이점 때문에 CSS 코드를 JSS 코드로 전송해야 하지만 구조가 기존 CSS(클래스 지향)처럼 보이기 때문에 여전히 JSS 코드를 읽는 것을 선호합니다. 여기 저기에 있을 수 있습니다.

나는 사람들이 과거에 Styled-component에 대한 경험이 있기 때문에 이러한 변경을 주장했다고 ​​생각합니다. "우리에게 익숙하지만 뚜렷한 이점이 없는 라이브러리를 선택하는 것은 어떨까요?"라는 느낌을 줍니다.

내 관점에서 JSS는 그냥 편리한 것 같습니다. 우리는 다음과 같은 모든 Javascript 방식을 사용하여 객체를 구성할 수 있습니다

{
...공유JSS1,
...공유JSS2,
무엇이든
}

또한 유형과 통합된 매끄러운 동적 테마가 있으며 className 및 css 유형 모두에서 모든 유형 힌트를 얻었습니다.

새로운 개발자의 경우 특히 Typescript 개발자는 단순히 JSS를 좋아할 것입니다.

참고로, 모든 항목에 대해 항상 별도의 구성 요소를 원하지 않는 경우 스타일이 지정된 구성 요소에서 일부 중첩을 수행할 수 있습니다. 의미 있는 이름을 가진 별도의 구성 요소를 사용하는 것이 styled-components 철학에 따라 더 깨끗하고 읽기 쉬운 것으로 간주되기 때문에 일반적으로 권장되지 않지만 문서에서는 "적게 사용"하면 괜찮다고 말합니다. 그리고 물론 그 철학을 공유하지 않는 사람은 더 많은 중첩을 자유롭게 할 수 있습니다. 중첩이 의미하는 바의 예는 다음과 같습니다.

const Wrapper = styled.div`
  display: block;

  .inner {
    flex: 1;
  }
`

...
  <Wrapper>
    <div class="inner">...</div>
  </Wrapper>

자세한 내용은 https://www.styled-components.com/docs/faqs#can -i-nest-rules를 참조하세요.

코딩 스타일 기본 설정에 대한 토론은 영원히 계속될 수 있습니다.

잠시 동안 styled-components 를 사용한 후 다음과 같은 이유로 JSS 접근 방식이 더 마음에 듭니다.

• 스타일이 길어지면 보통 별도의 파일로 이동합니다.
  styled-components 로도 그렇게 했고 useStyles / makeStyles 가 쓰기, 읽기 및 유지 관리가 더 쉽다는 것을 알았습니다. 예. import useStyles from './MyComp.styles' vs import {XStyled, YStyled,...} from './MyComp.styles' ... TS에서 입력하는 ...Styled 변형을 유지하는 것은 성가신 일입니다.
• 저는 점진적으로 일을 하는 경향이 있습니다. 먼저 div와 클래스를 사용하여 초안으로 시작한 다음 구성 요소로 리팩토링합니다. styled-components 를 사용할 때 내부 클래스를 사용하여 수행하지만(@mbrowne의 예에서와 같이) 더 많은 리팩토링 작업이 필요합니다. 저는 useStyles 접근 방식이 해당 워크플로를 사용하는 데 훨씬 더 편안하다는 것을 알았습니다.
• 템플릿 리터럴은 CSS 코드를 붙여넣는 데 좋지만 테마/소품 변수를 사용해야 하는 경우에는 끔찍합니다. 붙여넣기 코드 문제는 플러그인으로 해결하기 쉽지만 템플릿 리터럴 내부의 변수와 함수로 편집하는 것은 그리 많지 않습니다.

하지만 이건 제 개인적인 취향이니 여러분들의 취향은 다를 수 있습니다.

가장 큰 미해결 질문은 변경 사항에 대한 classes 사용입니다.

className 및 내부 클래스를 사용하는 예에는 문제가 있습니다(이전 의견 참조). $# styled-components 의 css 소품은 이러한 문제를 해결하는 옵션이 아닙니다. 감정의 css 함수와 달리 css 소품은 구성 요소에 연결되어 있어야 합니다(즉, useStyle/makeStyles/classes 코드 스타일에서는 사용할 수 없음).

구성 요소에 스타일을 추가하는 것은 사소한 디자인 결정이 아닙니다. 나에게 그것은 JSS의 좋은 점과 나쁜 점입니다. 스타일 구성 요소와 감정은 Babel 플러그인에 의존하고 SSR에 대한 캐싱 및 클래스 이름 생성을 처리하기 위해 React와 상호 작용합니다. JSS의 좋은 점은 Babel 플러그인이 필요하지 않다는 것입니다. 나쁜 부분은 JSS의 SSR이 더 많은 작업을 필요로 하고 그 영역에서 보고된 버그를 본 적이 있다는 것입니다.

MUI로 돌아가서 스타일 구성 요소를 채택한다는 것은 스타일을 사용자 정의하는 유일한 방법으로 className 및 내부 클래스를 사용하는 것을 의미한다는 인상을 받았습니다. 스타일은 프레임워크 전체에서 더욱 일관됩니다. 구성 요소가 className 를 사용하는 한 styled 또는 css 소품을 사용할 수 있습니다.

그러나 나에게 classes 소품을 제거하는 것은 뒤로 물러나는 것입니다. 이 소품은 검사 스타일 사용자 정의를 문서화하고 입력하는 데 도움이 됩니다. styled-components를 사용하지만 classes 에 대한 지원을 유지하는 것과 같이 중간 지점을 찾는 것이 가능할 수도 있습니다(내부 클래스 해킹 필요 없이). 그런 경우에 도움이 되는 styled-components API에서 아무 것도 찾을 수 없었습니다. 그렇기 때문에 JSS의 기술적 문제가 무엇인지 평가하는 것이 좋을 수 있습니다. 인기가 주요 문제라면 감정도 대중화되고 있으며(https://2019.stateofcss.com/technologies/css-in-js/#tools-section-overview 참조) makeStyles 다시 작성합니다.

@dfernandez-asapp 이 fwiw @styled-components는 https://www.styled-components.com/docs/advanced# 문자열 대신 jss와 유사한 개체 사용을 지원합니다.

스타일이 지정된 구성 요소가 일급 유형 스크립트 지원을 제거한 것이 상당히 실망스럽긴 하지만 전반적으로 귀하가 설명한 다른 방식으로 한 걸음 물러난 것처럼 보인다는 데 동의합니다.

참고로, 모든 항목에 대해 항상 별도의 구성 요소를 원하지 않는 경우 스타일이 지정된 구성 요소에서 일부 중첩을 수행할 수 있습니다. 의미 있는 이름을 가진 별도의 구성 요소를 사용하는 것이 styled-components 철학에 따라 더 깨끗하고 읽기 쉬운 것으로 간주되기 때문에 일반적으로 권장되지 않지만 문서에서는 "적게 사용"하면 괜찮다고 말합니다. 그리고 물론 그 철학을 공유하지 않는 사람은 더 많은 중첩을 자유롭게 할 수 있습니다. 중첩이 의미하는 바의 예는 다음과 같습니다.

const Wrapper = styled.div`
  display: block;

  .inner {
    flex: 1;
  }
`

...
  <Wrapper>
    <div class="inner">...</div>
  </Wrapper>

자세한 내용은 https://www.styled-components.com/docs/faqs#can -i-nest-rules를 참조하세요.

이에 대한 지원 유형이 있습니까? 아니면 모든 곳에 문자열을 넣어야 합니까?

스타일이 지정된 구성 요소에 대해 왜 그렇게 많은 과대 광고가 있는지 이해할 수 없습니다. 정직하게 한 발짝 물러난 느낌입니다. TypeScript를 사용하는 JSS의 유형이 지정된 CSS 속성은 훨씬 더 편리하고 유지 관리가 더 쉬우며 JS의 일부로 구문 검사가 있습니다. 최신/구성된 편집기는 오타가 있는지 알려주고 원하는 경우 자동 완성을 도와줍니다.

편집: 입력되었습니다. 아래 South-Paw의 답변을 참조하세요.

@martinjlowm 이 나에게 타이핑을 한 것 같습니까?

참조: https://styled-components.com/docs/advanced#style -objects

당신은 과대 광고를 이해하지 못한다고 말하지만... 저도 그것이 받는 모든 증오를 이해하지 못합니다. 🤷‍♂

감정 및 스타일 구성 요소는 CSS 스타일 개체에 비해 크게 개선되었습니다. IMO

@martinjlowm 이 나에게 타이핑을 한 것 같습니까?

...

참조: https://styled-components.com/docs/advanced#style -objects

당신은 과대 광고를 이해하지 못한다고 말하지만... 저도 그것이 받는 모든 증오를 이해하지 못합니다. 🤷‍♂

감정 및 스타일 구성 요소는 CSS 스타일 개체에 비해 크게 개선되었습니다. IMO

내가 참조! 나는 그것이 그런 객체를 지원한다는 것을 알지 못했습니다. 내 관심사는 템플릿 문자열의 CSS와 관련이 있지만 개체가 옵션이라면 반대할 것이 없습니다!

분명히 JSS도 완벽하지 않습니다. 재사용 가능한 서버 생성 시트가 ​​킬러 기능이 될 것이라는 것을 압니다. styled-component는 어떻게든 이를 지원합니까? 아는 사람 있나요?

지금 당장은 서버에서 생성한 스타일시트를 삭제하고 클라이언트가 모든 스타일을 다시 렌더링하도록 하는 것은 어리석은 일입니다.

@martinjlowm 이 나에게 타이핑을 한 것 같습니까?
...
참조: https://styled-components.com/docs/advanced#style -objects
당신은 과대 광고를 이해하지 못한다고 말하지만... 저도 그것이 받는 모든 증오를 이해하지 못합니다. 🤷‍♂
감정 및 스타일 구성 요소는 CSS 스타일 개체에 비해 크게 개선되었습니다. IMO

내가 참조! 나는 그것이 그런 객체를 지원한다는 것을 알지 못했습니다. 내 관심사는 템플릿 문자열의 CSS와 관련이 있지만 개체가 옵션이라면 반대할 것이 없습니다!

분명히 JSS도 완벽하지 않습니다. 재사용 가능한 서버 생성 시트가 ​​킬러 기능이 될 것이라는 것을 압니다. styled-component는 어떻게든 이를 지원합니까? 아는 사람 있나요?

지금 당장은 서버에서 생성한 스타일시트를 삭제하고 클라이언트가 모든 스타일을 다시 렌더링하도록 하는 것은 어리석은 일입니다.

또한 태그가 지정된 템플릿 리터럴도 입력할 수 있음을 명확히 하고 싶습니다. TypeScript는 잘못된 것으로 올바르게 표시하고 언어 서비스는 자동 완성 제안 등을 제공합니다.

@좌완 투수

감정 및 스타일 구성 요소는 CSS 스타일 개체에 비해 크게 개선되었습니다. IMO

나는 여전히 어떤 React 개발자가 이것에 참여하는지 혼란스럽습니다. CSS를 템플릿 문자열에 넣으려면 Angular를 사용하고 HTML도 템플릿 문자열에 넣지 않습니까? React의 장점은 JSX 요소가 실제로는 검사하고 변환할 수 있는 엄청난 권한이 있는 JS 객체이며 JSS도 마찬가지라는 것입니다.

JS 움직임에서 CSS를 주도하는 모든 것은 JS가 동적 작업을 수행하는 CSS보다 훨씬 뛰어나고 JS 객체의 힘이 작은 부분이 아니라는 사실입니다.

styled-components 가 객체를 지원한다는 사실은 일종의 붉은 청어입니다.

• 그것은 그것들을 지원하지만 어떤 이유로 "이것은 기존 스타일 개체가 있고 점차적으로 스타일이 지정된 구성 요소로 이동하려는 경우에 특히 유용합니다."라고 말합니다. 그들은 분명히 객체를 조작할 수 있다는 가치를 보지 못하고 스타일 객체가 API에서 항상 2급 시민으로 취급되는 것처럼 들립니다.
• 문서는 JSS에서 다음과 같은 실제 CSS 선택기를 지원하는지 명확하지 않습니다.

{
  color: 'black',
  '&$error': {
    color: 'red'
  }
}

심지어 감정은 스타일 개체의 가치를 존중하고 이를 일류 시민으로 취급합니다.

사물로 스타일을 쓰는 것은 감정의 핵심에 직접 구축된 강력한 패턴입니다.

@lcswillems 당신은 이 모든 작은 HOC를 항상 생성하는 것이 얼마나 번거로운지 과소평가하고 있습니다(그리고 대부분의 자동 가져오기 시스템이 @material-ui/core/Card 를 Card 로 가져올지 여부를 알만큼 똑똑하지 않다는 사실) MuiCard (그리고 여전히 import 문을 직접 작성하는 경우 시간을 심각하게 낭비하고 있는 것입니다))

const Card = styled(MuiCard)`
  display: flex;
`

const Details = styled.div`
  display: flex;
  flex-direction: column;
`

const CardContent = styled(MuiCardContent)`
  flex: 1 0 auto;
`

const CardMedia = styled(MuiCardMedia)`
  width: 151px;
`

이러한 종류의 일은 각 래퍼와 래핑된 구성 요소의 이름을 지정하는 방법을 지속적으로 결정해야 하므로 끔찍한 결정 피로를 유발합니다.

이것이 @dfernandez-asapp이 다음과 같이 말할 때 말하는 것입니다.

(잠시 후에 Styled HOC를 사방에 두는 것은 많은 추가 작업을 추가하고 나는 그 HOC를 싫어하기 시작했습니다... 적어도 그것은 제 개인적인 경험입니다)

HOC는 거의 죽어야 합니다. 구식 패턴입니다. 예를 들어, react-redux 는 connect HOC보다 100배 더 편리한 useSelector 후크와 함께 나왔고 Apollo는 HOC에서 후크로 이동했으며 useStyles 도 마찬가지입니다. 이 라이브러리의 withStyles 보다 더 편리합니다.

복사하여 붙여넣은 CSS를 JSS로 변환하는 번거로움은 훨씬 더 해결할 수 있는 문제입니다. 관심이 있다면 자동화 또는 웹사이트를 위한 VSCode 확장을 만들 수도 있습니다.

관심이 있다면 자동화를 위해 VSCode 확장을 만들 수도 있습니다.

@jedwards1211 paulmolluzzo.convert-css-in-js 가 있지만 JSS용으로 개선할 수 있다면 환영할 것이라고 확신합니다.

예, 확실히 개선할 수 있는 것 같습니다. 규칙과 선택기가 아닌 CSS 속성만 변환합니다.

@jedwards1211 나는 당신이 말한 것을 읽고 잠시 이 모든 것에서 한 걸음 물러서서 공백 위에 탭을 사용하는 것에 대해 논쟁하는 사람들의 댓글을 생각나게 합니다. 실제로는 마지막에 유용한 제품을 생산하기만 하면 무엇을 사용하든 차이가 없습니다.

Twitter 또는 Reddit에 의견/핫 테이크를 남겨주시면 거기서 토론할 수 있습니다. 하지만 템플릿 문자열과 CSS 개체에 대한 무의미한 불꽃 전쟁으로 이 문제를 계속 탈선시키지 말자... 우리 모두가 우리가 더 낫다는 데 동의할 수 있다고 생각합니다. 그것보다 😄

MUI에서 현상 유지를 변경할 가치가 없다는 점을 지적해주셔서 감사합니다. 😉

내 주요 관심사는 내 webpack 번들이 styled-components 코드와 JSS 코드의 혼합으로 부풀어 오르는 것입니다. 왜냐하면 앱에 기존 JSS가 너무 많아서 다른 것으로 대체하거나 빼내고 싶기 때문입니다. 어쨌든 우리 스타일을 위한 JSS.

공정하게 말해서, 나는 탭과 공백에 대해 신경 쓰지 않지만, 내가 만드는 각 구성 요소에 대해 6개의 HOC를 작성해야 한다면 내 일을 즐기지 못할 것입니다. 존재하는 모든 도구에는 유용한 제품을 생산할 수 있는 기능이 있습니다. 모든 경우에 사용하기에 정말 완벽하게 편리한 것이 있다면 생태계에 끊임없는 변화가 없을 것이고 우리는 이러한 논쟁을 하지 않을 것입니다. 그래서 생각해보면 정말 차이가 납니다.

@jedwards1211 강제로 Styled Components를 사용해야 하는 경우에도 v4 에 도입된 대체 css prop 구문이 있습니다. 사용할 수 있습니다. 최소한 이렇게 하면 걱정할 필요가 없습니다. 스타일이 지정된 구성 요소(MuiCard, StyledCard 등)에 접두사를 제공합니다.

import { Avatar } from '@material-ui/core';

// CSS is separate from the markup 👍
const avatarStyle = css`
  width: 32px;
  height: 32px;
  border-radius: 50%
`;

// No wrappers, prefixes in the markup (such as <MuiAvatar>, <StyledAvatar> etc.) 👍
function SomeComponent(props) {
  return <div> ... <Avatar css={avatarStyle} /> ... </div>
}

@jedwards1211 스타일이 지정된 구성 요소를 사용하는 경우 예제를 다음과 같이 단순화할 수도 있습니다.

const Card = styled(MuiCard)`
  display: flex;

  ${MuiCardContent} {
    flex: 1 0 auto;
  }

  ${MuiCardMedia} {
    width: 151px;
  }
`

const Details = styled.div`
  display: flex;
  flex-direction: column;
`

@koistya css 소품은 멋진 편이지만, 중요한 주의 사항은 이것이 Babel 플러그인으로 구현되어 모든 사람, 특히 tsc를 사용하여 tsx 파일을 컴파일하는 사람들을 위한 것은 아닙니다. 또한 TypeScript 또는 적어도 Flow가 구성 요소에 css 소품이 없다고 불평하게 한다고 가정합니다.

나는 이것이 내 앱에서 발생할 수 있는 잠재적인 중단에 대해 주로 불행하다고 생각합니다. @oliviertassinari 는 전에 MUI v5에서 styled-components 를 기본값으로 만드는 것에 대해 생각하고 있다고 언급했습니다. 그리고 그것은 선택 사항이길 바라고 JSS를 계속 사용할 수 있지만 우리는 그들이 그것을 해낼 수 있는지 보게 될 것입니다. 그것은 충격이었습니다. 전체 사용자 기반의 선호도에 대한 철저한 국민 투표가 실제로 있었습니까? 지금은 훨씬 더 대중적이기 때문에 나는 감정을 기대했을 것입니다.

또한 TypeScript 또는 적어도 Flow가 구성 요소에 CSS 소품이 없다고 불평하게 할 것이라고 가정합니다.

구성할 수 있습니다.

전체 사용자 기반의 선호도에 대한 철저한 국민 투표가 실제로 있었습니까?

이건 불가능 해. GitHub에 참여하는 사람들이 "우리" 사용자라고 가정할 수 있습니다. 이 문제는 우리가 가진 가장 많은 투표 를 받은 문제입니다.

지금은 훨씬 더 대중적이기 때문에 나는 감정을 기대했을 것입니다.

인기도는 어떻게 측정했나요?

⚠️ 감정은 스타일이 지정된 구성 요소보다 개발자가 훨씬 덜 선택합니다(제 기억으로는 /6). npm에서의 다운로드를 고려한다면 스토리북을 제거하고 반응 선택 다운로드 수(엄청난 수)를 선택하십시오.

@eps1lon 은 내가 보고 있던 것입니다: https://2019.stateofcss.com/technologies/css-in-js/

내가 틀렸지만 불행히도 이것이 시간이 지남에 따라 인기있는 차트는 아니지만 (매우 의심스러운 차트 디자인) 상승 추세 만 기억했습니다.

구성 가능

실제로 TypeScript가 모든 JSX 요소가 css 소품을 지원한다고 가정하도록 하는 방법이 있습니까? 그렇게 하도록 Flow를 구성하는 방법을 모르겠습니다.

편집 : 다행스럽게도 TypeScript에 대한 방법을 찾았지만 Flow에 대한 방법이 있는지 확실하지 않습니다.

이 문제는 우리가 가진 것 중 가장 많은 투표를 받은 문제입니다.

내가 참조. 한숨을 쉬다

styled-components 의 주요 기여자 중 하나인 FWIW는 유형 시스템에 대해 비우호적인 태도를 보이는 것 같습니다.

https://github.com/styled-components/styled-components/issues/3012#issuecomment -583878486

스타일 구성 요소가 TS/Flow 사용자의 개발 경험에 관심이 있는 것처럼 보인다면 스타일이 지정된 구성 요소로 마이그레이션하는 아이디어에 대해 훨씬 더 안심할 수 있습니다...

@jedwards1211 도움이된다면 css 에 대한 Babel 매크로가 있습니다. 특히 css/scss/less에서 나오는 모든 사람들이 "스타일링된" 방식으로 이동하는 것을 좋아하지 않는다고 생각합니다.

목표는 무엇입니까? 성능은 어떻습니까? 예를 들어 일부 시스템은 원자 CSS를 지원합니다. Tailwinds에서 제공하므로 훨씬 더 깨끗하고 빨라질 수 있습니다.

@hc-codersatlas packages/material-ui-benchmark 에서 몇 가지 벤치마크를 찾을 수 있습니다.

@koistya 제대로 읽으면 감정이 다른 것보다 훨씬 빨리 보입니다.

@oliviertassinari 대부분의 개발자가 실제로 이 선택을 "선택"합니까? react-select 및 스토리북에 대한 귀하의 언급에 따라 대부분의 개발자는 UI 구성 요소와 함께 번들로 제공되는 모든 것을 사용할 가능성이 높으며 material-ui가 큰 1이 됩니다. UI 프레임워크가 이미 사용하고 있는 것 외에 다른 시스템으로 더 많은 노력을 기울입니다.

이러한 UI 프레임워크의 대부분은 대기업에서 가져온 것입니다. 즉, 소수의 사람들이 실제로 이 "선택"을 하고 있습니다.

예를 들어 그로밋은 많은 회사들이 1포인트에서 사용하고 있던 styled-components를 사용합니다.

그리고 그 메모에서 npm 다운로드는 무엇을 의미합니까? 회사 사용은 방화벽 및 내부 npm 캐싱을 의미할 수 있으며, 이는 이러한 메트릭을 왜곡합니다.

변화가 있다면 인기보다는 기술적인 면에서 베스트 1로 바꿔주세요. 나는 material-ui가 어떤 라이브러리를 사용하든 mui 자체가 가장 인기 있는 ui 프레임워크 중 하나이기 때문에 인기 있는 1이 될 것이라고 예측합니다.

@South-Paw 제안한 단순화가 작동하지 않습니다. MuiCardContent 는 스타일이 지정된 구성 요소가 아니기 때문에 예제에서 ${MuiCardContent} 를 사용할 수 없습니다.

https://styled-components.com/docs/advanced#referring -to-other-components

기본적으로 모든 개별 HoC 래퍼를 피할 수 있는 방법은 없습니다. 잠시 동안 그것에 대해 생각한 후에 JSS로 해야 하는 것과 기본적으로 동일한 양의 타이핑/네이밍 결정이라는 것을 깨달았습니다.

@mbrookes @oliviertassinari 조건부 스타일과 내부 구성 요소 스타일은 어떻게 처리됩니까?
예를 들어 styled-components 기반으로 다음과 같은 것은 무엇입니까?

// conditional class name
<MenuItem classes={{selected: classes.selectedItem}}>...</MenuItem>

// inner component class name
<Dialog classes={{paper: classes.dialogPaper}}>...</Dialog>

styled-components 로의 전환 아이디어에 대해 진정했지만 이러한 종류의 사용 사례를 처리하기 위한 확실한 계획이 있는지 확인하고 싶습니다. API가 매우 다르거나 의존해야 한다고 가정하기 때문입니다. BEM 스타일 클래스 이름에.

@jedwards1211 아 제 실수입니다. 나는 예제 가 스타일이 지정된 구성 요소인 경우라는 인상을 받았지만 실제로 그렇지 않으면 작동하지 않습니다 👍

@ jedwards1211 clsx 는 과거에 조건부 클래스에 대해 스타일이 지정된 구성 요소와 짝을 이루는 것을 본 것입니다. 그런 종류의 의미입니까?

현재 하고 있는 프로젝트는 필요에 따라 MUI 구성 요소를 래핑하는 styled-components를 사용하므로 MUI 조건부 스타일링을 사용하지 않았습니다.

@South-Paw (또는 classnames )는 솔루션의 내부 세부 사항이 될 수 있지만 styled-components 래퍼는 단일 className AFAICT만 주입하기 때문에 내 말은 실제로 여러 재정의 클래스 이름을 구성 요소에 전달하는 편리한 방법이 아닙니다. 대신 <Dialog Paper={StyledPaper}>...</Dialog> 와 같은 작업을 수행해야 할 수 있으며 선택한 MenuItem 클래스 예제의 경우에는 무엇인지 잘 모르겠습니다.

@jedwards1211 설명하는 사용 사례가 무엇이며 문제가 어디에 있다고 생각하는지 더 잘 이해할 수 있도록 간단한 예를 들어 주시겠습니까? 솔루션에 대한 도움을 받고 싶지만 이것이 아직 무엇에 적용되는지 이해하지 못합니다 😄

네, 오늘은 시간이 없지만 내일은 할게요.
또한 jss-codemorphs 에 대한 작업이 진행 중이며, 궁극적으로 붙여넣은 CSS를 JSS로 변환하기 위한 VSCode 확장을 만들 계획입니다.

스타일이 지정된 구성 요소 구문이나 패키지가 유지되는 방식을 좋아하는 사람이 아니었고 이 제안을 좋아하는 사람이 아닙니다. Material ui에서 가장 좋아하는 것 중 하나는 현재 스타일링 솔루션입니다.

Facebook이 CSS-in-JS 솔루션도 오픈소싱할 수 있다는 것을 읽었다는 점은 흥미롭습니다. 그것도 나왔을 때 한 번 살펴보는 것도 의미가 있을 것 같습니다.

당면한 실제 주제에 대해. 나는 Typescript 경험이 좋지 않기 때문에 styled-components를 싫어합니다. 유형은 종종 돕는 것보다 더 해를 끼칩니다. 느린 컴파일 시간, 미친 인터페이스(스타일이 지정된 구성 요소가 인터페이스를 통해 작동하는 방식을 이해하려는 시도는 중첩된 Pick 마법으로 인해 악몽입니다). styled-components에 이러한 유형의 DX가 있는 한 material-ui가 이를 채택하는 것은 한 발짝 뒤로 물러난 것처럼 느껴질 것입니다.

Facebook이 CSS-in-JS 솔루션도 오픈소싱할 수 있다는 것을 읽었다는 점은 흥미롭습니다.

@venikx 그럴 가능성은 얼마나 됩니까? 내가 마지막으로 https://reactpodcast.simplecast.fm/75 에 있다는 것을 암시할 수 있는 무언가에 대해 들었을 때 5년 동안의 목표인 것 같았습니다.

오 정말? 나는 그들이 이미 "타임 라인"을 제공했는지 몰랐습니다. 어떤 이유로 나는 그것이 동시 모드와 같은 시기에 올 것이라고 생각했습니다. 너무 나빠.

하지만 styled-components에 대한 제 요점은 여전히 ​​유효합니다. 나는 styled-components를 사용하는 대신 순수 material-ui의 스타일 처리 방법을 사용하는 것을 선호합니다. styled-components의 타이핑은 컴파일러를 위한 것이지 문서를 위한 것이 아닌 것 같습니다.

또 다른 성가신 일(하지만 다시 개인적인 취향일 수 있음)은 구성 요소에 동적으로 스타일을 적용하는 방법입니다. 스타일이 지정된 구성 요소에 해당 논리를 포함하는 것보다 className을 추가하거나 제거하는 것을 매우 선호합니다.

Material-ui api는 순간 정말 깨끗합니다.

나는 Typescript 경험이 좋지 않기 때문에 styled-components를 싫어합니다.

나는 지금까지 적어도 4개의 대형 프로젝트에서 styled-components와 Typescript를 함께 사용했으며 유형에 문제가 없었습니다. - 소비자 쪽이 아닙니다.

느린 컴파일 시간

나는 그것을 사용하는 어떤 프로젝트에서도 이것을 경험하지 못했습니다. 당신이 의미하는 바에 대한 예가 있습니까?

미친 인터페이스 (스타일이 지정된 구성 요소가 인터페이스를 통해 작동하는 방식을 이해하려고 시도하는 것은 모든 중첩된 Pick 마법으로 인해 악몽입니다)

어떻게든 개선할 수 있다고 생각한다면 @types 프로젝트에 기여하는 것도 고려할 수 있습니다. 지금보다 개선된 부분이 있다면 모두가 감사할 것입니다!

스타일이 지정된 구성 요소에 해당 논리를 포함하는 것보다 className을 추가하거나 제거하는 것을 매우 선호합니다.

styled-components와 함께 클래스를 사용하는 것을 막는 것은 없습니다.

const Box = styled.div`
  height: 160px
  width: 160px;
  background-color: black;

  .red {
    background-color: red;
  }
`;

// simple usage
<Box className="red" />

// get more complex with conditionals and using something like clsx (https://www.npmjs.com/package/clsx)
const isRed = true;
<Box className={clsx({ red: isRed })} />

다른 의견을 주장하는 일부 댓글에도 불구하고 상위 문제에는 150 👍 및 27 🎉가 있고 18 👎 및 9 😕만 있다는 점에 주목할 가치가 있습니다. 이 토론을 싫어하는 목소리가 소수이고 긍정적인 조치라고 생각하는 다수가 있는 것 같습니다 🤷‍♂

@South-Paw 투표의 문제는 유일한 선택이 JSS 대 styled-components라는 것입니다. 보컬 부분은 스타일 구성 요소를 좋아하지 않고 JSS를 좋아하지 않는다는 것입니다. 아마 투표하면

결국 JSS보다 나은 것은 없습니다. 그건 오래 됬어. 느리고 부피가 크며(번들 크기) 계속 이동해야 합니다. 따라서 투표는 귀하의 결론을 전혀 지지하지 않습니다.

논쟁의 승자를 보기 위해 서로 싸우는 사람들에 대한 소음으로 이 문제를 채우지 않는 Spectrum 채팅이나 다른 것으로 이동할 수 있습니까?

핵심 팀에서 이 주제에 대한 토론을 위해 스레드를 팔로우하고 있습니다.

핵심팀의 판단을 과소평가하고 계신 것 같은데, 개인적으로 이 주제에 대한 논쟁은 그만하고 핵심팀을 더 믿어야 한다고 생각합니다. 결국 머티리얼 UI의 방향을 결정하는 것은 코어 팀의 몫입니다.

만약 당신이 정말로 그것에 대해 강한 의견을 갖고 있다면, Material UI는 놀랍게도 MIT 라이선스를 받았고, 그것을 포크하고, 당신이 가진 비전을 계속 유지하기를 바랍니다. 그렇게 하기를 권장합니다. 아마도 우리는 다양한 환경에서 미래에 배울 것입니다.

하지만, 제발, 핵심 팀이 그들의 일을 하게 하고, 그들을 믿으십시오. 그들은 놀라운 기술을 가진 정말 유능한 사람들이기 때문입니다.

여기 볼 수있는 아름다운 것이 있습니다

결국 JSS보다 나은 것은 없습니다. 그건 오래 됬어.

@hc-codersatlas old == 성숙한 -- 그것이 왜 문제인지 자세히 설명해 주시겠습니까?

좋아, 뜨거운 문제처럼 보이지만 누군가 이 간단한 정보를 확인해 줄 수 있습니까? 현재 Mui 버전(4 또는 5)에서 CSS처럼 보이는 태그가 지정된 템플릿 리터럴과 함께 styled-components 와 같은 구문을 사용할 수 있습니까? ?
이 질문에 대한 명확한 예 또는 아니오 대답을 찾을 수 없었습니다. 저는 기본 기술에 대해서는 별로 신경 쓰지 않고 개발자의 편의에만 관심이 있습니다. InVision에서 CSS를 복사하여 붙여넣는 것은 어떤 경우에는 기본적으로 매우 유용합니다.

이 문제는 Material-UI에서 사용되는 스타일링 솔루션에 관한 것입니다. 귀하의 질문은 앱의 스타일을 지정하거나 구성 요소의 스타일을 다시 지정하는 방법에 대한 것으로 보입니다. 어떤 솔루션이든 사용할 수 있습니다.

https://material-ui.com/guides/interoperability/

JSS는 플러그인으로 템플릿 리터럴을 기본적으로 지원합니다.

방금 매우 포괄적인 CSS에서 JSS로의 변환기 구현을 마쳤습니다.

• https://codemodsquad.github.io/jss-codemorphs/
• VSCode 확장: https://marketplace.visualstudio.com/items?itemName=vscodeshift.jss-codemorphs

CSS를 복사하여 JSS 스타일에 붙여넣는 번거로움이 없기를 바랍니다.

@jedwards1211 이거 봐
https://css2js.dotenv.dev/

@nainardev 다른 유틸리티는 매우 제한적이며 CSS 속성을 변환하지만 선택기, 중첩 선택기, 애니메이션 키프레임, 미디어 쿼리 등은 변환하지 않는다는 것을 알았습니다. 이 때문에 도구를 매우 포괄적으로 만들었기 때문에 변환할 수 있습니다. 바라건대 당신이 그것에 던진 본격적인 CSS가 될 것입니다.

이 답변을 어딘가에서 놓쳤을 수도 있지만 어쨌든 그것을 높이고 싶습니다. Material UI 구성 요소로 마이그레이션하고 스타일링 솔루션( less vs makeStyles vs styled-components )을 평가하는 중이며 대부분의 스타일링은 다음을 통해 수행됩니다. 파일과 대부분의 새로운 MUI 코드는 makeStyles 를 사용하고 있습니다. 명확히 알고 싶은 것은 이것이 v5의 일부가 될 것이기 때문에 스타일링과 관련된 기술적인 부채를 줄이기 위해 우리는 무엇을 할 수 있습니까?

1. v5에 makeStyles 가 있습니까? styled-components 및 테마와 어떻게 작동합니까? 예를 들어 styled-components 를 사용하면 다음과 같이 표시됩니다.

const useStyles = makeStyles((theme) => ({
  paper: {
    padding: theme.spacing(2),
    textAlign: 'center',
    color: theme.palette.text.secondary,
  },
}));

1. (v4) 이보다 스타일이 지정된 템플릿 문자열에서 theme 개체를 검색하는 더 좋은 방법이 있으므로 여러 번 사용할 수 있습니까?

const StyledContainer = styled.div`
  color: ${({ theme }) => theme.palette.primary.main};
  padding: ${({ theme }) => theme.spacing(1)};
  background-color: ${({ theme }) => theme.palette.background.paper};
`;

1. makeStyles 가 v5에 있다고 가정하고 대규모 코드베이스에 대해 styled-components 테마 제공자와 Material UI 테마 제공자를 모두 사용하는 경우 성능 저하를 예상해야 합니까?

Material UI 사용을 좋아합니다. 모든 수고에 감사드립니다!

@egilsster

1. 예, @material-ui/styles 또는 react-jss에서 볼 수 있습니다.
2. 예 https://material-ui.com/guides/interoperability/#theme ,

const StyledContainer = styled.div`
  ${({ theme }) => `
  color: ${theme.palette.primary.main};
  padding: ${theme.spacing(1)};
  background-color: ${theme.palette.background.paper};
  `}
`;

1. 주요 문제는 1. 구성 오버헤드, 1회 비용, 2. Sentry를 포함하여 ~15kB gzipped 오버헤드가 있는 두 개의 CSS-in-JS 런타임 로드입니다. 예를 들어 Sentry: https://bundlephobia.com /result?p=@sentry/browser.

빠른 답변 감사합니다. 감사합니다.

1. 예 material-ui.com/guides/interoperability/#theme

이것은 꽤 멋지다. 도구에 대한 일부 작업은 아마도 이것을 따를 것입니다. 마이그레이션하는 프로젝트는 TS를 사용하지 않지만 VSCode/언어 서버는 이 경우 theme 가 무엇인지 전혀 모르는 것 같고 styled-components 를 잃습니다. 구문 강조도.

다시 한 번 감사합니다. 이 개발을 계속할 것입니다.

@oliviertassinari 스타일이 지정된 구성 요소로의 마이그레이션이 있는 경우 <ListItem classes={{ selected: myCustomClassName}}> 와 같은 CSS API에 더 이상 의존할 수 없게 됩니까?

@jedwards1211 classes API는 유지됩니다.

괜찮아. styled-components는 루트 요소에 단일 클래스만 적용할 수 있기 때문에 MUI가 내부적으로 styled-components를 사용하는 방법이 약간 혼란스럽습니다.

const MyRoot = styled('div')`
  // some nice styles
`;

const MyAwesomeChild = styled('div')`
  // some nice styles
`;

export function AwesomeRoot(props) {
  return (
    <MyRoot className={props.classes?.root}>
      <MyAwesomeChild className={props.classes?.child}/>
      {props.children}
    </MyRoot>
  );
}

@jedwards1211 이 말이 되나요?

@yordis 간단해 보이지만 https://github.com/mui-org/material-ui/blob/master/packages/material-ui/src/Button/Button.js 와 같은 복합 선택기를 어떻게 리팩토링하시겠습니까?

styled-components 를 사용하여 이 기존 동작을 보존할 방법이 생각나지 않습니다. 따라서 사람들이 예상하는 것보다 더 많은 주요 변경 사항이 발생할 수 있습니다.

  outlined: {
    '&$disabled': {
      border: `1px solid ${theme.palette.action.disabledBackground}`,
    },
  },

기존 코드와 사용자 정의 재정의는 경우에 따라 CSS 특성에 따라 달라질 수도 있습니다.

아마도 이것은? 이것이 나에게 기본적으로 느껴지기 때문에 따라갈지 확신이 서지 않습니다. 아마도 일부 컨텍스트 및/또는 정보가 누락되었을 것입니다.

const MyOutlinedComponent = styled('div')`
  ${props.disabled && `
      border: `1px solid ${({ theme }) => theme.palette.action.disabledBackground}`,
  `}
`;

<MyOutlinedComponent disabled/>

@yordis 가능합니다. 내가 말했듯이 사람들은 이것이 사용자에게 얼마나 많은 주요 변경 사항을 초래할 것인지에 대해 생각하지 않을 수 있지만 저는 그 예가 주요 변경 사항을 방지할 것이라고 생각하지 않습니다.

실제 사례와 실제 잠재적인 주요 변경 사항을 공유하시겠습니까?

강력한 사례를 공유하지 않으면 팔로우하기 어렵습니다. 귀하의 메시지에 따르면 귀하가 이 주제를 완전히 이해하지 못하거나 제가 잘못된 판단을 내릴 수 있다고 생각합니다. 이해를 도와주세요, 제가 틀릴 수도 있습니다.

@oliviertassinari 테마 재정의가 v5에서 수정 없이 계속 작동합니까? 다음 재정의 예제가 작동하려면 MUI가 styled-components 생성 루트 클래스 이름 외에 JSS 생성 클래스 이름을 적용해야 하는 것처럼 보입니다.

const theme = createMuiTheme({
  overrides: {
    MuiButton: {
      root: {
        '&$disabled': {
          color: myCustomColor,
        },
      },
    },
  },
});

@yordis 는 더 생각해 본 결과 classes prop을 통해 전달된 스타일에 대한 복합 선택기가 운 좋게도 여전히 작동한다는 것을 깨달았습니다. 테마 재정의 스타일에 대해서는 확실하지 않습니다.

style={object}을 사용하여 스타일이 지정된 일반 MUI와 함께 MUI를 통해 두 스타일 구성 요소를 모두 사용하는 기쁨을 누렸습니다.

각각 미디어 캐러셀, 정보, 클릭 핸들러, 버튼 등이 있는 50개의 카드가 포함된 결과 목록 페이지를 가져옵니다.

스타일이 지정된 구성 요소를 사용하면 렌더링 시간에 거의 0.5초가 추가됩니다. const useStyles = makeStyles 또는 style={object}에 비해.

이 로드맵 계획의 결과를 받아들여야 합니다. 그러나 완전히 하향식으로 재정의할 수 없는 경우 UI 채택에 대한 계획이 꼬일 것입니다.

@Icehunter 사람들이 볼 수 있도록 결과와 샘플 프로젝트를 온라인에 게시할 수 있습니까?

@Icehunter 사람들이 볼 수 있도록 결과와 샘플 프로젝트를 온라인에 게시할 수 있습니까?

샘플 프로젝트는 독점 코드를 포함하기 때문에 어려울 것입니다. 렌더링된 이미지와 성능 탭의 타이밍 결과 섹션을 곧 게시하겠습니다.

각각 미디어 캐러셀, 정보, 클릭 핸들러, 버튼 등이 있는 50개의 카드가 포함된 결과 목록 페이지를 가져옵니다.

@Icehunter 그런 스타일에 소품을 보내는 건가요? 50장이든 500장이든 생성되는 클래스의 수는 같아야 합니다. 귀하의 특정 예에 공유할 수 없는 독점 코드가 포함되어 있는 것처럼 들리지만 공유할 수 있는 코드로 이 문제를 재현할 수 있습니까?

styled() / styled.div API는 _모든_ 요소의 렌더링에 오버헤드를 추가하므로 클래스 이름을 캐싱하더라도 속도가 느려질 수 있습니다. makeStyles 를 사용하면 스타일 그룹을 한 번 첨부한 다음 클래스 이름을 수동으로 적용할 수 있습니다. 이는 종종 훨씬 더 빠릅니다.

스타일이 지정된 구성 요소 styled 에 의존하는 솔루션이 MUI makeStyles 보다 3-4배 느릴 수 있음을 설명하기 위해 CodeSandbox 예제 를 작성했습니다.

styled API는 편의상 훌륭하지만 목록/테이블에서 많이 사용될 때 성능 문제가 될 수 있다는 @Icehunter 의 의견을 반영합니다. makeStyles 을 백업으로 사용하는 것이 좋습니다.

@schnerd 이러한 예를 조합해 주셔서 감사합니다. 이 예제는 우려 사항을 정말 잘 보여줍니다. 참고로 게시물 앞에 "보기가 어렵지 않습니다..."는 일종의 경멸처럼 보일 수 있으며 다른 훌륭한 예에 실제로 추가되지는 않았습니다.

@tuxracer 사과 – 업데이트되었습니다.

@Icehunter 무슨 말인지 이해가 안 가는데 SC나 JSS에서 공통 스타일을 사용하셨나요?

@Icehunter 무슨 말인지 이해가 안 가는데 SC나 JSS에서 공통 스타일을 사용하셨나요?

둘 다 사실. 우리는 결국 makeStyles를 사용했지만 styled={object}를 사용하거나 동일한 성능 결과를 얻었습니다.

우리는 전체 구성 요소 라이브러리와 기본 사이트에서 더 나은 성능을 얻기 위해 마이그레이션 프로세스를 진행 중입니다.

현명한 스택은 nextjs로 작성되었습니다.

명확하게(편집):

SC를 의도한 대로 사용하여 mui 구성 요소를 래핑했습니다. 매우 느리게 밝혀졌습니다.

그런 다음 공유 파일 설정에서 makeStyles 및/또는 style={object} 및 로컬(시뮬레이트된 계단식)을 사용하여 mui 구성 요소를 사용했습니다. 훨씬 더 빠릅니다.

나는 이 아이디어를 전혀 차단하고 싶지 않습니다. 그러나 기본값인 경우; 그런 다음 전역적으로 하향식 기본 선택을 재정의하고 자체적으로 dep 주입하는 방법이 있어야 합니다.

아마도 이것은? 이것이 나에게 기본적으로 느껴지기 때문에 따라갈지 확신이 서지 않습니다. 아마도 일부 컨텍스트 및/또는 정보가 누락되었을 것입니다.

const MyOutlinedComponent = styled('div')`
  ${props.disabled && `
      border: `1px solid ${({ theme }) => theme.palette.action.disabledBackground}`,
  `}
`;

<MyOutlinedComponent disabled/>

이 게임에 늦을 수도 있습니다. 하지만 @jedwards1211 은 이것을 SC로 표현하는 방법을 찾고 있다고 생각합니다. https://codesandbox.io/s/magical-snow-5bzd8

나는 내 자신이 어떤 곳에서 이것을 가지고 있습니다. 그 날이 오면 v5로 마이그레이션하는 것이 간단하면 좋을 것입니다.

사실 스타일 구성 요소를 사용하여 이와 같은 것이 어떻게 작동하는지 잘 모르겠습니다.

예를 들어 머티리얼 UI가 미래에 Typography 의 기본 변형 재정의를 지원한다면 JSS가 styled-components보다 쉽다고 생각합니다.

@heb-mm 여기에 @oliviertassinari 가 3월 7일에 이 스레드를 언급한 자세한 RFC 가 있습니다.

위로 스크롤하여 언급을 보는 데 1분 미만이 걸렸습니다.

편집: 궁금하신 분들을 위해 heb-mm이 지금 댓글을 삭제했습니다.

스타일이 지정된 구성 요소 styled 에 의존하는 솔루션이 MUI makeStyles 보다 3-4배 느릴 수 있음을 보여주기 위해 CodeSandbox 예제 를 작성했습니다.

@schnerd styled-components 를 모방해야 하는 Material-UI inhouse styled API를 포함하도록 벤치마크를 업데이트했습니다. 다른 옵션에 비해 엄청나게 느린 것을 보고 놀랐습니다. https://codesandbox.io/s/css-in-js-comparison-ljtjz?file=/src/App.js 를 참조하세요.

@emotion/styled (기본적으로 styled-component와 동일한 API를 가짐)가 똑같이 느릴지 아는 사람이 있습니까? 구현에 대해 더 최적화할 수 있는 부분이 있는지 궁금합니다.

@emotion/styled (기본적으로 styled-component와 동일한 API를 가짐)가 똑같이 느릴지 아는 사람이 있습니까? 구현에 대해 더 최적화할 수 있는 부분이 있는지 궁금합니다.

https://codesandbox.io/s/css-in-js-comparison-sej1m

스타일이 지정된 구성 요소만큼 빠릅니다. 여전히 makeStyle만큼 빠르지 않습니다. 내가 가장 많이 보는 문제는 객체 생성과 객체 캐싱/메모이제이션의 차이점입니다.

흠, 이것은 MUI로의 마이그레이션 계획에 상당한 문제를 일으킬 수 있습니다. 우리는 현재 CSS, 테마 및 성능을 관리하는 데 많은 문제를 겪은 후 Material UI 스타일링 시스템을 위해 styled-components 에서 멀어지고 있습니다. styled components 처음에는 괜찮았고 그 위에 자체 테마 솔루션을 구축했지만 UI가 커지면서 CSS도 커졌습니다. 우리는 TypeScript를 사용하므로 인라인 CSS 문자열 대신 JS 개체를 쉽게 리팩토링할 수 있다는 사실이 큰 장점이었습니다. 😕

그래서 저는 Material UI를 처음 접했고 v5의 알파 릴리스도 보았습니다. @ ldiego08 당신은 말했다 :

우리는 현재 Material UI 스타일링 시스템을 위해 styled-components에서 멀어지고 있습니다.

나는 일반적으로 반응으로 작업할 때 스타일이 지정된 구성 요소를 사용합니다. 머티리얼 UI 스타일링 시스템이란 무엇이며, 앞으로 머티리얼 UI에서 스타일과 CSS를 사용하기 위해 권장하는 방법은 무엇인가요? 나는 이 페이지를 읽었고 CSS-IN-JS에 찬성하는지 아닌지 명확하지 않습니다: https://material-ui.com/system/basics/. 저는 일반적으로 객체 구문이 아닌 CSS를 작성하는 것을 선호하며 "일반 CSS 구문"을 사용할 수 있기 때문에 CSS-IN-JS를 사용하는 이점을 누렸지만 손에 JS의 힘도 있습니다.

시작하는 데 도움을 주셔서 감사합니다!

styled-components API가 왜 그렇게 인기가 있는지 모르겠습니다. 더 느리므로 클래스 이름을 생성하는 대신 모든 것을 구성 요소로 래핑해야 합니다. 또한 태그가 지정된 템플릿 리터럴은 무엇입니까? 자바스크립트 문자열로 작성하는 것이 훨씬 낫기 때문에 CSS 파일에 CSS를 작성하고 싶지 않았습니다. :D 객체 구문은 구성 및 리팩토링 등의 경우 훨씬 더 강력합니다. 저에게는 CSS 객체를 취하고 클래스 이름을 반환하는 평범한 감정 css 및 cx 함수가 가장 유연하고 강력한 API입니다. 따라서 단순히 감정이 포함된 클래스 이름을 생성하고 클래스 API를 사용하는 것은 매우 유연하고 강력합니다. 그래서 왜 "더 편리한 개발자 API"를 위해 성능과 유연성을 교환하는지 이해할 수 없습니다(어떤 사람들에게는 끔찍한 API입니다).

styled-components API가 왜 그렇게 인기가 있는지 모르겠습니다. 더 느리므로 클래스 이름을 생성하는 대신 모든 것을 구성 요소로 래핑해야 합니다. 또한 태그가 지정된 템플릿 리터럴은 무엇입니까? 자바스크립트 문자열로 작성하는 것이 훨씬 낫기 때문에 CSS 파일에 CSS를 작성하고 싶지 않았습니다. :D 객체 구문은 구성 및 리팩토링 등의 경우 훨씬 더 강력합니다. 저에게는 CSS 객체를 취하고 클래스 이름을 반환하는 평범한 감정 css 및 cx 함수가 가장 유연하고 강력한 API입니다. 따라서 단순히 감정이 포함된 클래스 이름을 생성하고 클래스 API를 사용하는 것은 매우 유연하고 강력합니다. 그래서 왜 "더 편리한 개발자 API"를 위해 성능과 유연성을 교환하는지 이해할 수 없습니다(어떤 사람들에게는 끔찍한 API입니다).

나는 같은 우려를 가졌습니다 :) 아마도 상황이 조금 정리될 것입니다.
https://github.com/mui-org/material-ui/issues/6115#issuecomment -580449539

@martinjlowm 네, 우리는 같은 페이지에 있습니다 :) 머티리얼 UI 팀으로 가는 가장 현명한 방법은 일종의 플러그인 가능한 솔루션을 구현하고 js 솔루션의 CSS와 결합하지 않고 사람들이 무엇을 사용할지 선택하게 하고 그런 식으로 번들 크기를 저장하십시오. 또한 클래스와 createMuiTheme API를 유지하는 것이 가장 강력한 부분이기 때문입니다. 저에게 js의 css는 구성 요소 상태를 기반으로 하는 손쉬운 동적 스타일, CSS 또는 전체 구성 요소를 리팩토링하거나 삭제할 때의 자신감(객체 접근 방식이 우수한 곳), 성능(외부 스타일시트에서 사용하지 않는 스타일을 다운로드하지 않음)에 관한 것입니다. , 등등. 그리고 다시, 나는 왜 사람들이 일부 편집기 강조 표시와 함께 문자열을 쓰는 것을 좋아하는지 이해하지 못합니다. 컨텍스트에서 props에 액세스하려면 ${}를 사용해야 합니다. 배경 od div 요소를 설정하는 것보다 더 복잡한 경우 그 접근 방식은 지저분하고 내 의견으로는 읽을 수 없습니다. 나는 그것을 강타하는 것이 아닙니다. 단지 내 생각을 말하고 모든 개발자가 스타일이 지정된 구성 요소를 좋아하지 않는다는 점을 증명하려고 노력하고 있으며, 그렇다고 하더라도 성능과 유연성을 교환하는 것이 얼마나 좋은 거래인지 모르겠습니다. :)

@vdjurdjevic 실제로 js 솔루션에서 material-ui를 하나의 css에 결합하는 것은 css-in-js 관행이 불가피하게 다른 방향으로 성장할 때 충돌에 대한 거의 보장된 방법입니다.

특정 css-in-js 공급자로 스타일을 적용하는 어댑터 패턴은 어떻습니까? 스타일 자체는 material-ui 패키지 내에서 일관된 형식으로 정의되어야 합니다. 해당 어댑터에 따라 다르게 수행되는 스타일을 적용하는 것입니다.

다음과 같은 내용이 있습니다.

import {EmotionAdapter, StyledComponentAdapter, ThemeProvider} from "@material-ui/core/styles";
...
return 
    (<ThemeProvider theme={theme} adapter={EmotionAdapter}>
        ...
    </ThemeProvider>)

@vdjurdjevic https://github.com/mui-org/material-ui/issues/6115#issuecomment -652762320에 대한 귀하의 생각에 거의 동의합니다. 내가 최근에 https://github.com/mui-org/material-ui/issues/16947#issuecomment -653797178에서 공유한 방향에 대한 요약이 마음에 드실 것입니다.

나는 왜 사람들이 일부 편집기 강조 표시로 문자열 을 작성하는 것을 좋아하는지 이해하지 못합니다.

내 관점에서 몇 가지 이유:

• React.createElement('div', {}) 를 쓰지 않는 이유에 가깝습니다.
• 웹 개발 경험이 제한적인 사람들(많음)은 JavaScript API를 배우는 데 어려움을 겪습니다. CSS 구문을 사용하면 더 간단하게 느껴집니다. 디자이너를 예로 들어 팀원들에게 그것에 대해 어떻게 생각하는지 물어보세요. :)
• 개발 도구와 소스 간에 복사하여 붙여넣을 수 없습니다(나는 이것을 싫어합니다).

@oliviertassinari 좋아, 이것들은 몇 가지 확실한 요점입니다. 저도 동의합니다. :) 하지만 여전히 저에게(디자이너, 초심자, 선임 개발자가 아님) 스타일이 지정된 구성 요소와 태그가 지정된 템플릿 리터럴은 절대 선택 사항이 아닙니다. 추가 개발 방향에 대한 요약을 읽었으며 CSS 엔진이 선택 사항이라는 소식을 듣게 되어 기쁩니다. 나는 그것을 전환할 수 있는 한 styled-components를 기본값(대부분의 사용자가 좋아하는 경우)으로 신경 쓰지 않습니다. 솔직히 말해서 다음 프로젝트를 위해 v4에서 JSS를 고수할 것이라고 생각합니다. 여기에는 몇 가지 멋진 기능(예: 확장 및 구성 플러그인)이 있습니다. 감정을 위해 스타일리스 플러그인을 작성해야 비슷한 것을 가질 수 있었습니다.

추신. 저는 JSX의 팬도 아닙니다. :) 금방 지저분해지고 결국 화살표 코드가 표시되고 동적 요소를 렌더링해야 하는 구성 요소의 경우 createElement를 사용할 수 밖에 없습니다. createElement로 직접 작업하는 것이 더 낫다는 것이 아니라 JSX가 이상적이지 않다는 것을 말하는 것입니다. 내 생각에 Flutter는 최고의 DX를 가지고 있으며 언젠가는 웹 플랫폼을 잘 다룰 수 있기를 바랍니다.

@oliviertassinari https://github.com/mui-org/material-ui/issues/6115#issuecomment -643398897에 언급된 대로 진행 중인 성능 테스트에 따라 머티리얼 팀이 인기가 있기 때문에 스타일이 지정된 구성 요소를 선택하지 않기를 바랍니다. 느립니다. 항상 그래왔다. 개인적으로 CSS의 JS 표기법 같은 것을 배워야 하는 것이 개발자가 되는 요점입니다.

그것은 작업의 일부입니다.

개발자의 삶을 더 쉽게 만드는 것은 패키지 유지 관리자로서 우리가 하는 일의 일부이지만(내 프로젝트의 경우) 이를 쉽게 만드는 것과 성능을 높이는 것 사이에는 선이 있습니다.

이것이 내가 makeStyles만 사용하고 도입된 이후로 항상 사용하는 이유입니다.

내 마지막 팀 건축가는 듣지 않고 스타일이 지정된 구성 요소를 사용하여 지금 사이트가 느립니다. 테스트 브랜치에서 makeStyles로 전환하여 모바일 장치의 TTI에서 50%(10초)를 절약했지만, 그 댓글에서 말했듯이 JS 표기법은 모든 사람에게 알려져 있지 않기 때문에 받아들여지지 않았습니다.

내부적으로 재료는 원하는 대로 선택할 수 있지만 기본적으로 성능을 발휘하도록 하십시오.

[질문이 StackOverflow로 이동했습니다.]

@haysclark 지원 질문에 대해서는 RFC에 답하지 말고 StackOverflow를 사용하세요.

@haysclark 지원 질문에 대해서는 RFC에 답하지 말고 StackOverflow를 사용하세요.

@mbrooks 미리 알려 주셔서 감사합니다!

@emotion/styled (기본적으로 styled-component와 동일한 API를 가짐)가 똑같이 느릴지 아는 사람이 있습니까? 구현에 대해 더 최적화할 수 있는 부분이 있는지 궁금합니다.

https://codesandbox.io/s/css-in-js-comparison-sej1m

스타일이 지정된 구성 요소만큼 빠릅니다. 여전히 makeStyle만큼 빠르지 않습니다. 내가 가장 많이 보는 문제는 객체 생성과 객체 캐싱/메모이제이션의 차이점입니다.

Box 컴포넌트의 성능이 당신의 프로파일링과 비교될지 궁금해서 Chakra-UI의 Box를 추가하여 좋은 측정을 했고 결과는... 의외였습니다 :P
https://codesandbox.io/s/css-in-js-comparison-forked-mg3gx?file=/src/App.js

@Nvveen Chakra-UI v1을 사용해 보셨습니까? 다시 작성되었으며 잘만되면 더 나아질 것입니다. 아직 베타 버전이지만 감정 v11도 있습니다.

@Nvveen Chakra-UI v1을 사용해 보셨습니까? 다시 작성되었으며 잘만되면 더 나아질 것입니다. 아직 베타 버전이지만 감정 v11도 있습니다.

최신 RC로 방금 시도했지만 눈에 띄는 차이는 없었습니다. 여전히 일반 SC보다 약 1.5~2배 느립니다. 나에게 가장 큰 질문은 MUI Box가 왜 그렇게 느린가입니다.

@Nvveen Chakra-UI v1을 사용해 보셨습니까? 다시 작성되었으며 잘만되면 더 나아질 것입니다. 아직 베타 버전이지만 감정 v11도 있습니다.

최신 RC로 방금 시도했지만 눈에 띄는 차이는 없었습니다. 여전히 일반 SC보다 약 1.5~2배 느립니다. 나에게 가장 큰 질문은 MUI Box가 왜 그렇게 느린가입니다.

Jss를 사용합니다. SC는 적어도 다소 낫습니다.

내 컴퓨터에서 테스트 케이스가 실행되는 순서는 결과에 영향을 미칩니다. 비교하다

1. 상자 먼저 https://codesandbox.io/s/css-in-js-comparison-forked-tqlg1?file=/src/App.js
   

2. 마지막 상자 https://codesandbox.io/s/css-in-js-comparison-forked-js6th?file=/src/App.js
   

@oliviertassinari 가비지 수집 및 v8의 jit가 원인입니다. 테스트 실행을 분리/분리하는 것이 좋습니다. 나중 테스트는 더 나은 지트를 가지고 있지만 때때로 가비지 수집을 트리거합니다.

감정, SC 및 차크라는 각각의 작은 구성 요소에 장착할 고유한 스타일이 있고 MUI 스타일이 아직 완전히 최적화되지 않은 경우 이론적인 최대 성능에 근접한 것 같습니다. makeStyles/pure CSS에서와 같이 전체 구성 요소 트리에 대해 하나의 스타일 시트를 사용하는 것보다 더 나은 성능을 얻을 수 있는 유일한 방법인 것 같습니다. 감정, SC 등을 위한 추가 30ms는 스타일이 마운트되었는지 확인해야 하는 각 작은 구성 요소의 피할 수 없는 오버헤드입니다.

@jedwards1211 dx를 유지하는 것이라면 Atlassian은 이를 css로 컴파일 하는 lib를 만들었습니다.