さらにいくつかの質問：
6） xxxxStyle小道具を削除するか、削除することを目指して、スタイルを上書きするためにユーザーにxxxClassNameを渡してもらいますか？ それともこれらは無料ですか？
7）CSSを介したスタイルのオーバーライドを許可し、コンポーネントインターフェイスを簡素化しますか？ したがって、IconMenuでmenuItemStyleをオーバーライドする場合、 style = StyleSheet.create({ IconMenu: {MenuItem: { color:red }})タイプのオーバーライドを作成しますか？

@chrismcv私の個人的な意見では、提案されているこれらの超特定の小道具を削除するには、ソリューションを活用する必要があります。[TextField] floatLabelFocusStyle小道具＃4043を追加

私たちがそれを知る前に、人々はすべての可能なフォーカス/アクティブ/ホバー/どんな状態でもサブコンポーネントスタイルの小道具を求めようとしています。

「XXXXのスタイルを設定する方法」、「YYYY内でXXXのスタイルを設定できない」、「XXXにsomethingInsideToTheLeftButSlightlyMiddleFocusHoverActiveStyleプロップを追加してください」などの問題がたくさんあります。

6.の@chrismcvは、より一般的なxxxxStyle小道具とclassNamesについて、どう思いますか？ 一部のコンポーネントでは、何らかの方法で到達できる必要があります（ただし、幸い、 :hoverなどを使用できます）。

@chrismcv xxxxStyle小道具は、 className化されたスタイルのオブジェクトではなく、 styleプロパティに配置する必要があると思います。

@nathanmarks会話をブートストラップしていただきありがとうございます。 これは間違いなく、次のリリースで対処する必要のある主要な問題の1つです💯。

パフォーマンスの問題以外

私にとって、それは私たちが選択するソリューションに関して私が抱えている主な懸念事項の1つです。
現在のアプローチでは多くのCPUサイクルが失われたことは容易に想像できるので、ベンチマークはあまりありません。 CPUサイクルは、インラインスタイルオブジェクトのメモリ割り当てとガベージコレクションで失われます。

@oliviertassinari

私は現在、いくつかのJSスタイルのソリューションで遊んでいます。 興味深いですが、いわばまだ「初期」であることは明らかです。

私が考えていたのは、動的スタイルのプロパティ以外（たとえば、コンポーネントにcolor小道具がある場合）、基本スタイルオブジェクトの作成方法を変更する必要があるかどうかです。

JSスタイルのライブラリのように見えます。最大のパフォーマンスを得るには、 StyleSheet.create()メソッドを1回使用し、そのオブジェクトにopen={true}などの小道具/状態用のキー（css "classes"）を含める必要があります。いくつかの条件付きプロパティを使用してスタイルオブジェクトリテラルを動的に構築し、それをすべての単一スタイルのすべてのレンダリングでスタイルシートファクトリメソッドに渡すのではありません。

スタイルシートセレクターは、DOMに一度だけ書き込まれるという意味でキャッシュされますが（一部のライブラリでは、 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パラメーターよりも要素のstyleパラメーターを使用したいものは避けたいと思います。

@chrismcvありがとう！

ある意味で、JSスタイリングは通常のCSSからのパラダイムシフトであるため、 @ rvbyronが言わなければならないことが重要だと思います。 ほとんどの人は日常の仕事でJSスタイリングを使用しておらず、別の考え方が必要です+通常JSにあまり熟練していないプロジェクトに貢献する可能性のあるデザイナーにとっては困難です。

ここですべての角度を考慮することが重要です。

@oliviertassinari @chrismcv

react-lookについて私が気付いたのは、すべてのコンポーネントをlook HoCでラップする必要があるということです。 これはかなり侵襲的であるように思われ、 render()関数をハイジャックし、 super.render()をconstに格納し、そのようにスタイル解決操作を実行します。 Khan / aphroditeなどの他のソリューションでは、 className={}内のStylesheet.create()からのstyles.xxxx参照の関数ラッパーが必要です。

cssのためだけにrender()関数を乗っ取るのは、私には過剰に設計されているようです。 この種の深く統合されたスタイル機能のためのReact組み込みツール/サポートが存在しないことを教えてくれます。CSSヘルパーHoCがすべてのコンポーネントのレンダリングを制御するという考えについてはよくわかりません。

考え？

こんにちはマテリアル-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スタイルの実装、調整、および維持に役立ちます。

@chrismcv

メールを見つけて解説に入れてくれてありがとう！

両方の世界の行動アプローチのベスト？

ニーズに最適なスタイリングテクニックをインポートするという「動作」の概念についてはどうでしょうか。 「StyleTheme」または「ClassTheme」のインポートを使用して、動作を選択できます。 StyleThemeは、muiThemeオブジェクトマテリアルを参照できます-uiは今日持っており、コンポーネント中心のスタイリング開発者を満足させます。 または、muiTheme.jsオブジェクト（同期）から構築されたSCSSファイルを使用するClassThemeにより、CSS中心の開発者を満足させることができます。 つまり、すべてのコンポーネントがレンダリング要素の{... theme.ComponentName}に対応する必要があります。

非常に単純化された例を提供するために、RoundButtonコンポーネントには次のようなrenderメソッドがあります。

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'
}

2つの組み合わせは、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プロパティがオーバーライドされます。

@oliviertassinari

scss （+名前空間/ハッシュ用のcssモジュール）のようなものを使用することには多くの利点があると思います。 これはあなたが100％反対していることですか？ 仕事で慣れているので少し偏見があるかもしれませんが、同じ船にたくさんの人が乗っています。

JSスタイリングの状況に関する私の主な問題は、すべてのソリューションがまだ進行中のように感じることです。 実際のパフォーマンス評価はそれほど多くありません。私たちが見ているライブラリは証明されておらず、JSでスタイルを適切に行う方法を理解するために多くの時間を費やし

