추가 질문 :
6) xxxxStyle 소품을 제거하거나 제거하고 사용자가 스타일 재정의를 위해 xxxClassName 를 전달하도록 할 예정입니까? 아니면 이것들이 무료입니까?
7) CSS를 통한 스타일 재정의를 허용하고 구성 요소 인터페이스를 단순화합니다. 따라서 IconMenu에서 menuItemStyle 를 재정의하려면 style = StyleSheet.create({ IconMenu: {MenuItem: { color:red }}) 유형 재정의를 만들어야합니까?

@chrismcv 제 개인적인 의견은 우리가 제안한 이러한 슈퍼 특정 소품을 제거하기 위해 솔루션을 확실히 활용해야한다는 것입니다. [TextField] add floatingLabelFocusStyle prop # 4043

우리가 알기 전에, 사람들은 가능한 모든 포커스 / 액티브 / 호버 / 무엇이든 상태에 대한 하위 구성 요소 스타일에 대한 소품을 요청할 것입니다.

"XXXX 스타일을 지정하는 방법", "YYYY 내에서 XXX 스타일을 지정할 수 없음", "XXX에 somethingInsideToTheLeftButSlightlyMiddleFocusHoverActiveStyle 소품을 추가하십시오"와 같은 많은 문제가 있습니다.

@chrismcv in 6.보다 일반적인 xxxxStyle props 대 classNames에 대해 어떻게 생각하십니까? 일부 구성 요소를 사용하면 어떤 식 으로든 도달 할 수 있어야합니다 (다행히도 :hover 등을 사용할 수 있습니다!).

@chrismcv xxxxStyle props는 className -ified 스타일 개체가 아닌 style 속성에 있어야한다고 생각합니다.

@nathanmarks 대화를

성능 문제 외부

저에게는 이것이 우리가 선택할 솔루션에 대한 주요 관심사 중 하나입니다.
현재 접근 방식으로 많은 CPU 사이클을 잃었다 고 쉽게 상상할 수 있기 때문에 벤치 마크가 많지 않습니다. CPU 사이클은 인라인 스타일 객체에 대한 메모리 할당 및 가비지 수집으로 손실됩니다.

안녕하세요.

나는 현재 몇 가지 JS 스타일 솔루션을 가지고 놀고 있습니다. 흥미롭지 만 말하자면 여전히 "초기"라는 것이 분명합니다.

내가 생각한 한 가지는 동적 스타일 속성 외부 (예 : 구성 요소에 color 소품이있는 경우)에서 기본 스타일 개체를 만드는 방식을 변경해야 하는가?

JS 스타일 라이브러리에서 최대 성능을 얻으려면 StyleSheet.create() 메서드를 한 번 사용하고 open={true} 와 같은 props / states에 대해 해당 개체에 키 (css "classes")가 있어야합니다. 두 개의 조건부 속성을 사용하여 스타일 객체 리터럴을 동적으로 빌드하고 모든 단일 스타일에 대해 렌더링 할 때마다 스타일 시트 팩토리 메소드에 전달하는 대신.

스타일 시트 선택기가 DOM에 한 번만 기록된다는 의미로 캐시되지만 (일부 libs에서는 render() 필요할 때만 DOM에 기록됨) 여전히 일부 계산으로 리소스를 낭비하고 있습니다. + 객체 생성 + 위에서 언급 한 가비지 콜렉션. 우리가 버릴 때마다 렌더링 할 때마다 새로운 스타일 객체를 생성하는 경우.

음 ... 어제 (일요일) 여기에 댓글을 남겼습니다. 삭제 되었습니까?

@rvbyron 분명히 기억합니다. 나는 확실히 그것을 삭제하지 않았다.

@rvbyron 나도 그것을 기억합니다. 나는 무슨 일이 일어 났는지 전혀 모른다.

@rvbyron- 내 이메일에 포함되었으므로 여기에 인용 된 형식으로 돌아 오세요!

글쎄요, 저는 많은 일이 일어나는 것을보고 싶습니다.

A) 예, 라이브러리 수준에서 요소의 스타일 매개 변수를 사용하지 마십시오. 모든 구성 요소는 className을 사용하여 정의해야합니다. 구성 요소가 스타일을 사용하면 CSS가 제공하는 모든 강력한 기능이 파괴됩니다.
B) classNames를 각 구성 요소의 루트 요소에 자동으로 첨부하는 것이 좋습니다 (예 : RaisedButton 구성 요소는 구성 요소의 루트 요소에 암시 적으로 className = "mui-raised-button"이 있음). 스타일링이 훨씬 쉬워집니다. 구성 할 수도 있습니다.
C) muiTheme.js 파일에서 테마를 모두 가져옵니다. 테마 지정 muiTheme.SCSS 파일은 구성 요소에서 특별히 허용하는 속성뿐만 아니라 테마 작성자가 선택한 속성을 적용 할 수 있다는 점에서 훨씬 더 좋습니다. 물론 이것은 아마도 B가 구현되고 활성화되어야 할 것입니다.
D) React-look은 스타일 속성을 포함하는 JSON 객체를 classNames로 변환하므로 좋은 절충안으로 보입니다. 재정의하기가 더 쉽습니다. 그러나 위의 C에서 말했듯이 SCSS에서 테마 기반을 생성하고 싶습니다. 사용할 CSS 지원 패키지에 대해 꽤 열려 있습니다. 그러나 나는 className 매개 변수보다 요소의 스타일 매개 변수를 사용하고자하는 모든 것을 멀리 할 것입니다.

@chrismcv 감사합니다 친구!

저는 @rvbyron 이 말하는 것이 중요하다고 생각합니다. 어떤면에서 JS 스타일링은 일반 CSS에서 패러다임의 전환이기 때문입니다. 대부분의 사람들은 일상 업무에서 JS 스타일링을 사용 하지 않으며 다른 사고 방식이 필요하므로 일반적으로 JS에 능숙하지 않은 프로젝트에 기여할 수있는 디자이너를 더 어렵게 만듭니다.

여기에서 모든 각도를 고려하는 것이 중요합니다.

트윗 담아 가기

react-look 에 대해 내가 깨달은 한 가지는 look HoC에 모든 구성 요소를 래핑해야한다는 것입니다. 이것은 꽤 침략적인 것처럼 보이며 render() 함수를 가로 채고 super.render() 를 const 하고 그런 방식으로 스타일 확인 작업을 수행합니다. Khan / aphrodite 와 같은 일부 다른 솔루션은 Stylesheet.create() 내부 className={} Stylesheet.create() 의 styles.xxxx 참조 주위에 함수 래퍼가 필요합니다.

CSS를 위해 render() 함수를 하이재킹하는 것은 나에게 과도하게 설계된 것 같습니다. 이러한 종류의 깊이 통합 된 스타일 기능을위한 도구 / 지원에 내장 된 React가 존재하지 않는다는 것을 알 수 있습니다. 모든 구성 요소의 렌더링을 제어하는 ​​CSS 도우미 HoC에 대한 아이디어가 확실하지 않습니다.

생각?

안녕하세요 Material-UI 팀!

한동안 당신을 따라 왔고,이 주제를보고, 인라인 스타일에서 CSS로 이동하는 것이 좋은 생각이 될 수있는 이유에 대해 몇 가지 생각을 함께하고 싶었습니다. 이 저장소에서 렌더링 성능, 자식 / 중첩 요소 스타일 지정, 미디어 쿼리, 의사 요소 등을 다루는 많은 토론을 읽었으므로 아직 논의하지 않은 다른 항목에 집중하겠습니다. 하지만 그것도 관련이 있다고 생각합니다. 그리고 스타일 구성입니다. 제가 의미하는 바는 다음과 같습니다.

• 일부 스타일은 구성 요소 기본값에서 가져옵니다 (노드 폴더에 설정되어 있으며 만질 수 없음).
• 일부는 구성 요소 매개 변수에서 가져옵니다 (예 : 아바타 구성 요소 매개 변수 size={40} 는 너비, 높이 및 줄 높이를 40px ).
• 구성 요소 기본값이 사용자 정의되면 (테마 색상) 스타일은 테마 사용자 정의 위치에서 제공됩니다.
• 나머지 구성 요소 스타일이 수정되면 스타일은 코드의 또 다른 부분 인 구성 요소 구현에서 가져옵니다.

