Material-ui: すべてのデモでスタイル付きコンポーネントを使用する

@oliviertassinari what is the exactly the tasks in hand? @oliviertassinari手元にあるタスクは正確には何ですか？

Here is what I understand,これが私が理解していることです、

1. Run the docs websiteドキュメントのウェブサイトを実行する
2. Find all the example source code that uses material-ui/styles material-ui/stylesを使用するすべてのサンプルソースコードを検索します
3. Replace them with styled-componentsそれらをstyled-componentsに置き換えます

Is this correct?これは正しいです？

@yordis I think that the timing is going to be key in this transition. @yordisこの移行ではタイミングが重要になると思います。 I would imagine the following steps:私は次のステップを想像します：

1. We replace the usage of @material-ui/styles in the demos with the Box component, where possible.可能な場合は、デモでの@ Material-ui/stylesの使用法をBoxコンポーネントに置き換えます。 Moving #16858 at the same time would help.同時に＃16858を移動すると役立ちます。 This can be done in the near future.これは近い将来に行うことができます。
2. We solve #15561, we migrate more demos away from @material-ui/styles to use the system props. ＃15561を解決し、システムの小道具を使用するために、より多くのデモを@material-ui/stylesから移行します。 The sooner we solve this, the better.これを解決するのが早ければ早いほどよい。
3. We update the customization demos to use styled-components, leveraging the global Mui class names.グローバルMuiクラス名を利用して、スタイル付きコンポーネントを使用するようにカスタマイズデモを更新します。 We might need to work on some helpers to make accessing the theme values easier.テーマの値に簡単にアクセスできるようにするために、いくつかのヘルパーに取り組む必要があるかもしれません。
4. We solve #6115, we migrate the last usages of @material-ui/styles to styled-components. ＃6115を解決し、@ Material-ui/stylesの最後の使用法をstyled-componentsに移行します。 This is a task for v5, I think that we can start it Q1 2020 in the v5 alpha/beta versions.これはv5のタスクです。2020年第1四半期にv5アルファ/ベータバージョンで開始できると思います。

@oliviertassinari興味があります。これが繰り返された場合は、お詫び申し上げます@material-ui/stylesをラッパーまたはstyled-componentsの抽象化として保持してみませんか？

@ConAntonakos it's an option. @ConAntonakosそれはオプションです。 It could help if we need to extend/normalize some of the features of styled-components.スタイル付きコンポーネントの機能の一部を拡張/正規化する必要がある場合に役立ちます。

@oliviertassinari残っているもののリストはありますか？

@yordis We haven't done many efforts in this direction yet. @yordis私たちはまだこの方向に多くの努力をしていません。 However, there is a probability that it will require breaking changes, v5 is planned for around Q4 2020. I think that we should explore a partial deployment strategy for developers that want to leverage it sooner.ただし、重大な変更が必要になる可能性があります。v5は2020年第4四半期頃に計画されています。これをより早く活用したい開発者向けに、部分的な展開戦略を検討する必要があると思います。 Now, this effort has to be balanced with the other priorities, like the support of new advanced components (free and paid) or the release of an unstyled version of the library to increase our audience reach (with different themes, eg iOS style).現在、この取り組みは、新しい高度なコンポーネント（無料および有料）のサポートや、オーディエンスのリーチを拡大するためのスタイルなしバージョンのライブラリのリリース（iOSスタイルなどのさまざまなテーマ）など、他の優先事項とバランスを取る必要があります。 The good news is that we will likely grow the team in the coming months, enabling us to move faster.幸いなことに、今後数か月以内にチームを成長させ、より速く行動できるようになるでしょう。

I imagine you are already using styled-components on top of Material-UI today as many other developers do (and not @material-ui/styles ).他の多くの開発者が使用しているように（ @material-ui/stylesではなく）、今日、すでにMaterial-UIの上にスタイル付きコンポーネントを使用していると思います。 What are the top pain points you hope to address with this migration?この移行で対処したいと考えている最大の問題点は何ですか？

From a product perspective, our incentive is about: smaller bundle size, better performance, steaming support, fewer bugs, CSS template strings support, larger community, enables to use the system props in the core components, allow true dynamic themes and props support, better docs.製品の観点から、私たちのインセンティブは次のとおりです。バンドルサイズの縮小、パフォーマンスの向上、スチームサポート、バグの減少、CSSテンプレート文字列のサポート、コミュニティの拡大、コアコンポーネントでのシステム小道具の使用、真の動的テーマと小道具のサポート、より良いドキュメント。

However, there is a high probability that it will require breaking changes,ただし、重大な変更が必要になる可能性が高いですが、

Yeah, I tried to change some examples, but they require some integration with the theme provider, so we may need to inject material/style theme provider and styled-component theme provider I am assuming.ええ、私はいくつかの例を変更しようとしましたが、それらはテーマプロバイダーとの統合を必要とするため、私が想定しているmaterial/styleテーマプロバイダーとstyled-componentテーマプロバイダーを注入する必要があるかもしれません。