これに関しては、さまざまな懸念があると思います。

1. 静的スタイルを配置する場所（簡単、cssファイルで実行できます）
2. 入力に応じていくつかのスタイルを切り替える方法（classNameスイッチ）
3. 動的スタイルを適用する方法（インラインスタイルはそれを行うことができます）

アプリケーションを作成しているときはすべて問題ないようです。コード外の人は何も変更する必要はありません。

しかし、図書館では物事が異なり、上記のすべての懸念に加えて、次のことがあります。

1. ユーザーが静的スタイルをカスタマイズできるようにするにはどうすればよいですか？
2. 切り替え、カスタマイズ、分離が簡単な方法でテーマを実装するにはどうすればよいですか（異なるサブツリーの異なるテーマ）？
3. 他の人とうまく遊ぶことができるように、グローバル名前空間の汚染を回避するにはどうすればよいですか？
4. ユーザーはどのようにしてインライン化された動的スタイルをオーバーライドできますか？
5. トランスフォーマー！ （rtl、プレフィックスなど）

私たちが今持っているものは、どういうわけかこれらの警告に関するこれらすべての懸念を処理します：

1. パフォーマンス！
2. @nathanmarksが言ったように、深くネストされたコンポーネントはカスタマイズが困難です： somethingInsideToTheLeftButSlightlyMiddleFocusHoverActiveStyle
3. 一部のCSS機能の機能を利用できません。

スタイリングのアプローチを変更した場合は、もう一度やり直す必要があります。 その場合は、移行を開始する前に、必ずこれらすべてに回答する必要があります。

私の謙虚な意見では、CSSとそれにコンパイルされるものは将来の一部ではないと思います。 インラインスタイルが私たちの生活をずっと楽にしてくれたことに私たちは皆同意していると思います。 正直なところ、インラインスタイルで見られる唯一の制限は:hoverです！

少し設計を行うことで、これらの問題を解決できます。

1. スタイルオブジェクトをメモ化します。状態を持つコンポーネントの場合、状態を分解して小さなコンポーネントに配置し、上位のコンポーネントの状態である渡された小道具に基づいてスタイルオブジェクトをメモ化できるようにします。 これは簡単に解決できます！
2. それらを分解してください！ なぜたくさんの小さな機能が埋め込まれたListItemがあるのですか？ 分解して構成可能にすると、 somethingInsideToTheLeftButSlightlyMiddleFocusHoverActiveStyleような怪物を追加する必要がなくなります。
3. まぁ！ 私たちがパフォーマンスを得るのは:hoverだけです。ブラウザーまたはreactがそれについて何かをするまで、私たちはそれで生きることができると思います。

私のポイントは、現在のスタイリングアプローチですでに膨大な数の懸念に対処しているということです。 インラインスタイルのすべてのパターンに従わないため、制限があります。 コンポーネントを分解し始めて、より構成しやすくすれば、何も心配する必要はありません。 MeuItemを取る私はそれを取り出して構成可能にしました。それがいかに使いやすく、純粋なレンダリングを使用してパフォーマンスをどのように改善できるかがわかります。

したがって、アプローチを変更してこれらすべての問題を再度解決する代わりに、すでに持っているものを改善するために時間を費やしましょう。 メディアクエリをサポートする必要はありません。他の人が簡単に応答性を実装できるようにコンポーネントを変更できます。 デバッグするのは難しいですか？ コンポーネントを分解すると、インラインスタイルは小さくなり、読みやすくなります。 しかし議論の余地がある！ つまり、必要なのは、 Object.assignに参加しているものを確認して、スタイルがどこから来ているかを確認するためのブレークポイントだけです。

もちろん、それは私自身の意見です。私は非常にオープンに議論しています。

@alitaheri

あなたはいくつかの素晴らしいポイントを上げます。 ありがとう。 ある種のハイブリッドソリューションが可能かどうか疑問に思います。 どんな角度をとっても、たくさんの問題があるようです😆

来週は作業する時間があります。チャットをして、賢いアイデアを思いつくことができるかどうか見てみましょう。

変更の量を最小限に抑え、すでに解決済みの問題を解決する必要があることに同意します。 私の頭の中には2つの重要な目標があります。

1. パフォーマンス
2. 開発者の経験（JSスタイルのライブラリは、開発者がアプリケーションでクラスを簡単に使用できるようにすることで、ここで大いに役立ちます）

これについてもっと考える必要があります😄しかし、これらの2つのポイントを解決できれば、私たちのソリューションに満足します。

別のランダムなメモ-ライブラリ全体でインライン/ jsstyle /その他の特定のコード規則とデザインパターンを強制する自動化された方法があれば素晴らしいでしょう。

これはあなたが100％反対していることですか？

@nathanmarks私はSCSSの使用に100％反対しているわけではありません（ 行き止まりです。
Reactの主な利点の1つは、ブラウザーのレンダリングの特異性であるDOMを抽象化することです。
私の知る限り、React Core Teamの長期的な目標は、クロスプラットフォームコンポーネントを作成するためのAPIを提供することです。 実際、彼らは現在この方向に

@alitaheriに完全に同意します。 これらの2つのステップから始めることができます。

• 後で簡単に移行できるように、どこでもgetStylesパターンを使用してください。
  codemodを使用できますか？ 知るか。
• @alitaheriによって提案された各コンポーネントの内訳。

@oliviertassinari私は行き止まりの結論に同意します-それは未来ではありません。 私は主に、JSスタイルを私たちのために機能させる方法についての会話を刺激するためにそれを持ち出しました。 この辺りの何人かの人々が問題を取り巻くいくつかの良いアイデアを持っていることを私は知っていました😄FBが彼らの実験と一緒に_小さな_少し_だったらいいのに！