스타일을 조정할 때 살펴볼 위치가 4 개 이상 (👆)이므로 문제를 조사하기가 어렵습니다.

스타일이 CSS와 함께 제공되면 선택기가 표시되고 수정해야 할 위치를 정확히 알 수 있습니다. 인라인 스타일을 사용하면 특정 속성의 출처와 수정해야 할 항목을 이해하는 데 시간이 걸립니다. 그리고 개발자가 잘못된 위치에서 수정하면 ( size 매개 변수 대신 styles 영역에서 size 가 스타일이라는 것을 실제로 알려주는 것이 없으므로) 전체 width=height=line-height=40px 블록 성능, 또는 width/height/line-height 다시 작성하여 size 매개 변수를 적용 할 수 없게됩니다.

또한 인스펙터에서 볼 수있는 모든 것이 element.style 이므로 특정 속성이 적용된 부모 요소를 조사하기가 어렵습니다.

스타일이 선택자 (클래스 이름)와 함께 제공되면 인라인 스타일보다 스타일 구조를 훨씬 더 많이 제어 할 수 있습니다.

업데이트 : 제안 (이 주제에 관한)을 언급하는 것을 잊었습니다.

/component
--component.js
--component.css (or sass that is converted to css when the page is rendering)

이 구조는 구성 요소를 범위에 유지하지만 스타일을 더 많이 제어 할 수 있습니다. BEM className 규칙은 불필요한 중첩을 방지하는 데 도움이됩니다.

.mui-component {}
.mui-component__child {}

전반적으로 Material-UI 스타일을 구현, 조정 및 유지하는 데 도움이 될 것입니다.

뿡뿡

이메일을 찾아 주셔서 감사합니다!

두 세계의 행동 방식의 장점은 무엇입니까?

귀하의 요구에 가장 적합한 스타일링 기법을 가져 오는 "동작"개념은 어떻습니까? "StyleTheme"또는 "ClassTheme"가져 오기를 사용하여 동작을 선택할 수 있습니다. StyleTheme는 오늘날의 muiTheme 개체 material-ui를 참조 할 수 있으며 구성 요소 중심의 스타일링 개발자를 행복하게 만듭니다. 또는 muiTheme.js 개체 (동기화)에서 빌드 된 SCSS 파일을 사용하는 ClassTheme는 CSS 중심 개발자를 만족시킵니다. 이는 모든 구성 요소가 렌더링 요소에서 {... theme.ComponentName}을 수용해야 함을 의미합니다.

매우 간단한 예제를 제공하기 위해 RoundButton 구성 요소에는 다음과 같은 렌더링 메서드가 있습니다.

render() {
    return (<button {...theme.RoundButton} />);
}

StyleTheme 비헤이비어의 경우 theme.RoundButton에는 다음이 포함됩니다.

{ 
    style: {
        display: 'inline-block';
        borderRadius: '20px';
        width: '40px';
        height: '40px';
    }
}

ClassTheme 비헤이비어의 경우 theme.RoundButton에는 다음이 포함됩니다.

{ 
    className: 'mui-round-button'
}

이 둘의 조합은 ClassStyleTheme 동작으로 검색 할 수 있으며 theme.RoundButton은 다음을 모두 포함합니다.

{ 
    className: 'mui-round-button',
    style: {
        display: 'inline-block';
        borderRadius: '20px';
        width: '40px';
        height: '40px';
    }
}

mui-theme.scss 파일은 muiTheme.js 파일에서 생성되며 JS 파일에 포함 된 정확한 속성을 SCSS에 반영합니다. JS 이름의 낙타 케이스는 더 많은 표준 클래스 이름으로 변환됩니다.

mui-round-button {
    display: inline-block;
    border-radius: 20px;
    width: 40px;
    height: 40px;
}

MUI 구성 요소에 대한 모든 CSS 사용자 정의는 mui-theme.scss 파일이로드 된 후로드 된 동일한 클래스이므로 mui-theme 속성을 재정의합니다.

안녕하세요.

scss (네임 스페이스 / 해싱을위한 + CSS 모듈)과 같은 것을 사용하면 많은 이점이 있다고 생각합니다. 이것이 당신이 100 % 반대하는 것입니까? 직장에서 익숙해 졌기 때문에 약간 편견이있을 수 있지만, 많은 사람들이 같은 배를 타고 있습니다.

JS 스타일링 상황의 주요 문제는 모든 솔루션이 아직 진행중인 것처럼 느껴진다는 것입니다. 실제로 살펴볼 실제 성능 평가가 많지 않고, 우리가보고있는 라이브러리는 검증되지 않았으며, JS에서 스타일을 올바르게 수행하는 방법을 알아 내려고 많은 시간을 보내는 것처럼 느낍니다. 이 lib의 주요 목표는 머티리얼 디자인 사양을 구현하는 것이며, 이것이 현재 우리를 괴롭 히고 있다고 느낍니다. (성능 영향 문제를 정렬해야 함)

나는 이것에 대해 우리가 다른 우려를 가지고 있다고 생각합니다.

1. 정적 스타일을 넣을 위치 (쉬움, CSS 파일로 할 수 있음)
2. 입력에 따라 일부 스타일을 전환하는 방법 (className 스위치)
3. 동적 스타일을 적용하는 방법 (인라인 스타일로 가능)

응용 프로그램을 작성할 때 모든 것이 좋아 보이며 코드 외부에있는 사람은 아무것도 변경할 필요가 없습니다.

그러나 라이브러리의 경우 상황이 다르며 위의 모든 문제와 다음 사항이 있습니다.

1. 사용자가 정적 스타일을 사용자 정의 할 수 있도록하는 방법은 무엇입니까?
2. 쉽게 전환, 사용자 지정 및 격리하는 방식으로 테마를 구현하는 방법 (다른 하위 트리 다른 테마)?
3. 다른 사람들과 잘 놀 수 있도록 글로벌 네임 스페이스를 오염시키지 않는 방법은 무엇입니까?
4. 사용자가 인라인 동적 스타일을 어떻게 재정의 할 수 있습니까?
5. 변압기! (rtl, 접두사 등)

지금 우리가 가지고있는 것은 다음과 같은주의 사항으로 모든 문제를 어떻게 든 처리합니다.

1. 공연!
2. @nathanmarks가 말했듯이 깊게 중첩 된 구성 요소는 사용자 정의하기가 어렵습니다. somethingInsideToTheLeftButSlightlyMiddleFocusHoverActiveStyle
3. 일부 CSS 기능의 힘을 활용할 수 없습니다.

스타일링 접근 방식을 변경하면 모든 작업을 다시 수행해야합니다. 이 경우 마이그레이션을 시작하기 전에 모든 질문에 답해야합니다.

저의 겸손한 의견으로는 CSS와 CSS를 컴파일하는 것이 미래의 일부가 아니라고 생각합니다. 인라인 스타일이 우리 삶을 훨씬 더 쉽게 만들었다는 데 모두 동의한다고 생각합니다. 솔직히 인라인 스타일에서 볼 수 있는 유일한 제한 은 :hover !

우리는 약간의 디자인을 통해 이러한 문제를 해결할 수 있습니다.

1. 스타일 객체를 메모합니다. 상태가있는 구성 요소의 경우 상태를 분해하여 더 작은 구성 요소에 넣어 상위 구성 요소의 상태 인 전달 된 소품을 기반으로 스타일 객체를 메모 할 수 있습니다. 이것은 쉽게 해결할 수 있습니다!
2. 그들을 부숴 라! 왜 우리는 작은 기능이 많이 포함 된 ListItem 가지고 있습니까? 우리는 그것을 분해하고 구성 가능하게 만들 수 있습니다. 그러면 somethingInsideToTheLeftButSlightlyMiddleFocusHoverActiveStyle 와 같은 괴물을 추가 할 필요가 없습니다.
3. 으! 우리가 성능을 얻을 수있는 것은 :hover 브라우저 나 반응이 뭔가를 할 때까지 우리가 살 수 있다고 생각합니다.