v5 is planned for around Q4 2020. v5は2020年第4四半期頃に計画されています。

That is far enough, would it be better to pin different issues for visibility on what is a priority at the moment?それで十分ですが、現時点で何が優先されているかを可視化するために、さまざまな問題を特定する方がよいでしょうか。

I imagine you are already using styled-components on top of Material-UI today as many other developers do (and not @material-ui/styles).他の多くの開発者と同じように、今日、Material-UIの上ですでにstyled-componentsを使用していると思います（@material-ui / stylesではありません）。

Actually, I am quite happy with @material-ui/styles and I am not using styled-components when I use Material UI (I would remove withStyles since I don't want to rely on programmer discipline 😉 , but I understand legacy software may no have hooks still )🤷‍♂️実際、私は@material-ui/stylesに非常に満足しており、Material UIを使用するときにstyled-componentsを使用していません（プログラマーの規律に依存したくないので、 withStylesを削除します） 😉、しかし私はレガシーソフトウェアがまだフックを持っていないかもしれないことを理解しています）🤷‍♂️

What are the top pain points you hope to address with this migration?この移行で対処したいと考えている最大の問題点は何ですか？

I am trying to help with the migration, personally, no pain points.私は個人的に、問題点なしで移行を支援しようとしています。 Unless you take into consideration that as an ecosystem, I have to maintain two ways to develop something, but meh, personally, it is okay for me.生態系としてそれを考慮しない限り、私は何かを開発するために2つの方法を維持する必要がありますが、個人的には、それは私にとっては問題ありません。

Maybe styled-components fixes some interoperability with NextJS and Gatsby since the last time I tried was hard to make Mui work with those tools because of the SSR and styles (I am not sure if still painful) and most libraries using styled-components work out of the box.たぶんstyled-componentsは、NextJSとGatsbyとの相互運用性を修正します。これは、前回試したときに、SSRとスタイル（まだ苦痛かどうかはわかりません）とほとんどのライブラリがstyled-componentsを使用しているため、Muiをこれらのツールで動作させるのが困難だったためです。

Let me know how I could help, like I said, I was using the pinned issues to find the prioritization of the Org私が言ったように、私がどのように助けることができるか教えてください私は組織の優先順位を見つけるためにピン留めされた問題を使用していました

That is far enough, would it be better to pin different issues for visibility on what is a priority at the moment?それで十分ですが、現時点で何が優先されているかを可視化するために、さまざまな問題を特定する方がよいでしょうか。

It depends on the time horizon you are interested in. You can follow the issue with the label important , the roadmap page on the documentation and the monthly blog product updates.関心のある期間によって異なります。 importantというラベル、ドキュメントのロードマップページ、および毎月のブログ製品の更新を使用して、問題を追跡できます。

I don't fully understand this point.私はこの点を完全には理解していません。 Why not using styled-components when using Material-UI (today)? Material-UI（今日）を使用するときにstyled-componentsを使用しないのはなぜですか？ We had 1/3 of our users going down this path when we did our last survey, 6 months ago. 6か月前の前回の調査では、ユーザーの3分の1がこの道を進んでいました。

I don't fully understand this point.私はこの点を完全には理解していません。 Why not using styled-components when using Material-UI (today)? Material-UI（今日）を使用するときにstyled-componentsを使用しないのはなぜですか？

@material-ui/styles works like a champ so far, no reason to migrate everything 😄 so I am one of those out of 3 that don't use it together today. @material-ui/stylesはこれまでのところチャンピオンのように機能し、すべてを移行する理由はありません😄私は3人のうちの1人で、今日は一緒に使用していません。

Thank you for the info about prioritization.優先順位付けに関する情報をありがとうございます。

@yordis btw, my answer was made under the assumption you were following up on the main styled-components issue. @yordisところで、私の答えは、あなたが主なスタイル付きコンポーネントの問題をフォローアップしているという仮定の下で行われました。 I haven't realized we were on the documentation one.私たちがドキュメンテーションの1つにいることに気づいていません。

@oliviertassinari do you have any suggestions about the issue with theme context? @oliviertassinariテーマコンテキストの問題について何か提案はありますか？

I tried to use props.theme inside an styled-components but didn't work, I am not sure if you have a suggestion for it, but I think we will require to add styled-components theme provider as well. $ styled-components props.themeを使用しようとしましたが、機能しませんでした。提案があるかどうかはわかりませんが、 styled-componentsを追加する必要があると思います。テーマプロバイダーも。

Hey @oliviertassinari!ねえ@oliviertassinari！ Are you looking for PR's that convert the existing customization demos to use styled-components as part of this issue?この問題の一部として、既存のカスタマイズデモをスタイル付きコンポーネントを使用するように変換するPRをお探しですか？

I dont think styled-components is a good styling solution. styled-componentsが良いスタイリングソリューションだとは思いません。 current solution looks much much more readable, appealing, accessible and cleaner than styled.現在のソリューションは、スタイル設定よりもはるかに読みやすく、魅力的で、アクセスしやすく、クリーンに見えます。 i dont see any good reason to migrate.移行する正当な理由がわかりません。

I dont think styled-components is a good styling solution. styled-componentsが良いスタイリングソリューションだとは思いません。 current solution looks much much more readable, appealing, accessible and cleaner than styled.現在のソリューションは、スタイル設定よりもはるかに読みやすく、魅力的で、アクセスしやすく、クリーンに見えます。 i dont see any good reason to migrate.移行する正当な理由がわかりません。

And get almost fully typed.そして、ほぼ完全に入力します。 Don't see any reason to migrate +1 +1を移行する理由はありません

The link you've posted, that should show growing interest to styled-components, recently started showing a downward trend:あなたが投稿したリンクは、スタイル付きコンポーネントへの関心が高まっていることを示しているはずですが、最近、下降傾向を示し始めています。

I feel that narrowing down a styling solution to a single library is going to give us the exact same problem as we have today.スタイリングソリューションを単一のライブラリに絞り込むと、現在とまったく同じ問題が発生すると思います。

What about integration with zero-runtime libraries such as linaria ? linariaなどのゼロランタイムライブラリとの統合はどうですか？ This was suggested as being looked at in May 2019 Update .これは、 2019年5月の更新で検討されていることが示唆されました。

So far it only recovered to pre-v5-hype.これまでのところ、v5以前の誇大宣伝にしか回復していません。 Let's see how the updated data point for January till now looks.これまでの1月の更新されたデータポイントがどのように見えるかを見てみましょう。

@TheHolyWaffle Don't trust rank2traffic.com too much, data hasn't been very reliable nor up-to-date, its main advantage was the overall trend over 10 years (before it was made paid). @TheHolyWafflerank2traffic.comをあまり信用しないでください。データの信頼性も最新性も高くありません。その主な利点は、10年間（支払いが行われる前）の全体的な傾向でした。 For a shorter time window, so 6 months, prefer https://www.similarweb.com/ as more reliable. 6か月という短い期間の場合は、信頼性が高いとしてhttps://www.similarweb.com/をお勧めします。
Also take into account that once people know the API, they come back much frequently to the documentation.また、APIを知ったら、ドキュメントに頻繁に戻ってくることも考慮に入れてください。

I dont think styled-components is a good styling solution. styled-componentsが良いスタイリングソリューションだとは思いません。 current solution looks much much more readable, appealing, accessible and cleaner than styled.現在のソリューションは、スタイル設定よりもはるかに読みやすく、魅力的で、アクセスしやすく、クリーンに見えます。 i dont see any good reason to migrate.移行する正当な理由がわかりません。

And get almost fully typed.そして、ほぼ完全に入力します。 Don't see any reason to migrate +1 +1を移行する理由はありません

+1 styles is the main reason we're migrating to Material UI and moving away from styled components. +1 stylesが、マテリアルUIに移行し、スタイル付きコンポーネントから移行する主な理由です。 It's too much CSS and refactoring it has proven to be a huge burden for us. CSSが多すぎて、リファクタリングは私たちにとって大きな負担であることが証明されています。

Hi!やあ！ First of all, thank you for providing a great component library, best one I've used so far.まず、これまで使用した中で最高のコンポーネントライブラリを提供していただきありがとうございます。 Our teams have written hundreds of thousands of lines of code using the components and methodology you created and once developers learn the basics of using classes , how to write the styles etc., it's a breeze to work with even on a massive enterprise scale type of codebase.私たちのチームは、作成したコンポーネントと方法論を使用して数十万行のコードを記述しました。開発者がclassesの使用の基本、スタイルの記述方法などを学んだら、大規模なエンタープライズ規模のコードベース。

I'm not sure if that's the most common use of your library, but I suppose you are aware that many teams build their component libraries on top of Material UI, and so any components and decision you make also trickle down to those libraries.それがライブラリの最も一般的な使用法であるかどうかはわかりませんが、多くのチームがマテリアルUIの上にコンポーネントライブラリを構築していることをご存知だと思います。そのため、コンポーネントや決定はすべてそれらのライブラリに反映されます。 On our end we've been very happy with both performance and APIs so far.私たちの側では、これまでのところパフォーマンスとAPIの両方に非常に満足しています。

I've been following recent development in the library and to be honest, I'm having trouble understanding some of the decisions and worried how that will affect our teams, and what's overall the benefit of this move would be, as opposed to for example forking MUI.私は図書館での最近の開発をフォローしてきましたが、正直なところ、いくつかの決定を理解するのに苦労しており、それがチームにどのように影響するか、そしてこの動きの全体的なメリットは、たとえば、 MUIをフォークします。 Others have voiced their concern about move to styled components so I'll focus on the other one for me - the Box component.他の人は、スタイル付きコンポーネントへの移行について懸念を表明しているので、もう1つであるBoxコンポーネントに焦点を当てます。

I understand the utility of a Box component - to make it possible to use theme variables etc. in prop values, however the API and the consequences of using this component disqualify it from something I could recommend to our teams. Boxコンポーネントの有用性を理解しています-prop値でテーマ変数などを使用できるようにするためですが、APIとこのコンポーネントを使用した結果は、私がチームに推奨できるものからそれを失格にします。

First , it has a cryptic API for no reason I can discern (unless saving a few bytes is that reason): Instead of writing <Box margin={3} /> , it would be <Box m={3} /> .まず、それは私が識別できる理由がないために不可解なAPIを持っています（数バイトを節約することがその理由でない限り）： <Box margin={3} />を書く代わりに、それは<Box m={3} />になります。

Abbreviations like that seem needless, make things potentially ambigious, and introdue a new learning curve to developers, a mapping of abbreviations to actual properties they now need to memorize: "Is applying color done using c or color ?", "Is background a b , or bg , or background , or was b a border ?"そのような略語は不必要に思え、物事を潜在的に曖昧にし、開発者に新しい学習曲線を導入しcolor 。これは、開発者が今覚えておく必要のある実際のプロパティへの略語のマッピングですcまたはcolor ？ "、" backgroundはb 、またはbg 、またはbackground 、またはb border ？」 "Is background-size abbreviated as bs ?" 「 background-sizeはbs $と省略されますか？」

Second , components abstract most commonly recurring UI patterns, and create APIs that provide means of customizing those patterns to the extent that the design system permits.次に、コンポーネントは最も一般的に繰り返されるUIパターンを抽象化し、設計システムが許可する範囲でそれらのパターンをカスタマイズする手段を提供するAPIを作成します。 This manifests in creating props like gutterBottom on Typography , or dense on ListItem - as opposed to accepting just about any padding or margin.これは、ほぼすべてのパディングやマージンを受け入れるのではなく、 TypographyのgutterBottomや$ ListItemのdenseのような小道具を作成することで明らかになります。 I feel like introducing Box to large extent undermines this effort and introduces a tool that will make a mess out of any attempt to follow a design system unless we define some very nitpicky ways that Box component can be used for and spend effort in code reviews to make sure the all the values in used Box props aren't beyond the accepted list. Boxを導入すると、この取り組みが大幅に損なわれ、Boxコンポーネントを使用して使用できる非常に厄介な方法を定義しない限り、設計システムに従う試みを台無しにするツールが導入されるように感じます。使用されているBox小道具のすべての値が受け入れられたリストを超えていないことを確認するためのコードレビューの努力。 And at that point, the way to "automate" this would be to create a component that restricts the options, and we're backt to square one.そして、その時点で、これを「自動化」する方法は、オプションを制限するコンポーネントを作成することであり、私たちは正方形に戻ります。 To give an example, why would using Box mb={2} to achieve margin under Typography be okay, but Box mb={6} not?例を挙げると、タイポグラフィでマージンを達成するためにBox mb={2}を使用するのはなぜ問題ないのに、 Box mb={6}は問題ないのでしょうか。 This concern doesn't exist when we can rely on props to limit the options.オプションを制限するために小道具に頼ることができる場合、この懸念は存在しません。

Third concern, or rather a question I have. 3番目の懸念、またはむしろ私が持っている質問。 Since the Box component is potentially a quick way to build certain functionality, it would be also used by libraries built on top of MUI. Boxコンポーネントは、特定の機能をすばやく構築する方法である可能性があるため、MUI上に構築されたライブラリでも使用されます。 How would one override the styles of Box components used within another component?別のコンポーネント内で使用されるBoxコンポーネントのスタイルをどのようにオーバーライドしますか？ As an example.例として。 If we built ListItem using Box under the hood, would we need to introduce BoxProps={{ padding: 2 }} , or accept also dense prop based on which we write logic to apply a padding prop to a particular Box, or still something else?内部でBoxを使用してListItemを構築した場合、 BoxProps={{ padding: 2 }}を導入する必要がありますか、それともdenseプロップを受け入れる必要があります。これに基づいて、 paddingプロップをに適用するロジックを記述します。特定のボックス、またはそれでも何か他のもの？

I'm not sure if that's the most common use of your library, but I suppose you are aware that many teams build their component libraries on top of Material UI , and so any components and decision you make also trickle down to those libraries.それがライブラリの最も一般的な使用法であるかどうかはわかりませんが、多くのチームがマテリアルUIの上にコンポーネントライブラリを構築していることをご存知だと思います。そのため、コンポーネントや決定はすべてそれらのライブラリに反映されます。 On our end we've been very happy with both performance and APIs so far.私たちの側では、これまでのところパフォーマンスとAPIの両方に非常に満足しています。

@maciej-gurban This use case is an important one for us. @maciej-gurbanこのユースケースは私たちにとって重要なものです。 Our incentives are aligned to significantly improve it.私たちのインセンティブは、それを大幅に改善するために調整されています。 This is one of our objectives with v5.これは、v5の目標の1つです。

For instance, we are investigating the feasibility to provide a design tool that could be put in the hands of designers (paid) and would output ready to use customized Material-UI components (MIT), corresponding documentation, Sketch & Figma kit.たとえば、設計者の手に渡り（有料）、カスタマイズされたMaterial-UIコンポーネント（MIT）、対応するドキュメント、Sketch＆Figmaキットをすぐに使用できる設計ツールを提供する可能性を調査しています。 Basically, all we have been going it for Material Design but scaling it 🚀.基本的に、私たちはマテリアルデザインのためにそれを行ってきましたが、それをスケーリングします🚀。
The end goal here would be to free the time of a couple of front-end developers in each company.ここでの最終的な目標は、各企業の2人のフロントエンド開発者の時間を解放することです。 Why have front-end developers build a custom design system when it can be done by your own designers + Material-UI at a fraction of the cost?独自の設計者とMaterial-UIがわずかなコストで実行できるのに、なぜフロントエンド開発者がカスタム設計システムを構築するのでしょうか。 + reduce risk and have your front-end developers spend time where they make the most differences: working on the product. +リスクを軽減し、フロントエンドの開発者に、製品に取り組むという最大の違いをもたらす時間を費やしてもらいます。

I'm having trouble understanding some of the decisions and worried how that will affect our teamsいくつかの決定を理解するのに苦労していて、それが私たちのチームにどのように影響するか心配しています

If you could list them, it would be awesome.あなたがそれらをリストすることができれば、それは素晴らしいでしょう。

Others have voiced their concern about move to styled components他の人は、スタイル付きコンポーネントへの移行について懸念を表明しています

What's your concern with such a shift?そのような変化についてあなたは何を懸念していますか？ Our objective on the styling side has a couple of layer:スタイリング側の目的には、いくつかのレイヤーがあります。

1. Unstyled component, expose the same existing components but without any styles.スタイルが設定されていないコンポーネント。同じ既存のコンポーネントを公開しますが、スタイルはありません。 Keep the same classes API (first seen in jQuery-UI), provide default hardcoded values for each of the classes (global class names).同じclasses API（jQuery-UIで最初に見られる）を維持し、各クラス（グローバルクラス名）にデフォルトのハードコードされた値を提供します。 The objective behind this shift answer to a couple of incentives.このシフトの背後にある目的は、いくつかのインセンティブに答えます。 First, it's to dismiss a fear our users have, same to CRA eject mode, you won't use it but it feels safe to be present.まず、CRAイジェクトモードと同様に、ユーザーが抱く恐れを払拭することです。CRAイジェクトモードは使用しませんが、存在しても安全だと感じます。 Second, it's required to be able to build the paid design tool.第二に、有料のデザインツールを構築できる必要があります。 Third, it's required for the next layer第三に、それは次の層に必要です
2. Multiple style engines.複数のスタイルのエンジン。 The community is fragmented between different styling approaches.コミュニティは、さまざまなスタイリングアプローチ間で断片化されています。 By order of popularity: styled-components, plain CSS, CSS modules, emotion, JSS, utility first classes.人気順：スタイル付きコンポーネント、プレーンCSS、CSSモジュール、感情、JSS、ユーティリティファーストクラス。 It still feels like we didn't find the holy grail for styling.それでも、スタイリングの聖杯が見つからなかったような気がします。 And until we do, better not bet too much on any styling solution.そして、そうするまでは、スタイリングソリューションにあまり賭けないほうがいいでしょう。 So, have styled-components has the default, but allow developers to switch engine, stay on JSS if they are happy too.したがって、styled-componentsにはデフォルトがありますが、開発者がエンジンを切り替えて、満足している場合はJSSにとどまることができます。
3. Baseline theme.ベースラインテーマ。 Something less opinionated than the current default Material Desing Theme, but using the same theme's specification.現在のデフォルトのマテリアルデザインテーマよりも意見が少ないですが、同じテーマの仕様を使用しています。
4. A couple of different themes on top of the baseline.ベースラインの上にいくつかの異なるテーマ。 One for marketing pages, One for the Chinese market (close to the Gmail equivalent of China). 1つはマーケティングページ用、もう1つは中国市場用（Gmailで中国に相当）。

I'll focus on the other one for me - the Box component.もう1つであるBoxコンポーネントに焦点を当てます。

Yeah, I can hear you!ええ、聞こえます！ I have been working with @gregberge in the past.私は過去に@gregbergeと協力してきました。 At some point, we have considered hiding all the className props on @doctolib 's design system.ある時点で、 @doctolibの設計システムですべてのclassNameプロップを非表示にすることを検討しました。 The interesting thought is that you can gain features (properties) in exchange of more constraints.興味深い考えは、より多くの制約と引き換えに機能（プロパティ）を取得できることです。

I wouldn't worry too much about this one.これについてはあまり気にしません。 This can be resolved with a global option to limit the access to the "system"'s features or an eslint rule.これは、「システム」の機能またはeslintルールへのアクセスを制限するグローバルオプションで解決できます。

The abbreviation on the Box component is confusing. Boxコンポーネントの略語は紛らわしいです。 Code is being read more than being written, so it's important to keep clear what the code is meaning.コードは書かれているよりも読まれているので、コードが何を意味しているのかを明確にすることが重要です。 Last day I found "Box py={2}" in our codebase and I'm totally confused.昨日、コードベースで「Box py = {2}」を見つけましたが、完全に混乱しています。 After a search I figured out that means "paddingY".検索したところ、それは「paddingY」を意味することがわかりました。 Those abbreviation should not be encouraged especially non-css properties (I can guess pt means padding-top but not for py)これらの省略形は、特にcss以外のプロパティを推奨するべきではありません（ptはpadding-topを意味しますが、pyは意味しないと思います）

@oliviertassinari Thanks for your patience @oliviertassinariご理解いただきありがとうございます

I'm having trouble understanding some of the decisions and worried how that will affect our teamsいくつかの決定を理解するのに苦労していて、それが私たちのチームにどのように影響するか心配しています

If you could list them, it would be awesome.あなたがそれらをリストすることができれば、それは素晴らしいでしょう。

I wouldn't want this to turn into a litany of things I disagree with, because ultimately you're the guys who maintain this library and our view of what makes sense will be shaped by our own needs which might and likely don't always align, and that's fine.最終的にはあなたがこのライブラリを管理している人であり、意味のあるものに対する私たちの見方は、常にではないかもしれない私たち自身のニーズによって形作られるので、私はこれが私が同意しないものの連祷に変わることを望んでいません整列し、それは問題ありません。 I'm not against introducing the means of using other styling solutions - in fact I think it's great as it will bring more users who were holding off because of their dislike for JSS, but there's also us - the already existing users of your library who are sold on your solution, and if possible, would like to avoid massive refactor.私は他のスタイリングソリューションを使用する手段を導入することに反対していません-実際、JSSが嫌いなために延期していたユーザーが増えるので素晴らしいと思いますが、私たちもいます-あなたのライブラリの既存のユーザーはソリューションで販売されており、可能であれば、大規模なリファクタリングを避けたいと考えています。

Even if you decide that "we still provide support for JSS", refactoring all demos and your components to styled components will force the teams using JSS to migrate to styled components. 「引き続きJSSのサポートを提供する」と決定した場合でも、すべてのデモとコンポーネントをスタイル付きコンポーネントにリファクタリングすると、JSSを使用するチームはスタイル付きコンポーネントに移行する必要があります。 "Why are we still using X, when MUI team moved to Y?" 「MUIチームがYに移動したのに、なぜまだXを使用しているのですか？」 - will be one of the many questions in light of which it would be really hard not to agree with needing to make that migration sooner or later. -遅かれ早かれその移行を行う必要があることに同意しないのは非常に難しいことを考えると、多くの質問の1つになります。

I can definitely empathize with wanting to reach a wider audience by using a styling solution that's more popular.より人気のあるスタイリングソリューションを使用することで、より多くの聴衆にリーチしたいということに共感することができます。 However, I think it's worth considering that "popular" is not always "best" and that a move to a different tech needs onsideration not only of advantages and disadvantages of both solution, but the context in which we're making the decision.ただし、「人気」が常に「最良」であるとは限らず、別の技術への移行には、両方のソリューションの長所と短所だけでなく、決定を下す状況についても考慮する必要があることを考慮する価値があると思います。

Starting fresh, looking merely at advantages of X over Y makes sense, but working on an already existing system we also need to consider the cost of switching over and domino effects this bring on downstream teams.新たに始めて、Yに対するXの利点だけを見るのは理にかなっていますが、既存のシステムで作業する場合は、切り替えのコストと、これがダウンストリームチームにもたらすドミノ効果も考慮する必要があります。 For this switch over to make sense the advantanges of the other solution need to outweight the cost of migrating over.この切り替えを意味のあるものにするために、他のソリューションの利点は、移行のコストを上回る必要があります。 It seems that for your team, that cost benefit analysis rules in favor of styled components, but from what I can tell looking at reactions at posts talking about styled components in your repo, your user base is far from the same conclusion.あなたのチームにとって、その費用便益分析はスタイル付きコンポーネントを支持しているようですが、リポジトリ内のスタイル付きコンポーネントについて話している投稿での反応を見ると、ユーザーベースは同じ結論にはほど遠いです。

Like you said, your aim is to open up MUI to more styling solutions.あなたが言ったように、あなたの目的は、MUIをより多くのスタイリングソリューションに開放することです。 To provide good support for those solutions, there would need to be good documentation, examples and smooth integration layer - otherwise developers would find it hard to translate what they see in demos into what their styling solution of choice needs.これらのソリューションを適切にサポートするには、優れたドキュメント、例、スムーズな統合レイヤーが必要です。そうしないと、開発者はデモで見たものを、選択したスタイリングソリューションに必要なものに変換するのが難しいでしょう。 I'm just not sure if you really need to migrate to styled components to achieve the goals.目標を達成するために、スタイル付きコンポーネントに本当に移行する必要があるかどうかはわかりません。 Seems like your solution is also perfectly capable, if not more so than others, to build the design tool you're after since you already use actual JS object for all the styles.すべてのスタイルに実際のJSオブジェクトをすでに使用しているため、ソリューションは、他のソリューションよりも優れているとは言えないまでも、目的のデザインツールを完全に構築できるようです。

One question I have, does this mean that the core of Mui would still use jss, and this allows for a better way to use styled components on top of that?私が持っている1つの質問は、これはMuiのコアが引き続きjssを使用することを意味し、これにより、その上にスタイル付きコンポーネントを使用するためのより良い方法が可能になりますか？ Or would there be a way to say the core is also styled?それとも、コアもスタイリングされていると言う方法はありますか？ I just think it would add a lot of bloat if you have two css in js solutions. jsソリューションに2つのcssがある場合、それは多くの肥大化を追加すると思います。

How would theming work if using styled-components?スタイル付きコンポーネントを使用する場合、テーマはどのように機能しますか？ I used to use helpers in the CSS portion, and it was really messy.以前はCSS部分でヘルパーを使用していましたが、非常に面倒でした。 For me, the approach of applying theme props in a JS object is a lot cleaner than in a templated string.私にとって、JSオブジェクトにテーマの小道具を適用するアプローチは、テンプレート化された文字列よりもはるかにクリーンです。

For me (scientific backend programmer by origin), MUI styles bring beautiful, calming, predictable, parameterisable logic to the mental, crazy, bonkers-rules why-the-hell tearing-hair-out world of CSS.私（起源による科学的なバックエンドプログラマー）にとって、MUIスタイルは、美しく、落ち着きがあり、予測可能で、パラメーター化可能なロジックを、CSSの精神的でクレイジーなボンカールールのルールにもたらします。

The styles library (and its tight integration with the theme) is the main reason I mandate use of MUI over any other components library in the two organisations I oversee tech for - it takes all the css agony away!スタイルライブラリ（およびテーマとの緊密な統合）が、私が技術を監督している2つの組織の他のコンポーネントライブラリよりもMUIの使用を義務付けている主な理由です-それはすべてのcssの苦痛を取り除きます！ At first, all the developers I work with are like "what the hell's going on? Where's the css? Just give me css!!"最初、私が一緒に仕事をしているすべての開発者は、 「一体何が起こっているのか？cssはどこにあるのか？cssをくれ！」のようなものです。 and then they're like "Ohhhh. riiight. Got it. Magic."そして、彼らは「ああ、そうだね。わかった。魔法」のようだ。

In the longer term I think the current approach is going to become ever more powerful as the world moves to low/no code solutions (eg like sketch or figma, but outputting an actual routed app and set of components rather than a set of wireframes) - having styles expressed as an object unlocks the ability to introspect that - and create more new features in such an environment (like provision of a schema enabling direct use of MUI components within a CMS, or generation of 'theme from this' and hundreds I haven't thought of yet).長期的には、世界が低/コードなしのソリューションに移行するにつれて、現在のアプローチはさらに強力になると思います（たとえば、スケッチやfigmaのように、ワイヤーフレームのセットではなく、実際にルーティングされたアプリとコンポーネントのセットを出力します） -スタイルをオブジェクトとして表現することで、それを内省する機能が解き放たれます-そして、そのような環境でより多くの新しい機能を作成します（CMS内でMUIコンポーネントを直接使用できるようにするスキーマの提供、または「これからのテーマ」と数百のIの生成など）まだ考えていません）。

Moving back to the more raw-css kind of approach of styled-components doesn't preclude that - but it does make a lot of things (particularly parameterisation on the theme) a lot jankier and frustrating to achieve, and still requires much more in-depth knowledge of CSS's technicalities making it less accessible to new programmers and creative types alike. styled-componentsのより生のcssの種類のアプローチに戻ることは、それを排除するものではありません-しかし、それは多くのこと（特にテーマのパラメーター化）を達成するのに非常に厄介でイライラさせます、そしてそれでも必要ですCSSの技術に関するより深い知識により、新しいプログラマーやクリエイティブタイプがCSSにアクセスしにくくなっています。

On the evolution of the state-of-the-art, I think styled-components has become really popular because it's a great step in the right direction from where the world was (which is why it became popular).最先端の進化の中で、 styled-componentsは世界があった場所から正しい方向への大きな一歩であるため、本当に人気が出てきたと思います（それが人気になった理由です）。 But the existing MUI styles system is the next step on from that;しかし、既存のMUIスタイルシステムはそれからの次のステップです。 not an incorrect side-step.間違ったサイドステップではありません。 Once everyone's migrated to styled-components then the question will be "wait: why on earth are we doing this with these weird raw strings in our components...?"全員がstyled-componentsに移行すると、質問は「待ってください。なぜ、コンポーネント内のこれらの奇妙な生の文字列を使用してこれを行うのですか...？」

Maybe I'm totally wrong, but for my $0.02, I'm begging you to stay the course for at least another major version :)たぶん私は完全に間違っていますが、私の0.02ドルで、少なくとも別のメジャーバージョンのためにコースを続けるようにお願いしています:)