私たちが現在採用しているgetStyles()パターンには、それ自体に問題があると思います。 @alitaheriと私は今日、JSスタイルのセットアップを改善するために何をすべきか（テーマを含む！）についてかなり良いチャットをしました。 メモを書き留める機会がありましたら、明日、さらに情報を返信します。

来週は休暇中です。すべてのスタイルをJSベースに保ちながら、現在の問題の解決策を試す予定です。

Reactアムステルダムで学んだ教訓に関するこの投稿（https://medium.com/@kitze/lessons-learned-at-react-amsterdam-51f2006c4a59#.o12h794or）を読んでください。プレゼンテーションの1つは、Reactでのスタイリングのソリューションに関するものでした。http ：//slides.com/kof/javascript-style-sheets#/このディスカッションのタイムリーなプレゼンテーション。

私が考え続け、明示的に述べられていない（少なくとも私が覚えている）要件の1つは、WebのみとWebをサポートし、ネイティブに反応する必要があることです。 意図がWebのみである場合（つまり、React Nativeは必須ではありません）、ブラウザーがすでに効率的かつ堅牢にサポートし、人々が非常に精通しているものを活用するソリューションは良いことです。 反応ネイティブをサポートすることが必須である場合、それは異なるニーズと要件のセットを開きます。 テクノロジーの選択、妥協などが評価されるときに、考えて覚えておくべきことです。

@hburrows

そのプレゼンテーションを共有してくれてありがとう！

@alitaheri

そのプレゼンテーションで言及されているlibを見たいと思うかもしれません（これがデモです）。 それは私たちに多くの仕事を節約することができます。 以前はそれを見ていましたが、気に入らなかったことがいくつかありました（たとえば、すべてのコンポーネントを独自のHoCでラップする必要があるなど）。 ただし、ここで発生してます。 彼は、このような変更を実装すると、HoCを使用せずに使用できるaphroditeも見られます）。

または、 mixout機能するjss独自のreactバインディングをいつでも作成できます。

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の開発者を防ぐことができます。

以前のコメントで申し上げたように、この2つはうまく共存できると思います。 スタイルプロパティを適用するには、単に動作アプローチをとる必要があります。 ライブラリは、要素へのスタイルプロパティの直接適用に対応する必要があります。または、これらのスタイルプロパティで構成されるclassNameを作成する間接的なアプローチを許可する必要があります。 開発者が動作を選択できるライブラリは、理想的なソリューションのようです。

CSS開発者が単にアプローチを捨てたくない理由はたくさんあります。 「cssを使用する理由」を検索して、人々がそれが有益であると考える理由を確認してください。 スタイルの抽象化と強力なセレクター言語がその利点の1つであることがわかります。 CSSユーザーに利益をもたらす今日存在する膨大な量のコードを忘れないでください。

繰り返しになりますが、これは決してプロのCSS解説を意図したものではありません。 スタイリングにCSSを使いたいという人もいます。 このコメントは、開発者が選択できるようにする、アーキテクチャ的にニュートラルなスタイリングアプローチを奨励することを目的としています。

@rvbyron現在のアプローチを変更したい主な理由の1つは、cssを使用してコンポーネントを簡単にカスタマイズできるようにすることです。 jssようなライブラリを使用すると、jsスタイルを利用しながらcss機能を使用できるようになります。 そして、それらのスタイルをcssに変えるので、醜い!importantハックなしで、追加のクラス名で簡単にオーバーライドできます。

@alitaheri聞いて

繰り返しになりますが、classNameアプローチについて聞くのは素晴らしいことです。 これを念頭に置いて、どのように実装するかについていくつか質問があります。

• クラス名の命名規則はどのように見えると思いますか？
• すべてのクラス名に「mui-」またはその他のプレフィックスが付いていますか？
• クラスはコンポーネント名のダッシュ表記になりますか？
• クラス名は各コンポーネントのルート要素に適用されますか？

@rvbyron

理想的には：

カスタマイズ可能なプレフィックス。 開発エクスペリエンスを向上させるためのある種のダッシュ表記と、カスタムテーマIDを使用して固定文字列に設定できる（テーマ設定が変更されても変更されない）ハッシュサフィックス。 冗長性の低いプロダクションオプション、またはカスタマイズするコールバック関数も含まれます。 そして、ルート上のクラスは通常、とにかく常に必要になると思います。

記載されている要件や提案はたくさんあると思います。 それで、この議論のすべてからの持ち帰りはありますか？ 次の行動方針は何ですか？ このmaterial-uiにreact-jssを実装するために行われている作業はありますか？

@rvbyronうん、私たちは舞台裏でいくつかの大まかなアイデアを試しています。 より具体的なアイデアが得られたら、この問題を更新します。

私の謙虚な意見では、CSSとそれにコンパイルされるものは将来の一部ではないと思います。 インラインスタイルが私たちの生活をずっと楽にしてくれたことに私たちは皆同意していると思います。 正直なところ、インラインスタイルで私が目にする唯一の制限は：hover！です。

問題は、：hoverがスタイルの非常に基本的で非常に重要な部分であるということです。 未来派はさておき、ネイティブ機能を再実装するためにチートと回避策に頼らなければならないソリューションへの時期尚早なコミットメントを回避することが賢明かもしれません。

@wtgtybhertgeghgtwtg :hoverなどの機能がサポートされるように、実際のスタイルシートを使用するソリューションに向けて取り組んでいます。

主要なポイントが決定されていることを考えると（classNameとルート要素classNamesを介したJSSスタイリング）、material-ui v0.16.0リリースのロードマップとタイムラインはありますか？