제 요점은 현재의 스타일링 접근 방식으로 이미 많은 문제를 해결하고 있다는 것입니다. 인라인 스타일과 관련된 모든 패턴을 따르지 않기 때문에 한계가 있습니다. 구성 요소를 분해하기 시작하여 훨씬 더 구성 가능하게 만들면 아무것도 걱정할 필요가 없습니다. take MeuItem 그것을 꺼내서 구성 가능하게 만들었습니다. 사용하기 쉽고 순수한 렌더링을 사용하여 성능을 향상시킬 수있는 방법을 알 수 있습니다!

따라서 접근 방식을 변경하고 이러한 모든 문제를 다시 해결하는 대신 우리가 이미 가지고있는 것을 개선하는 데 시간을 투자합시다. 우리는 미디어 쿼리를 지원할 필요가 없습니다. 다른 사람들이 응답 성을 쉽게 구현할 수 있도록 구성 요소를 변경할 수 있습니다. 디버그하기 어렵습니까? 구성 요소를 분해하면 인라인 스타일이 더 작아지고 읽기 쉽습니다. 하지만 논쟁의 여지가 있습니다! 필요한 것은 Object.assign 에 참여하는 항목을 확인하여 스타일의 출처를 확인하는 중단 점뿐입니다.

물론 그것은 제가 토론에 매우 개방적이라고 생각합니다.

뿡 빵뀨

당신은 몇 가지 훌륭한 포인트를 올립니다. 감사. 일종의 하이브리드 솔루션이 가능한지 궁금합니다. 우리가 어떤 각도를 취하더라도 많은 문제가있는 것 같습니다 😆

다음 주에이 작업을 할 시간이 있습니다. 대화를 나누고 영리한 아이디어를 생각해 낼 수 있는지 살펴 보겠습니다.

변화량을 최소화하고 이미 해결 된 문제를 해결해야한다는 데 동의합니다. 여기에 두 가지 중요한 목표가 있습니다.

1. 공연
2. 개발자 경험 (JS 스타일 라이브러리는 개발자가 애플리케이션에서 클래스를 쉽게 사용할 수 있도록하여 여기에서 많은 도움이됩니다)

이것에 대해 더 생각할 필요가 있습니다 😄 그러나 우리가 그 두 가지 점을 해결하는 한 우리의 솔루션에 만족할 것입니다.

또 다른 임의의 메모-lib 전체에서 인라인 / jsstyle / 무엇이든에 대해 특정 코드 규칙과 디자인 패턴을 적용하는 자동화 된 방법이 있다면 좋을 것입니다.

이것이 당신이 100 % 반대하는 것입니까?

@nathanmarks 저는 SCSS를 사용하는 것에 100 % 반대하지 않습니다 (_ 직장에서 사용하고 있습니다 _). 그러나 내 관점에서는 막 다른 골목 입니다.
React의 주요 장점 중 하나는 브라우저의 렌더링 특수성을 추상화 한 DOM입니다.
내가 아는 한 React Core Team의 장기적인 목표는 크로스 플랫폼 구성 요소를 작성하기위한 API를 제공하는 것입니다. 실제로 그들은 현재이 방향으로

@alitaheri에 전적으로 동의합니다. 다음 두 단계로 시작할 수 있습니다.

• 나중에 더 쉽게 마이그레이션 할 수 있도록 어디서나 getStyles 패턴을 사용하십시오.
  codemod를 사용할 수 있습니까? 누가 알아.
• @alitaheri가 제안한대로 각 구성 요소를 분석합니다.

@oliviertassinari 저는 막 다른 결론에 동의합니다-그것은 미래가 아닙니다. JS 스타일이 우리를 위해 작동하도록 만드는 방법에 대한 대화를 자극하기 위해 크게 제기했습니다. 나는 여기 주변의 몇몇 사람들이 문제를 둘러싼 좋은 아이디어를 가지고 있다는 것을 알고있었습니다.

실제로 우리가 현재 사용하는 getStyles() 패턴에는 자체 문제가 있다고 생각합니다. @alitaheri 와 저는 오늘 JS 스타일 설정 (테마 포함!)을 개선하기 위해해야 ​​할 일에 대해 꽤 좋은 대화를

다음 주에는 휴가 중이며 모든 스타일을 JS 기반으로 유지하면서 현재 문제에 대한 해결책을 실험 할 것입니다.