@thclark your main concern seems to be with the CSS template string syntax vs the JavaScript style object API. @thclarkあなたの主な関心事は、CSSテンプレート文字列構文とJavaScriptスタイルオブジェクトAPIにあるようです。 Is this accurate?これは正確ですか？ It also seems to be the concern with most of the other comments of the thread.それはまた、スレッドの他のコメントのほとんどに関する懸念のようです。

Styled-components and emotions support both APIs.スタイル付きコンポーネントと感情は両方のAPIをサポートします。 This wasn't the main purpose of the issue.これは問題の主な目的ではありませんでした。 The objective of this issue was to anticipate the migration to a different styling solution.この問題の目的は、別のスタイリングソリューションへの移行を予測することでした。 However, we never move forward with "use styled-components in all the demos even if we didn't migrate the core engine".ただし、「コアエンジンを移行しなくても、すべてのデモでスタイル付きコンポーネントを使用する」ことは決してありません。 We have opted for keeping both synchronized.両方の同期を維持することを選択しました。
At this point, keeping the issue open doesn't add much value outside triggering discussions like this one :).この時点で、問題を開いたままにしておくことは、このような議論を引き起こすこと以外に多くの価値を追加しません:)。 We have to migrate the demos anyway for #22342.とにかく＃22342のデモを移行する必要があります。