@rvbyron約束されたタイムラインはありませんが、

@newogaありがとうニール！ アップデートに感謝します。 その他の問題については、classNameベースのシステムに移行するだけで、多くの人にとって視覚的に大きな変化になる可能性があることを付け加えたいと思います。このリリースをそれだけに限定することをお勧めします。 それに加えて他の変更が実際に移行を妨げる可能性があります。 しかし、私はあなたのチームが最良のバランスを選ぶことを知っています。

@newoga over here jssは、material-uiのスタイリングシステムの未来として呼び出されています。 これは、16.0のリリースを見越して、他の人が今すぐプロジェクトにjssをオンボーディングし始めることができるほど具体的な計画ですか？

@sorahnはまだ

@sorahnこの問題は、解決が非常に難しい問題についてコミュニティからフィードバックを得るために設計されています。 公式の決定はなされていません。 今のところ、誰もが自分と自分のプロジェクトに最適であると評価したスタイルライブラリまたはアプローチのみを選択して使用する必要があります。

ちなみに、このスタイリング変更の目標は、全員を別の標準に移行することではなく、使用するスタイリングアプローチに関係なく、Material-UIコンポーネントの使用とスタイリングを容易にすることです。

tl; drいいえ！ 他の誰かが言うことではなく、あなたにとって最善のことをしてください:)

@nathanmarks @newoga更新していただきありがとうございます！

レスポンシブデザインとすべてのインラインスタイルでのサーバー側レンダリングの制限に直面しているため、代替案を調査しています。 （s）css-modulesやcsxなどについて特に強い意見はありませんが、私たちはmaterial-uiが大好きなので、皆さんがやろうとしていることをすべてフォローするのは素晴らしいことです:)

私はメディアクエリに遭遇し、このスレッド（および他のスレッド）を読みました。 私はいくつかの潜在的な解決策と記事に飛び込みます。

私はJSS + CSXソリューションが本当に好きです（開発者の_喜び_の観点から）。

JSSのメリットとパフォーマンス

@sorahnと同様に、私はmaterial-ui標準を採用できれば幸いです。この方向で

@rosskevin私たちが話しているようにそれに取り組んでいます-これまでのどのソリューションでもカバーされていない、ここで考慮すべきことがあります。

私たちの要件は、設計上の制限や意見のために、既存のソリューションがサポートできるよりもはるかに広いものです。 これは主に、既存のソリューションが、コンポーネントAPIの消費を完全に制御できるアプリを念頭に置いて開発されているのに対し、さまざまなツールを使用してコンポーネントのスタイルを設定したいさまざまなユーザーがいるライブラリが原因です。

@sorahn簡単な質問-サーバー側レンダリングのベンダープレフィックスについて何をしていますか？ サーバー上のすべてのプレフィックスをレンダリングしているだけですか？ それともUAを通過していますか？

@nathanmarksユーザーエージェントをブラウザに送信していますが、個人的にはそれに依存するのは好きではありません。 それらをすべてデフォルトで配置し、muiThemeオブジェクトの小道具を介してそれらをオーバーライドできるようにするか、またはその逆で、デフォルトでは何も行わず、オプトインできるようにするのはどうでしょうか。

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

@sorahnプレフィックスではなくプレフィックスを付けたり、 allを渡したり、UAを渡したりするなど、好きなことを行うことができます。

@ nathanmarksjss @ 4.0.0をリリースしました。 最も重要な変更-決定論的IDの生成。これはreacthttp ： //jsstyles.github.io/examples/index.htmlを使用したssrの例です。

ここに$ .02を投入するだけです...インラインスタイルとアフロディーテのアイデアは本当に気に入っていますが、スタイルがブートストラップ4のようなscssのライブラリ形式に基づいている方が簡単だと感じています。

私が通常行うことは、_mixins.scssファイルを作成しながらbootstrap.scssファイルと_variables.scssファイルを文字通りコピーすることです...そのコピーを./lib/styleの下に置き、ローカルのbootstrap.scssファイルを更新してローカルを参照します他のすべてのnode_modulesのバージョンへのパスを使用しながら、変数とミックスイン...

次に、。/ lib / styleをsassLoader構成の検索パスの一部にするようにwebpack構成をセットアップします。

このようにして、ブートストラップなどをロードするmain.scssファイルを作成できます。そこからプロジェクトの残りの部分で変数やミックスインを参照できます。出力をビルド/バンドルする場合、適切なスタイルは次のとおりです。含まれています。

これの欠点は、マテリアルUIをソース（ビルド前ではない）として使用し、scssをバンドルに含めるためのwebpackを使用することを規定することです。 そうは言っても、既存の変数、クラス、スタイリングミックスインを使用するのがおそらく最も簡単な方法でしょう。

繰り返しになりますが、私はJSスタイリングのアイデアが本当に好きで、アフロディーテが提供するものが好きです...インラインスタイルのスタイリングライブラリと同様の（ダーマと呼ぶ予定です）作業を行っていましたが、アフロディーテはすでにすべてを行っています計画されているなど。

スタイリングソリューションは完成していますか？

これに関する更新はありますか？

はい、 nextブランチはjss