Lessons Learned At React Amsterdam (https://medium.com/@kitze/lessons-learned-at-react-amsterdam-51f2006c4a59#.o12h794or)에서이 게시물을 읽고 React의 스타일링 솔루션에 대한 프레젠테이션 중 하나를 참조하십시오. http : //slides.com/kof/javascript-style-sheets#/ 이 토론에 대한시기 적절한 프레젠테이션.

내가 계속 생각하고 명시 적으로 언급 한 적이없는 한 가지 요구 사항 (적어도 기억 나는대로)은 웹 전용과 웹을 지원하고 네이티브에 반응해야한다는 것입니다. 의도가 웹 전용 인 경우 (즉, React Native가 요구 사항이 아님) 이미 효율적이고 강력하게 지원하고 사람들이 매우 친숙한 브라우저를 활용하는 솔루션이 좋습니다. React Native를 지원하는 것이 필수라면 다른 요구 사항 및 요구 사항이 열립니다. 기술 선택, 타협 등을 평가할 때 생각하고 명심해야 할 사항입니다.

뿡뿡

프레젠테이션을 공유해 주셔서 감사합니다!

뿡 빵뀨

우리는 그 프레젠테이션에서 언급 된 lib 를보고 싶을 것입니다 ( 여기 데모가 있습니다 ). 많은 작업을 절약 할 수 있습니다. 이전에 살펴 보았지만 마음에 들지 않는 몇 가지 사항이있었습니다 (예 : 독점 HoC에서 모든 단일 구성 요소를 래핑해야하는 요구 사항). 그러나 여기 에서 있습니다 . 그는 이와 같은 변경 을 구현하면 HoC가없는 사용이 가능하다고 언급합니다. 나는 시트 쓰기를 위해 그 방법 / 디자인을 선호합니다 ( aphrodite 에서도 볼 수 있습니다).

또는 mixout 와 함께 작동 할 수있는 jss 대한 자체 반응 바인딩을 항상 만들 수 있습니다.

lib 작성자는이 문제에 대한 내 생각과 일치한다고 말했습니다.

그러나 모든 것이 스타일 시트가되는 것은 아님을 이해해야합니다. 가장 동적 인 변경을 위해서는 인라인 스타일을 사용해야합니다.

@nathanmarks 구현은 매우 작고 섞기 매우 쉽습니다. : grin :
https://github.com/jsstyles/react-jss/blob/master/src/index.js
이 라이브러리가 우리를 도울 수 있다고 생각합니다 : +1 :

@alitaheri 네 동의합니다!

jss 대한 몇 가지 사용자 지정 바인딩을 실험하고 있습니다. 해결하려고하는 몇 가지 문제 / 제한 사항이 있습니다. (하나는 코어 라이브러리에 대한 작업이 필요할 수 있음)

React 커뮤니티에는 JavaScript 스타일링이 최상의 솔루션이라는 일반적인 정서가있는 것 같습니다. 그 감정은 괜찮습니다. 나는 그것을 가진 사람들과 의견이 일치하지 않습니다. 그러나 JavaScript 스타일링이 구현되는 방식은 거의 항상 CSS 개발자와 관계가 없습니다. 구현은 모든 너무 자주 선호 style=/[element property]= 이상 className= 자신의 일을에서와 방지를 CSS 개발자.

이전 댓글에서 제안했듯이 두 사람이 함께 잘 살 수있을 것 같아요. 스타일 속성을 적용하려면 단순히 행동 방식을 취해야합니다. 라이브러리는 요소에 대한 스타일 속성의 직접 적용을 수용 하거나 이러한 스타일 속성으로 구성된 className을 만드는 간접적 접근을 허용해야합니다. 개발자가 동작을 선택할 수있는 라이브러리는 이상적인 솔루션처럼 보입니다.

CSS 개발자가 단순히 접근 방식을 버리고 싶지 않은 데는 여러 가지 이유가 있습니다. 사람들이 왜 그것이 유익하다고 생각하는지 보려면 "왜 CSS를 사용합니까"를 검색하십시오. 스타일의 추상화와 강력한 선택 언어가 이점 중 하나임을 알 수 있습니다. 오늘날 CSS 사용자에게 도움이되는 엄청난 양의 코드를 잊지 마십시오.

다시 말하지만, 이것은 어떤 식 으로든 전문적인 CSS 해설이 아닙니다. 스타일링에 CSS를 사용하고 싶은 분들이 있습니다. 이 의견은 개발자가 선택권을 가질 수 있도록 구조적으로 중립적 인 스타일링 접근 방식을 장려하기위한 것입니다.

@rvbyron 현재 접근 방식을 변경하려는 주된 이유 중 하나는 CSS를 사용하여 구성 요소를보다 쉽게 ​​사용자 지정할 수 있도록하는 것입니다. jss 와 같은 라이브러리를 사용하면 js 스타일을 활용하면서 CSS 기능을 사용할 수 있습니다. 그리고 이러한 스타일을 CSS로 변환하기 때문에 추악한 !important 해킹없이 추가 클래스 이름으로 쉽게 재정의 할 수 있습니다.

@alitaheri 듣기

다시 말하지만, className 접근 방식에 대해 들으니 환상적입니다. 이를 염두에두고 구현 방법에 대한 몇 가지 질문이 있습니다.

• 클래스 이름 명명 규칙이 어떻게 보일 것이라고 생각하십니까?
• 모든 클래스 이름에 "mui-"또는 기타 접두사가 있습니까?
• 클래스는 구성 요소 이름의 대시 표기법입니까?
• 각 구성 요소의 루트 요소에 클래스 이름이 적용됩니까?

뿡뿡

이상적으로 :

사용자 정의 가능한 접두사. 더 나은 개발 경험을위한 일종의 대시 표기법과 사용자 지정 테마 ID를 사용하여 고정 문자열로 설정할 수도있는 해시 접미사 (테마 설정이 변경되면 변경되지 않음). 덜 장황한 생산 옵션 또는 사용자 정의 할 콜백 함수를 포함합니다. 그리고 나는 루트의 클래스가 항상 항상 필요하다고 가정합니다.

많은 요구 사항과 제안 사항이 있다고 생각합니다. 그래서,이 모든 논의에서 벗어나는 것이 있습니까? 다음 조치는 무엇입니까? 이 material-ui에 react-jss를 구현하는 작업이 있습니까?

@rvbyron 네, 우리는 무대 뒤에서 몇 가지 대략적인 아이디어를 실험하고 있습니다. 좀 더 구체적인 아이디어가 있으면이 문제를 업데이트 할 예정입니다.

저의 겸손한 의견으로는 CSS와 CSS를 컴파일하는 것이 미래의 일부가 아니라고 생각합니다. 인라인 스타일이 우리 삶을 훨씬 더 쉽게 만들었다는 데 모두 동의한다고 생각합니다. 솔직히, 인라인 스타일에서 볼 수있는 유일한 제한은 : hover!

문제는 : hover가 스타일의 매우 기본적이고 매우 중요한 부분이라는 것입니다. 미래주의는 제쳐두고, 기본 기능을 다시 구현하기 위해 치트와 해결 방법에 의존해야하는 솔루션에 대한 조기 약속을 피하는 것이 현명 할 수 있습니다.

@wtgtybhertgeghgtwtg 실제 스타일 시트를 사용하는 솔루션을 위해 노력하고 있으므로 :hover 와 같은 기능이 지원됩니다.

주요 포인트가 결정되었으므로 (className 및 루트 요소 classNames를 통한 JSS 스타일링) material-ui v0.16.0 릴리스에 대한 로드맵과 타임 라인이 있습니까?

@rvbyron 약속 된 일정은 없지만 지금은 스타일링 접근 방식과 성능이 v0.16.0 릴리스의 주요 초점이며 현재 적극적으로 작업하고 있습니다. 내부, API, 마이그레이션 등과 관련된 몇 가지 다른 영역에서 올바른 방향을 결정하면 가까운 장래에이 문제를 커뮤니티 피드백에 사용할 것입니다.

@newoga 감사합니다 Neil! 업데이트에 감사드립니다. 다른 문제에 관해서는 className 기반 시스템으로 이동하는 것이 많은 사람들에게 시각적으로 큰 변화가 될 수 있다는 점을 추가하고 싶습니다. 그 외에도 다른 변경 사항은 마이그레이션을 실제로 방해 할 수 있습니다. 그러나 나는 당신의 팀이 최상의 균형을 선택할 것이라는 것을 알고 있습니다.

@newoga 여기 jss는 material-ui 스타일링 시스템의 미래로 불려졌습니다. 이것은 다른 사람들이 16.0 릴리스를 예상하여 지금 우리 프로젝트에 jss를 온 보딩 할 수있을만큼 충분히 구체적인 계획입니까?

@sorahn 아직

@sorahn 이 문제는 여전히 해결하기 어려운 문제에 대한 커뮤니티 피드백을 얻기 위해 고안되었습니다. 공식적인 결정은 내려지지 않았습니다. 현재로서는 모든 사람이 자신과 프로젝트에 가장 적합한 스타일 라이브러리 또는 접근 방식을 선택하고 사용해야합니다.

기록을 위해이 스타일 변경의 목표는 모든 사람을 다른 표준으로 마이그레이션하는 것이 아니라 사용하는 스타일링 접근 방식에 관계없이 Material-UI 구성 요소를 더 쉽게 사용하고 스타일을 지정하는 것입니다.

tl; dr 아니오! 다른 사람이 말하는 것이 아니라 당신에게 가장 좋은 것을하십시오 :)

@nathanmarks @newoga 업데이트

모든 인라인 스타일에서 반응 형 디자인 + 서버 측 렌더링의 한계에 부딪 히고 있으므로 대안을 조사하고 있습니다. (s) css-modules 또는 csx 등에 대해 특별히 강한 의견은 없지만 material-ui를 좋아하므로 여러분이 무엇을 할 것인지 따라가는 것이 좋습니다. :)

나는 미디어 쿼리를 만났고이 스레드를 읽었습니다. 몇 가지 잠재적 인 해결책과 기사를 살펴 보았습니다.

저는 JSS + CSX 솔루션을 정말 좋아합니다 (개발자 _joy_ 관점에서 볼 때).

JSS 이점 및 성능

@sorahn 과 유사하게 기쁩니다. @nathanmarks 가이 방향으로 작업하여이 접근 방식을 검증하기를 바랍니다. 또한 두 CSX / JSS 개발자 모두 자신의 라이브러리 채택을 돕고 장려하는 데 열심 인 것 같습니다.

@rosskevin 우리가 말하는대로 작업 중입니다. 지금까지 어떤 솔루션에서도 다루지 않은 고려할 사항이 있습니다.

우리의 요구 사항은 설계 제한이나 의견으로 인해 기존 솔루션이 지원할 수있는 것보다 훨씬 더 광범위합니다. 이는 기존 솔루션이 구성 요소 API의 사용을 완전히 제어 할 수있는 앱과 다양한 도구로 구성 요소를 스타일링하려는 다양한 사용자 집합이있는 라이브러리를 염두에두고 개발 되었기 때문입니다.

@sorahn 빠른 질문-서버 측 렌더링과 함께 공급 업체 접두사에 대해 무엇을하고 있습니까? 서버의 모든 접두사를 렌더링하고 있습니까? 아니면 UA를 통과하고 있습니까?

@nathanmarks 우리는 사용자 에이전트를 브라우저로 보내고 있지만 개인적으로 그것에 의존하는 것을 좋아하지 않습니다. 기본적으로 모든 항목을 배치하고 사람들이 muiTheme 개체의 소품을 통해 재정의하도록 허용하거나 그 반대의 경우 기본적으로 아무것도하지 않고 사람들이 선택하도록 허용하는 것은 어떻습니까?

muiTheme: {
  // other stuff...
  stylePrefixes: ['webkit', 'moz', 'ms']
}

@sorahn 프리픽스가 아닌 프리픽스, all 패스, UA 패스 등 원하는대로 할 수 있습니다.

@nathanmarks 방금 [email protected]을 출시 http://jsstyles.github.io/examples/index.html 이있는 ssr의 예가 있습니다.

여기에 $ .02를 넣으면됩니다. 인라인 스타일과 아프로디테에 대한 아이디어가 정말 마음에 들지만 스타일이 부트 스트랩 4와 같은 scss의 라이브러리 형식에 기반을두면 더 쉬울 것 같은 느낌이 듭니다.