I personally prefer the JavaScript API over the CSS string one because:私は個人的にCSS文字列よりもJavaScriptAPIを好みます。理由は次のとおりです。

• It doesn't ask for another linter/formater.別のリンター/フォーマッターを要求しません。
• I'm used to it.慣れてます。
• It plays nicely with TypeScript. TypeScriptとうまく連携します。

However, it's unclear what the community, at large, will enjoy using most.ただし、コミュニティ全体で何を最もよく使用するかは不明です。 CSS template has its advantages too. CSSテンプレートにも利点があります。 It's easier to copy & paste code between the browser and the code.ブラウザとコードの間でコードをコピーして貼り付ける方が簡単です。 A lot more people (overall: designers, developers, etc.) are familiar with the approach.より多くの人々（全体として：設計者、開発者など）がこのアプローチに精通しています。

To be noted that I think that we should use the style utilities as much as possible in the demos with v5.なお、v5のデモでは、可能な限りスタイルユーティリティを使用する必要があると思います。

@mnajdova any thoughts on the matter? @mnajdovaこの問題について何か考えはありますか？ Maybe it's worth asking the community on a poll.多分それは世論調査でコミュニティに尋ねる価値があります。

@oliviertassinari succinctly put, as usual. @oliviertassinariはいつものように簡潔に言います。 Yes, my main concern is retaining the Javascript API.はい、私の主な関心事はJavascriptAPIを保持することです。 Honestly, I wasn't aware that styled-components retained that, as all of the examples I came across seem to be css templated.正直なところ、私が遭遇したすべての例はcssテンプレート化されているように見えるため、styled-componentsがそれを保持していることに気づいていませんでした。

That perhaps moots most of my points above.それはおそらく上記の私のポイントのほとんどを論破します。 Nevertheless, glad you didn't move across - and thanks for your and the team's continued efforts here.それにもかかわらず、あなたが移動しなかったことをうれしく思います-そしてあなたとチームのここでの継続的な努力に感謝します。 I've built things I never could have without MUI existing.私は、MUIが存在しなければ実現できなかったものを構築しました。

This issue is being resolved in v5.この問題はv5で解決されています。 We have migrated the documentation of the slider to the new approach: https://next.material-ui.com/components/slider-styled/.スライダーのドキュメントを新しいアプローチに移行しました：https：//next.material-ui.com/components/slider-styled/。 We use the sx prop anytime simple CSS are necessary then use the styled API for more heavy customizations.単純なCSSが必要な場合はいつでもsxプロパティを使用し、さらに重いカスタマイズにはstyled APIを使用します。 I believe the previous concern raised have been handled, if not, please comment :).以前に提起された懸念は処理されたと思います。そうでない場合は、コメントしてください:)。