このプロジェクトに出くわしたばかりですが、見栄えがよく、サンプルページではコンポーネントの使用方法が非常に簡単にわかり、広く使用されているように見えたので、非常に興奮していました。 しかし、私はインラインスタイルに非常に失望しており、皆さんがインラインスタイルから離れているのを見てうれしいです。 私が指摘したいことの1つは、これらのコンポーネントの外側のレイアウトに関係するものはすべて削除し、親コンポーネントのスタイリングにそれを処理させる必要があるということです。 最下位レベルのコンポーネントには、周囲の要素を押しのけるようなマージンやパディングがないようにする必要があります...特に、インラインスタイルをいじらずにオーバーライドすることはほぼ不可能であるため、掘り下げて実行方法を見つける必要があります。それ。 残念ながら、このプロジェクトは使用できないと思ったので、このプロジェクトについてはあまり掘り下げていません。 私は確かにインライン対CSSスタイリングの多くの議論を読みました。 とにかく、あなたはTextFieldで私を失いました。 上に14px、下に16pxのマージンがあります。 それをオーバーライドするために単純なスタイルを書くことはあまり気になりませんが、インラインスタイルのためにそれは不可能であり、コンポーネントをdivでラップする場合のように、それを逆にするためだけに高レベルのコンポーネントを作成する必要があるのは完全にクレイジーですマージンを実行する：-14px 0 -16pxまたは計算で少し調整しますが、何らかの方法でそれを修正する必要はありません。 すでに行っているようにclassNameを小道具として渡すことを許可して、コミュニティが望む方法でレイアウトスタイルをコンポーネントに適用できるようにすると、さらに好まれます。 とにかく、それは私の$ .02です。

それに加えて、これらのレイアウトタイプのコンポーネントを作成したり、レイアウトプロパティを処理するための追加の小道具を作成したりすることは、ファンデーションやブートストラップのようなグリッドシステムを使用するなどの理想的な場合があります。 たとえば、サイズ、ガター、幅、列などの小道具を使用しますが、コンポーネントで表示されるものの外側をスタイリングしないことから始めます。

私は完全に@ jbsmith969と一緒です

コンポーネントをdivでラップしてマージンを実行する場合のように、それを逆にするために、より高いレベルのコンポーネントを作成する必要があるのは、私にとって完全にクレイジーです：-14px 0 -16pxまたは、計算で少し調整して、希望どおりにします

@ jbsmith969低レベルのコンポーネントにレイアウトロジックを含めるべきではないことに同意します。 ただし、アプリの特異性のために高度に抽象化されたコンポーネントを作成することは、まったくおかしなことに聞こえません。
IMHO、これはReactが可能にする最も強力なパターンの1つです（分離プロパティのおかげで）。

@oliviertassinari @ jbsmith969まさにそれが私たちがしたことです！ 2つのパラメータ（フィールド名と色）のように渡すCustomTextFieldコンポーネントを作成しました。これは、それらの周りにほんの少しのロジックを実行し、 material-ui/TextFieldをレンダリングします。欲しいです。

それはずっと下のコンポーネントです！

したがって、reactを使用して、htmlを取得してjsに入れます。これは、問題なく、ダンディです。 しかし、私たちのcssを取り、それを私たちのhtmlに押し込むのですか？ それは他の誰かとうまく座りませんか？

サスから離れることの利点は何でしたか？

昔ながらの私を呼んでください、しかし私たちの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はマテリアルデザインの仕様に従います。仕様に従わない場合は、何らかの回避策を

@vizathright私は間違いなく同じ考えを持っています。 しかし、このソリューションの利点は何ですか？

少なくともCSSと同じように実際に機能するソリューションがあれば、それを試してみることを検討します。 しかし、現在、警告なしにそれを行うことができる（私が知っている）解決策がないので、私は実際には頂点を見ていません。

なぜこのリポジトリは、ソリューションのアルファ段階のアイデアと思われるものを、他の点では非常に有用なコードベースに採用しようとしているのですか？ 私たちはまだテックを持っているとは思いませんし、これがそのテックの適切なテストベッドだとは思いません。

@nathanmarks JSSを使用してコンポーネントのスタイルをオーバーライドする方法についてアドバイスできますか？ nextの最新のコードを使用しています

編集：さて、それがまだ完全に実装されていないことを理解しただけです。 私の悪い！ 😬

オブジェクトキーのデッドコードを排除する良い方法はまだ見つかりませんでした。JSSでは、オブジェクトを使用してスタイルを保存する必要があります。

nextブランチのコンポーネントのランダムな例（まだ完了していません）： https ：
primary accentクラスと

同じ理由で、以前はMUIがインラインスタイルを管理していた方法も好きではありませんでした（スタイルが個別に定義されている場合、lintは未使用の変数をキャッチしていました。https：//github.com/callemall/material-ui/blob/を参照してください） 60a202fdc9645aa00f20c52e5152f168a1b0031b / src / IconButton / IconButton.js＃L26）。

サスから離れることの利点は何でしたか？

@gdauntonインラインスタイル/ sassアプローチを使用しないことに関してあなたが

ユーザーの観点からは、次の改善が提供されます。

• キャッシュされて生成されたCSSシートに依存するため、より高速な反応レンダリング方法。
• CSSの優先順位はインラインスタイルの優先順位よりも低く、ユーザーはDevToolsを使用して変更するシートを識別できるため、簡略化されたスタイルのオーバーライド。
• サーバー側のレンダリングを行うときの最初のペイントが高速になります。
  
  
  
  • ユーザーは重要なCSSシートをインライン化でき、ページ内で使用されているものだけをインライン化できます。 それは大きなモノリスなので、_Bootstrap_ではできないことです🙈。
  
  
  • ユーザーは、本番環境でクラス名キーを醜くすることができるはずです。
  
  
• _scss-loader_や_Webpack_のようなビルドチェーンの依存関係はありません。

コントリビューター/メンテナーの観点から、次の改善が提供されます。

• CSSリンターはもうありません
• プリプロセッサCSSはもうありません
• 学ぶべきCSS構文はありません
• コンポーネントのスタイルを設定するためのはるかに強力な言語：JavaScript
• スタイルエンジンを抽象化する可能性を開きます。 たとえば、 react-with-stylesを使用

このレポがアルファステージのアイデアと思われるものを採用しようとしているのはなぜですか