내가 일반적으로하는 일은 말 그대로 bootstrap.scss 파일과 _variables.scss 파일을 복사하는 것입니다. 변수와 믹스 인, node_modules의 다른 모든 버전에 대한 경로를 사용하는 동안 ...

그런 다음 웹팩 구성을 설정하여 sassLoader 구성에 대한 검색 경로의 ./lib/style 부분을 만듭니다.

이런 식으로 부트 스트랩 등을로드하는 main.scss 파일을 가질 수 있습니다. 거기에서 나머지 프로젝트 내에서 변수 및 / 또는 믹스 인을 참조 할 수 있으며 출력을 빌드 / 번들 할 때 적절한 스타일은 다음과 같습니다. 포함.

이것의 단점은 material-ui를 소스 (사전 빌드가 아님)로 사용하고 번들에 scss를 포함하기 위해 웹팩을 사용하는 것을 규정한다는 것입니다. 즉, 기존 변수, 클래스 및 스타일링 믹스 인을 사용하는 가장 직접적인 경로 일 것입니다.

다시 말하지만, JS 스타일링의 아이디어가 정말 마음에 듭니다. Aphrodite가 제공하는 것과 같은 tbh ... 인라인 스타일을위한 스타일링 라이브러리로 비슷한 작업을하고 있었지만 Aphrodite는 이미 모든 작업을 수행하고 있습니다. 계획하고 있습니다.

스타일링 솔루션이 완성 되었습니까?

이것에 대한 업데이트가 있습니까?

네, next 지점은 jss

방금이 프로젝트를 접하게되었고 멋지게 보였고 예제 페이지를 통해 구성 요소 사용 방법을 매우 쉽게 파악할 수 있었고 널리 사용 된 것처럼 보였기 때문에 매우 흥분되었습니다. 그러나 나는 인라인 스타일에 매우 실망하고 여러분들이 그들로부터 벗어나는 것을 보니 기쁩니다. 제가 지적하고 싶은 것 중 하나는 이러한 구성 요소 외부의 레이아웃과 관련된 모든 작업을 제거하고 부모 구성 요소의 스타일이이를 처리하도록해야한다는 것입니다. 가장 낮은 수준의 구성 요소에는 주변 요소를 밀어내는 어떤 방식 으로든 여백이나 패딩이 없어야합니다. 특히 인라인 스타일을 엉망으로 만들지 않고 재정의하는 것이 거의 불가능하기 때문에 주변을 파헤 치고 수행 방법을 찾아야합니다. 그. 불행히도 사용할 수 없다고 생각했기 때문에이 프로젝트에 대해 더 깊이 파고 들지 않았습니다. 나는 확실히 인라인 스타일과 CSS 스타일에 대한 많은 토론을 읽었습니다. 어쨌든, 당신은 TextField에서 나를 잃었습니다. 상단에는 14px의 여백이 있고 하단에는 16px의 여백이 있습니다. 나는 그것을 재정의하기 위해 단순한 스타일을 작성하는 것을 너무 신경 쓰지 않을 것이다. 그러나 그것은 인라인 스타일링 때문에 불가능하며 당신의 컴포넌트를 div로 래핑 할 때와 같이 그것을 뒤집기 위해 더 높은 수준의 컴포넌트를 생성해야한다는 것은 나에게 완전히 미쳤다. 그리고 margin : -14px 0 -16px 또는 내가 원하는 방식으로 계산을 통해 약간 조정하지만 어떤 식 으로든 수정해야 할 필요는 없습니다. 여러분이 이미했던 것처럼 className이 prop으로 전달되도록 허용한다면 레이아웃 스타일링을 커뮤니티가 스타일링하려는 방식으로 컴포넌트에 적용 할 수 있다면 훨씬 더 선호합니다. 어쨌든 그건 내 $ .02입니다.

여기에 추가하기 위해, 이들에 대한 레이아웃 유형 구성 요소를 생성하거나 레이아웃 속성을 처리하기위한 추가 소품을 만드는 것이 파운데이션 및 부트 스트랩과 같은 그리드 시스템을 사용하는 것과 같이 이상적 일 수 있습니다. 예를 들어 크기, 거터, 너비, 열 등과 같은 소품을 사용하지만 구성 요소에서 볼 수있는 외부 주위에는 스타일링없이 시작합니다.

나는 @ jbsmith969와 완전히 함께합니다.

구성 요소를 div로 래핑하고 margin : -14px 0 -16px를 수행 할 때와 같이 더 높은 수준의 구성 요소를 만들어야하거나 내가 원하는 방식으로 계산하여 약간 조정해야한다는 것은 완전히 미쳤습니다.

@ jbsmith969 저수준 구성 요소에는 레이아웃 논리가 없어야한다는 데 동의합니다. 그러나 앱 특이성을 위해 더 높은 추상화 된 구성 요소를 만드는 것은 전혀 미친 소리가 아닙니다.
IMHO는 React가 가능하게하는 가장 강력한 패턴 중 하나입니다 (격리 속성 덕분에).

@oliviertassinari @ jbsmith969 그게 바로 우리가 무슨 짓을했는지! 우리는 우리의 생성 CustomTextField 다음 밖으로 렌더링, 내가 2 PARAMS (필드 이름, 색상)과 같은 패스 구성 요소를, 그리고 그것은 단지 그 주위 로직의 작은 비트를하지 material-ui/TextField 뭐든 우리 필요.

끝까지 구성 요소입니다!

그래서 반응으로 우리는 우리의 html을 가져 와서 js에 넣습니다. 그것은 훌륭하고 멋집니다. 하지만 CSS를 가져 와서 html로 밀어 넣을까요? 다른 사람과 잘 어울리지 않나요?

sass에서 벗어나는 이점은 무엇입니까?

구식이라고 부르지 만 js / html과 css를 별도로 유지하는 것이 왜 그렇게 잘못 되었습니까?

합법적으로 여기에서 몇 가지 답변을 찾고 있습니다 ...

https://github.com/callemall/material-ui/issues/3614#issuecomment -249095805와 관련하여 스타일링은 단순히 구성 요소가됩니다.

CSS 클래스를 새로운 구성 요소로 봅니다. (예 : btn-danger -boostrap의 유사)

const DangerButton = ({ hoverColor, style, ...others }) => {
    return (
        <MUI.FlatButton
            hoverColor={hoverColor || Colors.pink100}
            style={{ color: Colors.black, ...style }}
            {...others}
        />
    );
};

하지만 전환은 고통입니다 ..

( @ jbsmith969의 경우 MUI는 머티리얼 디자인 사양을 따릅니다. 사양을 따르고 싶지 않다면 해결 방법을 기대할 수 있습니다. 그러나 MUI가 해킹하기 어렵다는 데 동의하지만 주로 일관성이없는 이상하기 때문입니다. 스타일이 인라인이기 때문이 아닙니다.)

@vizath 맞습니다 나는 확실히 같은 생각을 가지고 있습니다. 하지만이 솔루션의 장점은 무엇입니까?

실제로 아니라 단지 CSS는 않는 한 적어도 일한 해결책이 있었다면, 나는 총을주고 고려할 것입니다. 그러나 현재는 경고없이이를 수행 할 수있는 솔루션 (내가 알고있는)이 없기 때문에 실제로 원숭이를 보지 못합니다.

이 저장소가 솔루션에 대한 알파 단계 아이디어를 매우 유용한 코드베이스로 채택하려는 이유는 무엇입니까? 나는 우리가 아직 tec과 함께 있다고 생각하지 않으며 이것이 그 tec을위한 적절한 테스트 베드라고 생각하지 않습니다.

@nathanmarks JSS를 사용하여 구성 요소의 스타일을 재정의하는 방법에 대해 조언 해 주시겠습니까? next 의 최신 코드를 사용하고 있습니다.

편집 : 좋아, 아직 완전히 구현되지 않았다는 것만 알아 냈습니다. 내 잘못이야! 😬

객체 키에서 죽은 코드를 제거하는 좋은 방법을 아직 찾지 못했고 JSS를 사용하면 객체를 사용하여 스타일을 저장해야합니다.