アルファステージのアイデアの意味によって異なります。
このアプローチを使用したのは私たちだけではありません。 例：AirBnB、カーンアカデミー、ReactNative。

少なくともCSSと同じように機能しました

CSSは、コンポーネントではなく、ドキュメントのスタイルを設定するために最初から設計されました。
それは私たちの業界の大きな変化です。

私の観点からは、それはスタイリングコンポーネントにひどいです。
Web仕様の背後にいる人々はこの問題をよく知っており、ローカルスコープスタイルの_WebComponents_で対処しようとしています。
CSSの改善とコンポーネントベースのスタイルの作成を中心にReactがリリースされて以来、これらすべての新しいプロジェクトに気づきましたか？

はい、次のブランチはjssを使用しています

@nathanmarksこの変更に追いつくためにどこに行けばいいですか？

見つかりました： https ：

@bramickは、0.15.0から開始されて動作しているためnextについてで

わかりました、それで私は何が新しいかを逃しています...誰か？

@bramick nextはまだ完全に文書化されていません（ただし、文書化サイトはあります）。 今のところ、ソースを読む必要があり、ドキュメントサイトのソースコードを参照して、それがどのように機能するかを確認できます。 それのいくつかはまだ動く標的かもしれないことをただ理解してください。

@oliviertassinariうわー！ 綿密な対応に感謝します。

私が完全に同意するとは言えませんが、あなたは私が持っていたいくつかの質問を反抗的にクリアしました。

私は同意します、私たちは私たちのスタイルがコンポーネントベースである世界に向かって動くべきです（そしてそうです）、そしてcssはそのために素晴らしいものではありません。 しかし、（私の意見では）これを大規模に採用する前に、解決すべきいくつかのしわがまだあります。

私は興味がありますが、これと標準のcssの間にパフォーマンスの違いがあるかどうかを確認した人はいますか？ 私はcssがまだjavascriptで優位に立っているように感じます。 ロードした後も、スタイルを生成して挿入する必要があります。

@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プリプロセッサを正しく使用すれば、その優れたコード構造と表現力がすべて気に入っています。

それがより多くの価値をもたらすのであれば、プロジェクトに複雑さを加えてもかまいません。 そのため、追加のCSSリンター、プリプロセッサー、ローダー、および学習する必要のある追加の構文を気にすることはありませんでした。 私もJSSについてオープンであり続けようとしています、それは最初の外観の後でそれが私を納得させなかったということだけです。

私の最大の懸念は、スタイル情報がコンポーネント定義を乱雑にすることになるということです。

これは完全にあなた次第であり、コードをどのように編成するかによって異なります。いくつかのルールに固執すれば、悪いことは何も起こりません（2年の生産経験から話しています）。

JavaScriptオブジェクトで表現されたCSSは、はるかに冗長で整理が困難です。

コードの再利用レベルが高く、繰り返しが少ないため、実際には冗長性が低くなります。

開発者にとって最大の欠点は、CSSプロパティとその値に関するすべてのインテリセンス情報が失われることです。

ここでの目標は、material-uiのユーザーがスタイリングに必要なものを何でも使用できるようにすることだと思います。 CSSの自動補完は、私がよく耳にする議論です。 ほとんどの場合、cssinjsをあまり使用しなかった人々から来ており、以前の便利さを失うことを恐れているだけです。

それがより多くの価値をもたらすのであれば、プロジェクトに複雑さを加えてもかまいません。

重要なのは、複雑さを軽減し、コードベースをより一貫性があり、使いやすく、理解しやすいものにすることだと思いますが、すべての複雑なシナリオを同時にカバーしています。

私の最大の懸念は、スタイル情報がコンポーネント定義を乱雑にすることになるということです。

私たちのプロジェクトでは、コンポーネントのスタイル情報を個別のファイルに抽出し、webpackでロードしました。 主な利点は、すべてが適切に整理されており、webpackがコンポーネントごとにコードをバンドルできるため、jsコードとスタイル情報のコード分割が可能になることです。

また、ロジックを分離してスタイリングルールを作成すると、関心の分離が行われます。 一例として、よく知られているcssプリプロセッサでミックスインのようにスタイリングを生成するスタイルファクトリ関数を導入しました。
私のポイントは、独自の特定のワークフローをモデル化し、プロジェクトとチームのニーズに最適に適応するための柔軟性が大幅に向上することです。

これを確認してくださいhttps://styled-components.com/

テクノロジーを変更するのはゲームのかなり遅い段階ですが、スタイル付きコンポーネントが非常に有望であることに同意します。 SSR、メディアクエリ、非常に優れた構文などを処理します。 JSSと比較して、自動プレフィックスとテーマ設定も処理します。

私の知る限り、内部でpostcssを使用していますが、エッジケースの処理とプラグインが多数含まれている完全なcssパーサーであるため、実行時に許容できるパフォーマンスは得られません。 これをJSSJSONに前処理することは想像できますが、正直なところ、CSS言語を使用して、JS変数や関数呼び出しと混合することと、JSを完全に使用することにはあまり価値がありません。

言うまでもなく、styled-componentsの現在のビルドは250kbで、すでに縮小されています。 公平を期すために、Reactとcoがバンドルされているためですが、それでも、PostCSSパーサーだけでも13kb（最小化されていない、2kb〜）であり、すでにJSSまたはFelaとほぼ同じサイズです。

（プレゼンテーション）コンポーネントの迅速でシンプルなプロトタイピングには最適ですが、他のソリューションでは提供できないメリットや機能は見当たりません。

同意します。私が開発したライブラリで試してみましたが、公開するには重すぎました。 彼らはそれで進歩すると確信していますが、ここでのJSSの作業はほぼ完了しており、ほとんど同じ利点を提供しているようです。

私は最近react-toolboxを使用しましたが、基本的にwebpackのsassLoader依存するCSSモジュールをテーマに使用しています。 私にとって、それは本当にうまくいきました。 多分それは調査する価値があります。

ねえ、私は@mgcreaの意見を二番目にする必要がありreact-toolboxテーマのサポートは単純に素晴らしいです-コンポーネントの外観をカスタマイズすることがフロントエンドストーリーの最も重要な側面であるため、切り替えます。

古き良きCSSスタイリングがMaterialUIの第一級市民になることを誰も期待すべきではないと思います。それが、 react-toolboxが開始された理由です。

少なくとも、このトピックに関する多くの問題や投稿を読んだ後の私の印象です。 チームがReactNativeの互換性を向上させるために努力していることや、JSSで解決するのがはるかに簡単なエッジケースのスタイリングに関する多くのコメントをぼんやりと覚えています。

しかし、その情報は多くの議論の中で失われています。 これは非常に物議を醸すトピックであるため、プロジェクトの目標と哲学（コアメンテナーによって書かれた）に関するWikiページがあり、Javascriptのスタイリングがなぜそれほど根付いているのかについて強い意見があれば、信じられないほどの価値があると思います。フレームワーク。

Reactの最もアクティブで洗練されたマテリアルスタイリングフレームワークであるため、MaterialUIが本当に好きです。 ただし、サードパーティのコンポーネントとの統一されたスタイルを維持したい場合、JSSはずっと頭痛の種になります。

私自身は、react-toolboxのようなものではなく、Material-UIがスタイリングを行う方法に感謝しています。その理由は、次のとおりです。私たちのプロジェクトの1つでは、ユーザーが動的なテーマを選択できるようになっています。

ユーザーが事前に決定できない色のペアを選択する可能性があるため、使用するテーマスキームはどれも非常に動的である必要があります。 と、テーマの変更はライブで行うことができます。b/ cすべてのスタイルはインラインで生成されます。私がしなければならないのは、プライマリ/アクセントカラーを与えることだけです。

react-toolboxet。 al。、これは私が見ることができるものからの雑用のようです。

@jropええ、この非常に特殊なケースでは、動的JSSが必要ですが、多くのアプリケーションでは、これは重要な要件ではなく、マテリアルのカスタマイズの現在の話（UIテストについても言えません）-uiは単に受け入れられません。 私たちは、デフォルトのマテリアルUIの外観を使用するだけではなく、非常に視覚的で設計されたアプリを構築しています。これは、その動作部分がほとんど必要であるためです。

@DominikGuzeiは、jssを使用してnextブランチをカスタマイズできます。 これは、現在のリリースで見られるものではありません。

皆さん、ここで死んだ馬を倒しているような気がします。 nextブランチは、テーマを使用して別の（大幅に改善された）パスを選択し、オーバーライドを許可しています。 インラインスタイルを使用しなくなり、私が要求した柔軟性を提供します。 さらにカスタマイズ性が必要な場合は、 nextコンポーネントに対してHOCを使用して、独自のスタイルシートを作成できます。

@nathanmarks 、この決定が下されたので（私が知る限り、非常にうまく機能します👍）、要約を書いてこの問題を閉じてロックし、問題を見つけた人が今後の方向性を理解できるようにすることをお勧めします。

プロジェクトの目標と哲学（コアメンテナーによって書かれた）についてのWikiページがあり、Javascriptスタイリングがフレームワークに深く根付いている理由についての強い意見があれば。

@fgarcia今週初めにパリで開催された地元のイベントで、Material-UIで使用されているスタイリングアプローチの進化についてプレゼンテーションを行いました。 スライドと_notes_：より良いスタイルへの旅をご覧になることをお勧めします。 私は課題、問題、解決策に焦点を当てています。

動的テーマを選択するユーザー

CSS-Modulesの静的なスタイル生成の側面は、かなりの結果をもたらします。
実行時にスタイルを挿入すると、コスト効率が低下

• スタイルの実装により柔軟性があります。 たとえば、 CircularProgressは、CSSキーフレームアニメーションの実装方法にリンクされた固定のthicknessがあります。 動的スタイルでは、thicknessプロパティを追加して、ユーザーが値を動的に変更できるようにすることができます。 ⚠️虐待されないように。
• 大規模なアプリでは、画面に表示されているコンポーネントに必要なスタイルのみを挿入できます。 ページをブートストラップするためにブラウザが必要とする作業量を削減します。 したがって、インタラクション後に最初にペイントするまでの時間が短縮されます。 たとえば、重要なCSSをSSRでインライン化します。
• ユーザーが動的なテーマとコンポーネントのバリエーションを使用できるようにします。 たとえば、必要なすべてのカラーバリエーションでボタンの色を変更します。

@oliviertassinariそれは聞いて素晴らしいです。 私はCSSモジュールに関して非標準的な見方をしているかもしれませんが、それらが大騒ぎする価値があるとは思いません。 このため、material-uiを通じてJSSのことを聞いて興奮しました。 CSSモジュールよりもJavaScriptの哲学に沿っているようです。

@oliviertassinari特典の概要をありがとう。 これらの側面を見ると、間違いなく興味深いものです。 現時点でのJSSとそのエコシステム（postcss）の欠点は、すべてが最先端であり、単純なcss-modules + SASSのように確立されたツールチェーンとナレッジベースに依存できないことです。 しかし、それはイノベーションに支払う代償です。特定の要件があるかどうか、バグや文書化されていないパスの代償を払っても構わないと思っているかどうかによって異なります。

JSSは、css-modulesより前に作成されています。 CSSモジュールは、構文を大幅に変更することなく大多数のユーザーの問題を解決したため、急速に普及しました。