next 분기의 구성 요소에있는 임의의 예 (완료되지 않음) : https://github.com/callemall/material-ui/blob/b372f6223ec2528dbe02f100e4802334f88445b7/src/IconButton/IconButton.js#L36
primary 및 accent 클래스가 사용되지 않음을 안정적으로 찾을 수있는 방법을 찾을 수 없습니다.

같은 이유로 MUI가 이전에 인라인 스타일을 관리하는 방식이 마음에 들지 않았습니다 (스타일이 별도로 정의 된 경우 Lint는 미발송 변수를 포착했을 것입니다. https://github.com/callemall/material-ui/blob/ 참조) 60a202fdc9645aa00f20c52e5152f168a1b0031b / src / IconButton / IconButton.js # L26).

sass에서 벗어나는 이점은 무엇입니까?

@gdaunton 인라인 스타일 / sass 접근 방식을 사용하지 않는 것과 관련된 측면에 따라 다릅니다.

사용자 관점 에서 다음과 같은 개선 사항을 제공 할 것입니다.

• 캐시 된 생성 된 CSS 시트에 의존하므로 더 빠른 반응 렌더링 방법.
• CSS 우선 순위가 인라인 스타일보다 낮고 사용자가 DevTools를 사용하여 변경할 시트를 식별 할 수 있으므로 단순화 된 스타일 재정의.
• 서버 측 렌더링을 할 때 더 빠른 첫 번째 페인트.
  
  
  
  • 사용자는 중요한 CSS 시트를 인라인 할 수 있으며 페이지에서 사용 된 시트 만 인라인 할 수 있습니다. 즉, 🙈 큰 기둥입니다 당신이 _Bootstrap_으로 할 수없는 일입니다.
  
  
  • 사용자는 프로덕션에서 클래스 이름 키를 uglify 할 수 있어야합니다.
  
  
• _scss-loader_ 또는 _Webpack_과 같은 빌드 체인 종속성이 없습니다.

기여자 / 관리자 관점 에서 다음과 같은 개선 사항을 제공 할 것입니다.

• 더 이상 CSS 린터 없음
• 더 이상 전처리 CSS가 없습니다.
• 배울 CSS 구문 없음
• 구성 요소 스타일을 지정하는 훨씬 더 강력한 언어 : JavaScript
• 스타일 엔진을 추상화 할 가능성을여십시오. 예 : react-with-styles 사용

이 저장소가 알파 단계 아이디어를 채택하려는 이유

알파 단계 아이디어가 의미하는 바에 따라 다릅니다.
우리는이 접근 방식을 사용한 유일한 사람이 아닙니다. 예 : AirBnB, Khan Academy, ReactNative.

적어도 CSS만큼 잘 작동했습니다.

CSS는 처음부터 구성 요소가 아닌 문서의 스타일을 지정하도록 설계되었습니다.
그것은 우리 업계의 주요 변화입니다.

내 관점에서 볼 때 스타일링 구성 요소가 짜증납니다 .
웹 사양 뒤에있는 사람들은이 문제를 잘 알고 있으며 _Web Components_의 로컬 범위 스타일로 해결하려고합니다.
CSS 개선 및 컴포넌트 기반 스타일 작성과 관련하여 React가 출시 된 이후 모든 새로운 프로젝트를 눈치 채 셨나요?

네, 다음 분기는 jss를 사용하고 있습니다.

@nathanmarks 이 변경 사항을 확인하려면 어디로 가야합니까?

찾았습니다 : https://github.com/callemall/material-ui/blob/next/docs/customization/themes.md

@bramick 은 next 에 관한 것이 아닙니다.

좋아, 그래서 나는 새로운 것을 놓치고 ... 누구?

@bramick next 는 아직 완전히 문서화되지 않았습니다 (그러나 문서화 사이트가 있습니다). 지금은 소스를 읽어야하고 문서 사이트 소스 코드를 참조하여 작동 방식을 확인할 수 있습니다. 일부는 여전히 움직이는 표적 일 수 있습니다.

트윗 담아 가기 깊이있는 답변에 감사드립니다.

전적으로 동의한다고 말할 수는 없지만 제가 가진 몇 가지 질문을 도전적으로 해결하셨습니다.

동의합니다. 우리 스타일이 컴포넌트 기반의 세계로 나아가 야하고 CSS가 그에 적합하지 않습니다. 그러나 (내 의견으로는) 우리가 이것을 대규모로 채택하기 전에 제거해야 할 몇 가지 주름이 있습니다.

그래도 궁금합니다. 이와 표준 CSS 사이에 성능 차이가 있는지 확인한 사람이 있습니까? CSS가 자바 스크립트에 여전히 우위를 점하고있을 것 같습니다. 로드 한 후에도 여전히 스타일을 생성하고 삽입해야합니다.

@gdaunton https://github.com/cssinjs/jss/blob/master/docs/performance.md 에서 jss 성능에 대해 읽어보십시오.

렌더링되고 페이지에 추가되지만 구성 요소 내에서 작성된 표준 CSS입니다. 나는 next 브랜치를 사용하고 있으며 꽤 잘 작동합니다.

@newoga 말씀하신 내용에 대한 링크를 보내 주시겠습니까?

@bramick OMG! 정말 간단하지 않나요? 예를 들어 next Button에 대해서는 여기를보십시오 .

JSX가 성공한 후 JavaScript 파일에 CSS를 넣는 것이 매력적이라는 것을 이해하지만 응용 프로그램의 모든 CSS에 대해 동일한 작업을 수행하는 것이 좋은 생각인지 확실하지 않습니다. 예를 들어 매우 복잡한 동적 스타일을 다룰 때 JSS에 좋은 사용 사례가 있다는 것을 알고 있습니다.

나의 가장 큰 관심사는 스타일 정보가 결국 컴포넌트 정의를 복잡 하게 만들 것이라는 것입니다. JavaScript 객체로 표현 된 CSS는 훨씬 더 장황 하고 구성하기가 더 어렵습니다 . 예를 들어, 이전 게시물에서 참조한 Button 컴포넌트에서 코드의 거의 절반이 스타일 정보입니다. 더 이상 우려의 분리가 없습니다. 스타일 코드를 별도의 파일로 옮길 수 있다는 것을 알고 있지만, 처음부터 JavaScript에서 사용할 필요가 없습니다.

개발자에게 가장 큰 단점은 CSS 속성 및 해당 값에 대한 모든 인텔리 센스 정보 를

더 많은 가치를 가져다 준다면 내 프로젝트에 복잡성을 추가해도 괜찮습니다. 그래서 추가 CSS 린터, 전 처리기, 로더 및 내가 배워야하는 추가 구문은 신경 쓰지 않았습니다. 나는 또한 JSS에 대해 공개적으로 유지하려고 노력하고 있습니다. 그것은 단지 첫 번째 모습 이후에 나를 설득하지 못했습니다.

내 가장 큰 관심사는 스타일 정보가 결국 구성 요소 정의를 복잡하게 만든다는 것입니다.

이것은 전적으로 당신에게 달려 있으며, 코드를 어떻게 구성 하느냐에 달려 있습니다. 규칙을 고수하면 나쁜 일이 일어나지 않습니다 (2 년의 생산 경험에서 이야기).

JavaScript 객체로 표현 된 CSS는 훨씬 더 장황하고 구성하기 어렵습니다.

코드 재사용 수준이 높고 반복 횟수가 적기 때문에 실제로 덜 장황합니다.

개발자에게 가장 큰 단점은 CSS 속성 및 해당 값에 대한 모든 인텔리 센스 정보를 잃는다는 것입니다.

여기서 목표는 material-ui 사용자에게 스타일링에 원하는 것을 사용할 수있는 선택권을주는 것입니다. CSS 자동 완성은 자주 듣는 주장입니다. 대부분 cssinjs를 많이 사용하지 않은 사람들과 이전에 사용하던 편의성을 잃어 버리는 것에 대한 두려움 때문입니다.

더 많은 가치를 가져다 준다면 내 프로젝트에 복잡성을 추가해도 괜찮습니다.

요점은 복잡성을 줄이고 코드베이스를보다 일관되고 사용 및 이해하기 쉽게 만드는 것이라고 생각하지만 모든 복잡한 시나리오를 동시에 다룹니다.

내 가장 큰 관심사는 스타일 정보가 결국 구성 요소 정의를 복잡하게 만든다는 것입니다.

프로젝트에서 컴포넌트의 스타일 정보를 별도의 파일로 추출하고 웹팩으로로드했습니다. 주요 이점은 모든 것이 잘 구성되어 있고 웹팩이 구성 요소별로 코드를 번들로 제공 할 수 있으므로 js 코드와 스타일 정보의 코드 분할이 가능하다는 것입니다.

또한 스타일링 규칙을 생성하기 위해 로직을 분리 할 때 우려 사항이 분리됩니다. 한 가지 예는 잘 알려진 css 전 처리기에서 믹스 인과 매우 유사한 stlying을 생성하는 스타일 팩토리 함수를 도입 한 것입니다.
내 요점은 자신의 특정 워크 플로우를 모델링하고 프로젝트와 팀의 요구에 가장 잘 적응할 수있는 훨씬 더 많은 유연성을 확보한다는 것입니다.

이 https://styled-components.com/ 확인

기술을 변경하는 것은 게임의 후반부이지만 스타일 구성 요소가 매우 유망하다는 데 동의합니다. SSR, 미디어 쿼리, 꽤 멋진 구문 등을 처리합니다. JSS와 비교하여 자동 접두사 및 테마도 처리합니다.

내가 아는 한 내부에서 postcss를 사용하므로 런타임에 사용할 때 허용되는 성능을 제공하지 않습니다. 왜냐하면 많은 에지 케이스 처리 및 플러그인이있는 전체 CSS 파서이기 때문입니다. 나는 이것을 JSS JSON으로 전처리하는 것을 상상할 수 있지만, 솔직히 말해서 CSS 언어를 사용하고 JS 변수 및 함수 호출과 혼합하는 것보다 JS를 끝까지 사용하는 것에서 그다지 가치가 없다고 생각합니다.

언급하자면 현재 스타일 구성 요소의 빌드는 이미 축소 된 250kb입니다. 공평하게 말하면 React와 co를 번들로 묶기 때문이지만 PostCSS 파서만으로도 이미 JSS 또는 Fela의 크기에 가까운 13kb (최소화되지 않음, 2kb ~)가 있습니다.

(프레젠테이션) 구성 요소의 빠르고 간단한 프로토 타이핑에는 좋지만 다른 솔루션이 제공 할 수없는 이점 / 기능은 보이지 않습니다.

동의합니다. 제가 개발 한 도서관에서 시험해 보았는데 게시하기에 너무 무거웠습니다. 나는 그들이 그것으로 진전을 보일 것이라고 확신하지만, 여기에서 JSS 작업은 거의 완료되었고 대부분의 동일한 이점을 제공합니다.

최근 react-toolbox를 사용했는데, 기본적으로 webpack의 sassLoader 에 의존하는 CSS 모듈을 테마로 사용합니다. 저에게는 정말 잘 작동했습니다. 조사해볼 가치가 있을지도 모릅니다.

@mgcrea 의 의견을 두 번째로해야합니다. react-toolbox 테마 지원 은 놀랍습니다. 구성 요소의 모양을 사용자 지정하는 것이 프론트 엔드 스토리의 가장 중요한 측면입니다.

나는 누구도 좋은 오래된 CSS 스타일이 머티리얼 UI에서 일류 시민이 될 것이라고 기 대해서는 안된다고 생각합니다. 이것이 react-toolbox 가 시작된 이유입니다.

적어도이 주제에 대한 많은 이슈와 게시물을 읽은 후의 인상입니다. 팀이 React Native 호환성을 개선하기 위해 노력하는 것과 JSS로 쉽게 해결할 수있는 스타일링 엣지 케이스에 대한 많은 의견을 모호하게 기억할 수 있습니다.

그러나 그 정보는 많은 토론에서 손실됩니다. 이것은 논란의 여지가있는 주제이기 때문에 자바 스크립트 스타일링이 왜 그토록 깊이 뿌리 내리고 있는지에 대한 강한 언급과 함께 프로젝트 목표와 철학 (핵심 관리자가 작성한)에 대한 위키 페이지를 가질 수 있다면 그것은 놀라운 가치가 될 것이라고 생각합니다. 뼈대.

React를위한 가장 활동적이고 세련된 머티리얼 스타일링 프레임 워크이기 때문에 Material UI를 정말 좋아합니다. 그러나 JSS는 타사 구성 요소와 통합 된 스타일을 유지하고 싶을 때 많은 두통을 유발합니다.

저는 Material-UI가 react-toolbox와는 반대로 스타일링을 수행하는 방식에 감사 드리며 그 이유는 다음과 같습니다. 프로젝트 중 하나에서 사용자가 동적 테마를 선택할 수있는 기능이 있습니다.

사용자가 미리 결정할 수없는 색상 쌍을 선택할 수 있으므로 사용하는 테마 구성표는 매우 동적이어야합니다. 와, 테마 변경은 라이브로 발생할 수 있습니다. b / c 모든 스타일은 인라인으로 생성됩니다. 내가해야 할 일은 기본 / 악센트 색상을 지정하는 것뿐입니다.

반응 도구 상자 등에서. al., 이것은 내가 볼 수있는 것보다 더 많은 일인 것 같습니다.

@jrop 예,이 매우 특별한 경우에는 동적 JSS가 필요하지만 중요한 요구 사항이 아닌 많은 응용 프로그램의 경우 재료 UI를 사용자 정의하는 현재 스토리 (UI 테스트에 대해 말하지 않음)는 허용되지 않습니다. 우리는 대부분의 동작 부분이 필요하거나 원하기 때문에 기본 재질 UI 모양을 사용할 수없는 고도로 시각적이고 디자인 된 앱을 구축하고 있습니다.

@DominikGuzei jss를 사용하여 next 분기를 사용자 지정할 수 있습니다. 이것은 현재 릴리스에서 볼 수있는 것이 _ 아닙니다 _.

여러분, 여기서 죽은 말을 치고있는 것 같습니다. next 분기는 테마와 함께 다른 (훨씬 개선 된) 경로를 선택했으며 재정의를 허용합니다. 더 이상 인라인 스타일을 사용하지 않으며 내가 요청한 유연성을 제공합니다. 더 많은 사용자 정의 기능을 원하는 다른 사람들은 next 구성 요소에 대해 HOC를 사용하고 자신의 스타일 시트를 작성할 수 있습니다.

@nathanmarks ,이 결정이 내려 졌기 때문에 (내가 말할 수있는 한, 꽤 잘 작동합니다 👍), 요약을 작성하고이 문제를 닫고 잠그는 것이 좋습니다.

프로젝트 목표와 철학 (핵심 관리자가 작성한)에 대한 Wiki 페이지가있는 경우 자바 스크립트 스타일이 프레임 워크에 그토록 깊이 뿌리 박혀있는 이유를 강력하게 언급 할 수 있습니다.

@fgarcia 이번 주 초 파리에서 열린 지역 행사에서 Material-UI가 사용하는 스타일링 접근 방식의 진화 에 관한 프레젠테이션을했습니다. 슬라이드와 _notes_ : 더 나은 스타일을 향한 여정을 보는 데 관심이있을 수 있습니다. 저는 도전, 문제 및 해결책에 중점을 둡니다.

동적 테마를 선택하는 사용자

CSS-Modules의 정적 스타일 생성 측면은 상당한 결과를 가져옵니다.
런타임에 스타일을 삽입하는 것은 비용 효율적이지 않지만 다음을 수행 할 수 있습니다.

• 스타일 구현에 더 많은 유연성을 제공합니다. 예 : CircularProgress 에는 CSS 키 프레임 애니메이션이 구현되는 방법에 연결된 고정 thickness 가 있습니다. 동적 스타일을 사용하면 사용자가 값을 동적으로 변경할 수 있도록 두께 속성을 추가 할 수 있습니다. ⚠️ 학대 당하지 마십시오.
• 대규모 앱에서는 화면에 표시되는 구성 요소에 필요한 스타일 만 삽입 할 수 있습니다. 페이지를 부트 스트랩하기 위해 브라우저에 필요한 작업량을 줄입니다. 따라서 상호 작용 후 처음 페인트하는 시간이 더 빠릅니다. 예를 들어 SSR로 중요한 CSS를 인라인합니다.
• 사용자가 동적 테마 및 구성 요소의 변형을 사용할 수 있습니다. 예를 들어, 필요한 모든 색상 변형으로 버튼의 색상을 변경합니다.

@oliviertassinari 정말 굉장합니다. CSS 모듈과 관련하여 비표준적인 관점을 가지고있을 수 있지만 모든 소란스러운 가치가 있다고 생각하지 않습니다. 이런 이유로 material-ui를 통해 JSS를 접하게되어 기뻤습니다. CSS 모듈보다 JavaScript 철학과 훨씬 더 밀접한 것 같습니다.

@oliviertassinari 혜택 요약에 감사드립니다. 이러한 측면을 보면 확실히 흥미 롭습니다. 현재 JSS와 생태계 (postcss)의 단점은 모든 것이 최첨단이며 간단한 CSS 모듈 + SASS와 같이 잘 확립 된 도구 체인 및 지식 기반에 의존 할 수 없다는 것입니다. 그러나 그것은 혁신에 대해 지불하는 대가이며, 특정 요구 사항이 있거나 버그에 대한 대가를 지불 할 의사가 있는지 여부와 덜 문서화 된 경로에 따라 다릅니다.

JSS는 css-modules 이전에 생성되었습니다. CSS 모듈은 구문을 너무 근본적으로 변경하지 않고도 대다수 사용자의 문제를 해결했기 때문에 더 빠르게 대중화되었습니다.

즉, "새로운"기술인 react를 사용하고 있습니다. SASS를 원한다면 vanilajs 또는 backbonejs도 선택해야합니다.)

@kof React는 수십만 명의 개발자가 사용하고 Facebook에서 관리하므로 (하룻밤 사이에 사라지지 않음) 매우 다른 이야기이므로 "새롭지 만"매우 견고 할 수 있습니다. 지금까지 많은 문제).

SASS는 가장 잘 확립 된 CSS 전 처리기 중 하나이며 모든 프로젝트에서 사용할 수 있습니다. 매우 견고하고 테이블에 많은 가치를 제공합니다. 그래서 나는 절대적으로 필요한 경우 (예 : 동적 테마 때문에) JSS와 같은 것을 선택하지만 여러 개발자가 참여하는 상용 소프트웨어 프로젝트에서 수년간의 경험 / 프레임 워크 / 지식 기반 등을 버리는 것을 싫어합니다. 그래서 JSS에서 동적 테마 측면 만 구축하고 나머지는 sass / css-modules로 구축하는 것도 고려할 것입니다.

나는 이러한 사고 방식을 이해하지만, 또한 그것을 반 생산적이라고 생각하고 혁신과 산업을 늦추는 것에 대해 비난합니다.

왜 둘 다 지원하지 않습니까? JavaScript로 작성된 스타일과 CSS 모듈로 작성된 스타일? 예를 들어 https://github.com/callemall/material-ui/blob/next/src/Button/Button.js 를 살펴보면 prop ( https://github.com/javivelasco/react-css-themr) 대신 다음을 사용하십시오.