そうは言っても、あなたはreactを使用しています。これも一種の「新しい」テクノロジーです。 SASSが必要な場合は、vanilajsまたはbackbonejsも選択する必要があります）

@kof Reactは、数十万の晩で消えることはありません）、非常に異なるストーリーです。したがって、「新しい」かもしれませんが、非常に堅実です（

SASSは最も確立されたcssプリプロセッサの1つであり、あらゆるプロジェクトで使用できます。非常に堅牢で、テーブルに多くの価値をもたらします。 だから私は絶対に必要な場合にのみJSSのようなものを選びます（例えば：動的なテーマのため）が、いくつかの開発者がいる商用ソフトウェアプロジェクトで長年の経験/フレームワーク/知識ベースなどを捨てることは嫌いです。 したがって、JSSで動的テーマの側面のみを構築し、残りをsass / css-modulesで構築することも検討します。

私はこの考え方を理解していますが、それは逆効果であると考えており、イノベーションと業界の速度を低下させていると非難しています。

なぜあなたは両方をサポートしないのですか？ JavaScriptで書かれたスタイルとcss-modulesで書かれたスタイル？ たとえば、 https：//github.com/callemall/material-ui/blob/next/src/Button/Button.jsを見ると、小道具から渡されたクラス名を使用するのは非常に簡単です（ https://github.com/javivelasco/react-css-themr）を使用する代わりに：

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

そうですね。

JSSやCSSの使用に関する議論が終わりを迎えているようには見えません（まだ？）。 私には、現時点では50/50のように見えます。

SASSに関しては、react-toolboxは現在、完全なpostCSSソリューションを優先して移行しています。個人的には、postCSS（sassLikeプラグインを使用）の方が優れており、ビルド部門がなくてもより強力だと思います。

すべてのJS、特にReactのスタイリングは、明らかにまだ急速な進化の状態にあります。 ですから、あなたが何をするにしても、私は意見が分かれないようにします-現在の幅広い使用法にうまく適合します。

* styleプロップがあるところならどこでも* classNameプロップを追加することを検討してください。 限目。

完全な開示：私は幸せなAphroditeユーザーです。

classNameを追加するにstyleプロパティから）が優先されるため、 !importantハックが必要です。

@ligazもちろん、その通りです。 Aphroditeはデフォルトですべてに!importantを追加するので、おそらく「幅広い使用法」についての私の考えはひどく歪んでいます。

@ligaz @estaub - nextはすでにstyleなしでコーディングされており、コンポーネントのユーザーはclassName （および複雑なコンポーネントのさまざまな部分に複数のクラス名）を提供することでオーバーライドできます。

メンテナによるnextブランチのスタイリングパラダイム設定はJSSを使用しています。 個人またはテーマごとに使用することは喜びであり、簡単に上書きできます。

この馬は死んでいる。 それを打つのをやめましょう。 @oliviertassinari nextの指示文を使用して、この問題を閉じてロックすることをお勧めします。

こんにちは@ rosskevin-これが次にどのように機能するかについての例を教えていただけますか？

現在、新しいプロジェクトのフレームワークを検討しています。マテリアルUIを使用したいのですが、次に説明する変更が必要です。 テストプロジェクトに次のブランチを追加し、単純なコンポーネントを追加しましたが、インラインスタイルでいっぱいのインスペクターが表示されているので、何か間違ったことをしていると思いますか？

それ以上の詳細は本当に役に立ちます！

ありがとう

@giuseppepaul nextはプレアルファ版であり、まだ完成していないため、npmでは公開されていません。 https://github.com/callemall/material-ui.git#nextのクローンを作成し、 docs/siteを実行して、インラインスタイルがもうないことを確認できます。 また、適度な量のデモがあります。

私はnextのプライベートバージョンを公開しており（更新を制御できるように）、まもなく本番アプリケーションとして使用しています。

この馬は死んでいる。 それを打つのをやめましょう。 @oliviertassinari次の方向性の声明で、この問題を閉じてロックすることをお勧めします。

その馬は完全に死んでいない。 しかし、間違いなくタイトな場所にあります🔫。
同意します。この問題を閉じましょう。

その話に尽力してくれた@nathanmarksに大いに感謝し
＃5718で今後の道のりについてもっと情報を集めました。

こんにちは、
IconButtonは、波及効果のためのCSS3 transitionプロパティがあります。 Card @nextのドキュメントの複雑な相互作用で、アイコンが反転したときに遷移を追加するための変換にtransitionを追加しました。
アプリで同じことを行うと、一方の遷移（リップルまたは復帰）が他方をオーバーライドします（要素が2つのプロパティを持つことはできません。そうでない場合、一方が他方をオーバーライドします）。
ただし、シェブロンアイコンには2つのtransitionsが正常に適用されています。 どういうわけか、 IconButtonによって提供された遷移とコードで定義された遷移をマージするからです。 どうやってそれを達成しますか？
他のいくつかのものは私にはわかりにくく、関連するドキュメントが見つかりません。 themeは、 breakpoints （ここでは使用されていません） transitions （ここで使用されています）のように多くのメソッド/プロパティがあります。 MuiThemeProvider.createDefaultContext()が返すもののthemeプロパティについてのドキュメントはすでにありますか？特にコード内で広く使用されていると便利だと思われます。
this.context.styleManager.render(styleSheet) ？ 何 ？
また、 jss-theme-reactorを使用しますが、 react-jssと比較してまだポイントがわかりません。

@NitroBAYこのスレッドは終了しました。 正しいチャネルで質問してください。バグに気付いた場合、またはドキュメントを改善したい場合は、問題を開いてください。 それ以外の場合は、gitter.imのStackOverflowを使用できます。