const classes = this.context.styleManager.render(styleSheet);

그렇지 않나요?

JSS 또는 CSS 사용에 대한 논의가 끝을 찾는 것 같지 않습니다 (아직?). 나에게 그것은 현재 50/5처럼 보입니다.

SASS와 관련하여 react-toolbox는 현재 전체 postCSS 솔루션을 선호하여 마이그레이션하고 있습니다. 개인적으로 postCSS (sassLike 플러그인 포함)가 더 나은 선택이고 빌드 deps없이 더 강력하다고 생각합니다.

모든 JS, 특히 React의 스타일링은 분명히 여전히 빠른 진화 상태에 있습니다. 그래서 당신이 무엇을 하든지, 나는 자신의 의견을 피하려고 노력할 것입니다.

* style prop이있는 곳에 * className prop을 추가하는 것을 고려하십시오. 기간.

전체 공개 : 저는 행복한 아프로디테 사용자입니다.

className 추가는 인라인 스타일 ( style 속성에서)이 우선하므로 여전히 !important 해킹이 필요합니다.

@ligaz 물론 당신 말이 맞아요. Aphrodite는 기본적으로 모든 항목에 !important 를 추가하므로 "광범위한 사용"에 대한 내 생각이 심하게 왜곡되어있을 수 있습니다.

@ligaz @estaub - next 이미 _without_ 코딩 style 제공하여 대체 할 구성 요소와 수의 사용자를 className (복잡한 구성 요소의 여러 부분과 여러 클래스 이름) .

관리자가 next 브랜치에 설정 한 스타일링 패러다임은 JSS를 사용하고 있습니다. 사용하는 것이 즐겁고 개인 또는 테마별로 재정의하기 쉽습니다.

이 말은 죽었습니다. 그만 치자. @oliviertassinari next 에 대한 지시문으로이 문제를 닫고 잠그는 것이 좋습니다.

안녕하세요 @rosskevin- 이것이 다음에 어떻게 작동하는지에 대한 예를 알려주시겠습니까?

저는 현재 새로운 프로젝트를위한 프레임 워크를 찾고 있습니다. 머티리얼 UI를 사용하고 싶지만 다음에 언급 한 변경 사항이 필요합니다. 테스트 프로젝트에 다음 분기를 추가하고 간단한 구성 요소를 추가했는데 인라인 스타일로 가득 찬 관리자가 표시됩니다. 그래서 제가 뭔가 잘못하고있는 것 같아요?

자세한 내용은 정말 도움이 될 것입니다!

감사

@giuseppepaul next 는 사전 알파이고 아직 완료되지 않았기 때문에 npm에 게시되지 않았습니다. https://github.com/callemall/material-ui.git#next 를 복제하고 docs/site 를 실행하여 더 이상 인라인 스타일이 없는지 확인할 수 있습니다. 또한 합리적인 양의 데모가 있습니다.

다음 버전의 비공개 버전을 게시하고 있으며 (업데이트를 제어 할 수 있도록) 곧 프로덕션 애플리케이션으로 사용할 예정입니다.

이 말은 죽었습니다. 그만 치자. @oliviertassinari 나는 당신이 다음 방향의 진술로이 문제를 닫고 잠그는 것이 좋습니다.

그 말은 완전히 죽지 않았습니다. 그러나 확실히 빡빡한 곳에서 🔫.
동의합니다.이 문제를 종료하겠습니다.

그 이야기에 대한 그의 노력에 대해 @nathanmarks 에게 큰 감사를
앞으로의 길에 대한 더 많은 정보를 # 5718로 모았습니다.

안녕하세요,
IconButton 에는 물결 효과를위한 CSS3 transition 속성이 있습니다. Card @next 문서의 복잡한 상호 작용에서 아이콘이 반전 될 때 전환을 추가하기 위해 변형에 transition 를 추가했습니다.
내 앱에서 동일한 작업을 수행하면 한 전환 (리플 또는 복귀)이 다른 전환을 재정의합니다 (요소에 두 개의 속성이있을 수없고 그렇지 않으면 하나가 다른 하나를 재정의 함).
그러나 쉐브론 아이콘에는 두 개의 transitions 가 성공적으로 적용되었습니다. 어쨌든 IconButton 제공하는 전환과 코드에 정의 된 전환을 병합하기 때문입니다. 어떻게 달성합니까?
다른 것들은 저에게 모호하며 관련 문서를 찾을 수 없습니다. theme 에는 breakpoints (여기에서는 사용되지 않음) transitions (여기에서 사용됨)와 같은 많은 메서드 / 속성이 있습니다. theme 속성에 대한 문서가 이미 MuiThemeProvider.createDefaultContext() 반환하는 것에 대한 문서가 있습니까? 특히 코드 내에서 광범위하게 사용된다는 점에서 유용 해 보입니다.
this.context.styleManager.render(styleSheet) ? 뭐 ?
또한 사용 jss-theme-reactor 나는 아직도 비교 점을 이해하지 않는 react-jss .

@NitroBAY 이 스레드는 끝났습니다. 버그를 발견하거나 문서 개선을 원하면 문제를 제기하십시오. 그렇지 않으면 gitter.im의 StackOverflow를 사용할 수 있습니다.