进一步的问题：
6）我们会删除还是旨在删除xxxxStyle道具，并让用户以xxxClassName作为替代样式？ 还是这些是免费的？
7）我们是否将允许通过CSS覆盖样式并简化组件接口。 因此，如果我想在IconMenu中覆盖menuItemStyle ，是否要创建style = StyleSheet.create({ IconMenu: {MenuItem: { color:red }})类型覆盖？

@chrismcv我个人的意见是，我们绝对需要利用该解决方案来删除我们正在提出的这些超级特定道具：[TextField]添加floatLabelFocusStyle道具＃4043

在我们不知道这一点之前，人们将要求为每种可能的焦点/活动/悬停/任何状态的子组件样式提供道具。

我看到很多问题，例如“如何设置XXXX的样式”，“不能在YYYY内设置XXX的样式”，“请向XXX添加somethingInsideToTheLeftButSlightlyMiddleFocusHoverActiveStyle属性”

@chrismcv in 6.关于更通用的xxxxStyle道具vs classNames，您怎么看？ 使用我们的某些组件，您将需要能够以一种或另一种方式到达（虽然我们可以使用:hover等！）。

@chrismcv我认为xxxxStyle道具应该放在style属性中，而不是className化风格的对象中。

@nathanmarks感谢您引导对话。 这绝对是我们下一版本💯需要解决的主要问题之一。

绩效问题之外

对于我来说，这是我将选择的解决方案的主要问题之一。
我们没有很多基准测试，因为我们可以轻松地想象一下，使用当前方法丢失了许多CPU周期。 CPU周期丢失到内联样式对象的内存分配和垃圾回收中。

@oliviertassinari

目前，我正在使用几个JS样式解决方案。 有趣但很明显，可以这么说。

我正在考虑的一件事-在动态样式属性之外（例如，如果组件具有color prop），我们是否应该更改创建基本样式对象的方式？

似乎对于JS样式库而言，要获得最佳性能，您应该使用它们的StyleSheet.create()方法一次，并在该对象中为诸如open={true}类的道具/状态使用键（css“类”）而不是使用几个条件属性来动态构建样式对象文字，并将其传递给样式表工厂方法，以便呈现每种样式。

即使在仅将样式表选择器缓存到DOM（并且在某些libs中仅在render()需要时才写入DOM）的意义上缓存它们之后，我们仍然在浪费资源进行某些计算+对象创建+垃圾回收，如上所述，如果我们要创建一个新样式的对象，则每个渲染只是为了将其丢弃。

嗯...我昨天（星期日）在这里发表评论。 它被删除了吗？

@rvbyron我记得很清楚。 我当然没有删除它。

@rvbyron我也记得它。 我不知道发生了什么事。

@rvbyron-它已包含在我的电子邮件中，因此以引号形式回到此处！

好吧，我想看到很多事情发生。

A）是的，一定要在库级别上放弃使用元素的style参数。 所有组件都应使用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谢谢老兄！

我认为@rvbyron所说的很重要，因为在某些方面，JS样式在很大程度上是常规CSS的范式转变。 大多数人在日常工作中都没有使用JS样式，这需要不同的思维方式+使得通常可能对不那么精通JS的项目有所贡献的设计人员更加困难。

重要的是要在这里考虑所有角度。

@oliviertassinari @chrismcv

我意识到react-look一件事是，您需要将所有组件包装在look HoC中。 这似乎很具有侵入性，它甚至劫持了render()函数，将super.render()在const并以此方式执行样式解析操作。 其他一些解决方案（例如Khan / Aphrodite）仅需要在className={}内的Stylesheet.create()内的styles.xxxx引用周围进行函数包装。

对css劫持render()函数似乎对我来说是过度设计的。 它告诉我，还没有提供用于这种深度集成的样式功能的React内置工具/支持，我不确定CSS助手HoC控制所有组件的渲染的想法。

有什么想法吗？

您好Material-UI小组！

一直关注您一段时间，现在看到这个主题，我还想提出一些想法，为什么从内联样式转换为CSS可能是个好主意。 我在此版本库中阅读了很多讨论，涉及渲染性能，样式化子元素/嵌套元素，媒体查询，伪元素等，因此，我将集中讨论我尚未遇到的其他话题，但我认为这也很重要。 它是样式组织。 这是我的意思：

• 某些样式来自组件默认值（在节点文件夹中设置且不可触摸）
• 有些来自组件参数（例如Avatar组件参数size={40}将width，height和line-height设置为40px ）
• 当自定义组件默认值（主题颜色）时，样式来自主题自定义位置
• 修改其余的组件样式后，这些样式来自组件实现，这是代码的另一部分

调整样式时，至少要查看4个不同的位置（👆），这使得很难调查问题。

当CSS附带样式时，您会看到选择器并确切知道要在哪里修复。 使用内联样式需要花费一些时间来了解特定属性的来源以及应在何处修改的内容。 并且如果开发人员在错误的位置进行了修改（例如，在styles区域而不是size参数，因为实际上没有任何内容表明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对象material-ui，并使以组件为中心的样式开发人员感到高兴。 或者，ClassTheme将使用从muiTheme.js对象（已同步）构建的SCSS文件，从而使以CSS为中心的开发人员感到高兴。 这意味着所有组件随后都需要在render元素中容纳{... 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'
}

可以将两者的组合作为ClassStyleTheme行为进行检索，theme.RoundButton将包含两者：

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

mui-theme.scss文件将从muiTheme.js文件生成，并在SCSS中反映JS文件包含的确切属性。 JS名称的驼色大写字母将转换为更多标准的类名称：

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

加载mui-theme.scss文件后，对MUI组件进行的任何CSS定制都将只是加载相同的类，从而覆盖mui-theme属性。

@oliviertassinari

我认为使用scss （+用于命名/散列的css模块）有很多好处。 这是您100％反对的事情吗？ 我可能会略有偏见，因为这是我习惯在工作中使用的方式，但是很多人都在同一条船上。

我对JS样式情况的主要问题是，感觉所有解决方案仍在开发中。 没有很多现实世界的性能评估可以查看，我们正在查看的库尚未得到证实，我觉得我们似乎在花费大量时间试图弄清楚如何正确地使用JS中的样式。 这个lib的主要目标是实施材料设计规范，我不禁感到目前这对我们构成了束缚。 （我们需要对性能影响问题进行排序）

我认为我们对此有不同的担忧。

1. 放置静态样式的位置（简单，css文件即可）
2. 如何根据输入切换某些样式（className切换）
3. 如何应用动态样式（内联样式可以做到这一点）

当您编写应用程序时，一切似乎都很好，代码外的任何人都无需更改任何内容。

但是对于库而言，情况有所不同，上述所有问题都存在，还有以下内容：

1. 如何使用户自定义静态样式？
2. 如何以易于切换，自定义和隔离的方式实现主题（不同的子树不同的主题）？
3. 如何避免污染全局名称空间，以便我们能够与他人良好地合作？
4. 用户如何覆盖内联的动态样式？
5. 变形金刚！ （RTL，前缀，等）

我们现在所拥有的以某种方式可以解决这些警告：

1. 性能！
2. 深嵌套的组件很难自定义，如@nathanmarks所说： somethingInsideToTheLeftButSlightlyMiddleFocusHoverActiveStyle
3. 我们无法利用某些CSS功能的强大功能。

如果我们更改样式方法，则必须重新做一遍。 如果涉及到这一点，我们应该确保在开始迁移之前回答所有这些问题。

以我的拙见，我认为CSS及其所编译的内容都不是未来的一部分。 我认为我们都同意，内联样式使我们的生活更加轻松。 老实说，我看到的内联样式的唯一限制是:hover ！

我们可以通过做一些设计来解决这些问题。

1. 记住样式对象，对于具有状态的组件，我们可以分解状态并将其放在较小的组件中，以便可以根据作为较高组件状态的传递道具来记住其中的样式对象。 这很容易解决！
2. 把它们分解！ 为什么我们有一个嵌入了许多小功能的ListItem ？ 我们可以将其分解并使其可组合，那么我们就不必添加somethingInsideToTheLeftButSlightlyMiddleFocusHoverActiveStyle类的怪兽
3. h！ 我们获得的性能只有:hover我认为我们可以忍受直到浏览器或做出反应为止。

我的观点是，我们已经使用当前的样式设计方法解决了许多问题。 它有局限性，因为我们没有遵循内联样式的所有模式。 如果我们开始分解我们的组件并使它们更具可组合性，那么我们就不必担心任何事情。 拿MeuItem拿出来让它变得可组合，您会看到它使用起来很容易，如何使用纯渲染提高性能！

因此，与其改变我们的方法并再次解决所有这些问题，不如让我们花费时间来改善我们已经拥有的东西。 我们不需要支持媒体查询，我们可以以易于他人实现响应的方式更改组件。 难以调试？ 如果我们分解组件，则内联样式将更小且更易于阅读。 值得商though！ 我的意思是，您所需要的只是一个转折点，以查看Object.assign涉及的内容，以查看样式的来源。

当然，这是我个人的看法，我非常愿意讨论。

@alitaheri

您提出了一些要点。 谢谢。 我想知道某种混合解决方案是否可能。 看来，无论我们采取什么角度，都有很多问题😆

下周我有时间进行工作-让我们聊天，看看能否提出一个聪明的主意。

我同意尽量减少更改的数量，并且必须重新解决已经解决的问题。 我脑海中有两个重要目标：

1. 性能
2. 开发人员的经验（JS样式库通过使开发人员能够轻松地在其应用程序中使用类而在这里大有帮助）

more需要多考虑一下，但是只要我们能够解决这两点，我都会对我们的解决方案感到满意。

另一个随机说明-如果我们有一种自动化的方法来为整个库中的inline / jsstyle /任何代码强制实施某些代码约定和设计模式，那将是非常不错的。

这是您100％反对的事情吗？

@nathanmarks我不是100％反对使用SCSS（_I在work_中使用它）。 但是从我的角度来看，这是一个死胡同。
React的主要优点之一是抽象化了浏览器的呈现特性：DOM。
据我所知，React Core Team的长期目标是提供一个API以编写跨平台组件。 实际上，他们目前正在朝这个方向进行

我完全同意@alitaheri。 我们可以从这两个步骤开始：

• 在任何地方使用getStyles模式，以便以后更轻松地进行迁移。
  我们可以使用codemod吗？ 谁知道。
• 按照@alitaheri的建议分解每个组件。

@oliviertassinari我同意死胡同的结论-这不是未来。 我在很大程度上提出它是为了激发有关如何使JS样式对我们有用的讨论。 我知道周围的人对这个问题有一些好主意😄希望FB随着他们的实验再做一点点！

我实际上认为我们当前采用的getStyles()模式有其自身的问题。 @alitaheri和我今天聊

下周，我将休假，并且将尝试解决当前问题，同时保留所有基于JS的样式。

只需阅读这篇关于阿姆斯特丹React的经验教训（https://medium.com/@kitze/lessons-learned-at-react-amsterdam-51f2006c4a59#.o12h794or）的帖子，其中一个演讲就是关于React样式设计的解决方案： http ：//slides.com/kof/javascript-style-sheets#/针对此讨论的及时介绍。

我一直在思考并且没有看到明确陈述的要求（至少我记得）是支持纯Web与Web并响应本机。 如果意图是仅基于Web的（即，不需要本机响应），那么利用已经有效且强大地支持哪些浏览器并且人们非常熟悉的解决方案将是一件好事。 如果必须支持本机反应，那么就会带来一系列不同的需求和要求。 在评估技术选择，折衷方案等时，要考虑并牢记一些事情。

@hburrows

感谢您分享该演示文稿！

@alitaheri

我们可能要看一下该演示文稿中提到的lib （这是一个演示）。 它可以为我们节省很多工作。 我以前曾看过它，但是有一些我不喜欢的东西（例如要求将每个单独的组件包装在专有的HoC中）。 然而，有一些有关的一些讨论这里发生的一切。 他提到实施这样的更改将允许无HoC的使用。 我确实更喜欢用于工作表编写的方法/设计（也在aphrodite看到）。

或者，我们总是可以为jss创建自己的反应绑定，该绑定可以与mixout 。

lib作者也说了这一点，这与我对the的看法是一致的：

但是，您需要了解，并非所有内容都适合用作样式表。 对于最动态的更改，应使用内联样式。

@nathanmarks实现很小，很容易混淆：grin：
https://github.com/jsstyles/react-jss/blob/master/src/index.js
我认为该库可以帮助我们：+1：

@alitaheri是的，我同意！

我还在尝试一些jss自定义绑定-我想尝试解决一些问题/限制。 （尽管其中一个可能需要对核心库进行工作）

React社区似乎普遍盛行JavaScript样式是最好的解决方案。 那种感觉很好，我并不反对那些拥有这种感觉的人。 但是，JavaScript样式的实现方式几乎总是与CSS开发人员无关。 与className= ，实现常常偏向于style=/[element property]= ，并阻止CSS开发人员完成工作。

正如我在先前的评论中所提供的那样，我认为两者可以很好地生活在一起。 必须简单地采取一种行为方式来应用样式属性。 该库必须能够将样式属性直接应用到元素，或者它必须允许间接创建包含这些样式属性的className的方法。 允许开发人员选择行为的库似乎是理想的解决方案。

CSS开发人员不想直接放弃他们的方法有很多原因。 搜索“为什么使用CSS”以了解人们为什么认为它有益。 您会发现样式的抽象和功能强大的选择器语言是其好处之一。 我们不要忘记，当今存在大量使CSS用户受益的代码。

同样，无论如何，这都不打算成为专业的CSS评论。 我们当中有些人希望使用CSS进行样式设计。 该评论旨在鼓励采用一种架构上中立的样式化方法，使开发人员可以选择。

@rvbyron我们想要更改当前方法的主要原因之一是也使使用CSS自定义组件更加容易。 使用jss类的库将使我们能够在使用js样式的同时使用css功能。 并且由于将这些样式转换为CSS，因此可以轻松地使用额外的类名覆盖它们，而无需使用丑陋的!important hack。

@alitaheri很

同样，很高兴听到className方法。 考虑到这一点，我对如何实现有一些疑问：

• 您认为类名命名约定会是什么样子？
• 所有类名称上都将带有“ mui-”或其他前缀吗？
• 该类是否为组件名称的破折号？
• 是否将类名称应用于每个组件的根元素？

@rvbyron

理想情况下：

可自定义的前缀。 某种形式的短划线表示法可提供更好的开发人员体验，并且还可以使用自定义主题ID将散列后缀设置为固定字符串（因此，如果更改了主题设置，则不会更改）。 包括不太冗长的生产选项，甚至可以自定义回调函数。 而且我认为，无论如何，根源上的类通常总是必要的。

我认为列出了许多要求并提供了建议。 因此，所有讨论是否都没有完成？ 下一步行动是什么？ 关于在此Material-UI中实现react-jss有什么工作要做吗？

@rvbyron是的，我们正在幕后尝试一些粗略的想法。 当我们有了一些更具体的想法时，将更新此问题。

以我的拙见，我认为CSS及其所编译的内容都不是未来的一部分。 我认为我们都同意，内联样式使我们的生活更加轻松。 老实说，我看到的内联样式的唯一限制是：hover！

问题是：hover是样式的非常基本，非常重要的部分。 撇开未来主义，避免过早采用必须通过作弊和变通方法来重新实现本机功能的解决方案可能是明智的。

@wtgtybhertgeghgtwtg我们正在努力使用真实样式表的解决方案，因此支持:hover功能。

鉴于已经确定了主要要点（通过className和根元素classNames进行JSS样式设置），material-ui v0.16.0版本是否有任何路线图和时间表？

@rvbyron我们没有承诺的时间表，但是到目前为止，样式化方法和性能是v0.16.0发行版的主要工作重点，并且我们正在积极努力。 一旦我们确定了其他方面的正确方向，因为它与内部，API，迁移等相关，我们可能会在不久的将来将这个问题用于社区反馈。

@newoga谢谢尼尔！ 我感谢更新。 至于其他问题，我想补充一点，对于许多人来说，仅使用基于className的系统可能是一个视觉上的突破，我建议将此发行版限制在此范围内。 除此之外的其他更改可能确实会阻止迁移。 但是，我知道您的团队会选择最佳的平衡点。

@newoga在这里JSS被称为了作为材料的UI造型系统的未来。 这是否是一个足够具体的计划，以使其他人可以预期16.0版本开始将jss加入我们的项目中？

@sorahn尚未

@sorahn本期旨在让社区反馈有关仍要解决的难题。 尚未做出官方决定。 到目前为止，每个人都应该只选择和使用他们认为最适合自己和项目的样式库或方法。

作为记录，此样式更改的目标不是将所有人迁移到不同的标准，而是使其更易于使用和样式化Material-UI组件，无论您使用哪种样式方法。

tl;博士做最适合您的事情，而不是别人怎么说：)

@nathanmarks @newoga感谢您的更新！

我们在所有内联样式中都遇到了响应式设计+服务器端渲染的局限性，因此我们正在研究其他选择。 关于（s）css-modules或csx或其他内容，没有特别强烈的意见，但是我们喜欢material-ui，所以很高兴能随您便去做：)

我遇到了媒体查询，请阅读此线程（和其他线程）。 我研究了一些潜在的解决方案和文章。

我真的很喜欢JSS + CSX解决方案（从开发人员_joy_的角度来看）。

JSS的优点和性能

与@sorahn相似，我很乐意采用material-ui标准，我希望@nathanmarks在这个方向上的工作可以验证这种方法。 同样，CSX / JSS开发人员似乎都渴望帮助和促进其库的采用。

@rosskevin正如我们所说的

由于设计上的限制或意见，我们的要求比现有解决方案能够支持的要广泛得多。 这主要是因为现有解决方案在开发时就考虑到了应用程序，在这里您可以完全控制组件API的使用，而在库中则拥有各种各样的用户，他们希望使用不同的工具来设计其组件的样式。

@sorahn快速问题-您如何处理服务器端呈现的供应商前缀？ 您是否只是在服务器上渲染所有前缀？ 还是您通过了UA？

@nathanmarks我们正在将用户代理发送到浏览器，但是我个人不喜欢依赖

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

@sorahn您将能够做任何您想做的事情，使用前缀而不是前缀，通过all ，通过UA等。

@nathanmarks我刚刚发布了[email protected]。 最重要的更改-确定性ID的生成，这是带有react http://jsstyles.github.io/examples/index.html的ssr示例

只是在这里投入$ .02 ...虽然我真的很喜欢内联样式和美之女神的主意，但如果样式以基于Bootstrap 4的scss的库格式为基础，这几乎会感觉更容易。

我通常要做的是在创建_mixins.scss文件时，从字面上复制bootstrap.scss文件和_variables.scss文件。使用./lib/style下的副本，我更新本地bootstrap.scss文件以引用本地变量和混入，同时使用其他所有节点的node_modules版本的路径...

然后，我将我的webpack配置设置为使./lib/style成为sassLoader配置搜索路径的一部分。

这样，我可以拥有一个main.scss文件来加载引导程序，等等。。。我可以从那里引用项目其余部分中的变量和/或mixins，并且当我构建/打包输出时，适当的样式是包括在内。

不利的一面是，它将规定使用material-ui作为源（不是预构建）和webpack，以将scss包括在捆绑包中。 也就是说，这可能是使用现有变量，类和样式混合的最直接的方法。

再次，我真的很喜欢JS样式的想法，也很喜欢Aphrodite所提供的东西。。。计划等等。

样式解决方案是否已定稿？

是否有任何更新？

是的， next分支正在使用jss

我刚刚遇到了这个项目，对此感到非常兴奋，因为它看起来很棒，示例页面使您很容易弄清楚如何使用这些组件，并且看起来像它已经被广泛使用。 但是，我对内联阶梯感到非常失望，很高兴看到你们与他们的距离越来越远。 我想指出的一件事是，与这些组件外部的布局有关的所有内容都应删除，并让父组件的样式来处理。 最低层的组件上不应有任何边缘或填充物，以免将周围的元素推开...尤其是因为要在不与内嵌阶梯配合的情况下进行覆盖是不可能的，这意味着我需要深入研究并找出方法那。 我真的没有深入研究这个项目，因为不幸的是我发现它不可用。 我当然阅读了很多有关内联与CSS样式的讨论。 无论如何，您在TextField迷失了我。 顶部有14px的边距，底部有16px的边距。 我不太介意编写一个简单的样式来覆盖它，但是由于内联样式，这是不可能的，不得不创建一个更高级别的组件来扭转这种情况对我来说是完全疯狂的，就像用div包装您的组件一样并执行边距：-14px 0 -16px或通过计算将其稍微调整到我想要的方式，但实际上并不需要以任何方式进行校正。 如果您希望像以前一样允许将className作为道具传递，那么我会更喜欢它，这样布局样式就可以按照您的社区希望为其样式的方式应用于组件。 无论如何，那是我的$ .02。

除此之外，为这些对象创建布局类型组件或制作其他道具来处理布局属性可能是理想的选择，例如使用诸如Foundation和bootstrap这样的网格系统。 例如，使用道具（例如大小，装订线，宽度，列等），但首先要在组件可见的外部周围没有样式。

我完全喜欢@ jbsmith969

对于我来说，不得不创建一个更高级别的组件以扭转这种情况完全是疯狂的，就像用div包装组件并进行边距处理时一样：-14px 0 -16px或通过计算将其稍微调整为我想要的方式

@ jbsmith969我确实同意低级组件不应具有任何布局逻辑。 但是，为您的应用程序专用性创建更高抽象的组件听起来一点也不疯狂。
恕我直言，这是React启用的最强大的模式之一（由于隔离属性）。

@oliviertassinari @ jbsmith969那正是我们所做的！ 我们创建了CustomTextField组件，我将其像2个参数一样传递给了（字段名和颜色），它围绕它们做了一点逻辑，然后用我们所需要的任何东西渲染了一个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遵循Material Design规范。如果我不想遵循该规范，则希望可以采取一些解决方法。但是，我同意MUI很难破解，但这主要是因为不一致的怪异之处组件道具，不是因为它们的样式是内联）

@vizath对，我绝对有同样的想法。 但是此解决方案的优点是什么？

如果有一种解决方案至少可以和CSS一样有效，那么我考虑尝试一下。 但是，由于目前还没有一种解决方案（据我所知），可以不做任何警告，所以我看不到它的顶峰。

为什么此回购尝试尝试采用似乎是alpha阶段的想法来解决原本非常有用的代码库？ 我只是不认为我们已经有了tec，也不认为这是该tec的适当测试平台。

@nathanmarks您可以建议如何使用JSS覆盖组件的样式吗？ 我正在使用next的最新代码

编辑：好的，只是发现它仍然没有完全实现。 我的错！ 😬

我还没有找到消除对象键中无效代码的好方法，并且使用JSS使其强制使用对象存储样式。

next分支的一个组件中的随机示例（尚未完成）： https :
我找不到可靠地找到未使用primary和accent类的方法。

由于相同的原因，我以前也不喜欢MUI管理内联样式的方式（如果样式是分别定义的，则皮棉将捕获未使用的变量，请参见https://github.com/callemall/material-ui/blob/ 60a202fdc9645aa00f20c52e5152f168a1b0031b / src / IconButton / IconButton.js＃L26）。

摆脱无礼的好处是什么？

@gdaunton这取决于您是否不使用内联样式/ sass方法。

从用户的角度来看，它将提供以下改进：

• 更快的反应渲染方法，因为我们将依赖于缓存生成的CSS图纸。
• 简化样式覆盖，因为CSS优先级低于内联样式，并且用户可以使用DevTools识别要更改的工作表。
• 执行服务器端渲染时，可以更快地进行第一次绘制。
  
  
  
  • 用户将能够内嵌关键的CSS表，并且仅内嵌页面中的已用过的CSS表。 那是_Bootstrap_不能做的，因为它很大。
  
  
  • 用户应该能够在生产中使用类名键。
  
  
• 没有像_scss-loader_或_Webpack_这样的内置链依赖性。

从贡献者/维护者的角度来看，它将提供以下改进：

• 没有更多的CSS linter
• 不再需要预处理器CSS
• 无需学习CSS语法
• 一种更强大的用于设置组件样式的语言：JavaScript
• 打开了将样式引擎抽象化的可能性。 例如，通过使用react-with-styles

为什么此回购尝试采用似乎是alpha阶段的想法

取决于您对Alpha Stage想法的理解。
我们远非唯一使用这种方法的人。 例如，AirBnB，可汗学院，ReactNative。

至少和CSS一样好

CSS是从一开始就设计样式的文档，而不是组件。
那是我们行业的重大转变。

从我的角度来看，它吸引了样式的组件。
Web规范的幕后人很清楚这个问题，并尝试使用_Web Components_的本地范围样式来解决。
自从React围绕CSS改进和编写基于组件的样式而启动以来，您是否注意到所有这些新项目？

是的，下一个分支正在使用jss

@nathanmarks我可以去哪里赶上这一变化？

找到了它： https :

@bramick似乎与next无关，因为这是从0.15.0开始的

好吧，所以我想念最新消息...有人吗？

@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成功之后，我了解将CSS放入JavaScript文件中的吸引力，但是我不确定对应用程序的所有CSS进行相同操作是否是个好主意。 我知道JSS有一些很好的用例，例如在处理超复杂的动态样式时。

我最大的担心是样式信息最终将使组件定义混乱。 用JavaScript对象表示的CSS更加冗长，难以组织。 例如，在上一篇文章中引用的Button组件中，几乎一半的代码是样式信息。 不再存在关注点分离。 我知道您可以将样式代码移到单独的文件中，但是首先将其放在JavaScript中是没有意义的。

对于开发人员而言，最大的缺点是，他们失去了CSS属性及其值的

我不介意为项目带来更多价值的复杂性。 因此，我从不介意额外的CSS linter，预处理器，加载程序以及必须学习的额外语法。 我还试图对JSS保持开放态度，只是在初看起来之后，它并没有说服我。

我最大的担心是样式信息最终将使组件定义混乱。

这完全取决于您，取决于代码的组织方式，如果您遵守某些规则，则不会发生任何不良情况（从2年的生产经验谈起）。

用JavaScript对象表达的CSS更加冗长，难以组织。

实际上，它不那么冗长，因为您具有更高级别的代码重用和更少的重复。

对于开发人员而言，最大的缺点是，他们失去了CSS属性及其值的所有智能信息。

我认为这里的目标是使Material-UI的用户可以选择使用他们想要的样式。 我经常听到CSS的自动完成功能。 大多数情况下，它来自于很少使用任何cssinjs的人，而他们只是担心失去过去使用的便利。

我不介意为项目带来更多价值的复杂性。

我认为，这样做的主要目的是降低复杂性，并使代码库更一致，更易于使用和理解，但同时涵盖所有复杂场景。

我最大的担心是样式信息最终将使组件定义混乱。

在我们的项目中，我们将组件的样式信息提取到单独的文件中，并使用webpack加载它们。 主要优点是所有组件都井井有条，并且webpack可以将每个组件的代码捆绑在一起，因此可以拆分js代码和样式信息。

当您分离逻辑以生成样式规则时，也将关注点分离。 一个例子是，我们引入了样式工厂函数，该函数在众所周知的CSS预处理器中生成类似于mixin的样式。
我的观点是，您将获得更多的灵活性来建模自己的特定工作流，并最适合项目和团队的需求。

检查此https://styled-components.com/

改变技术还为时已晚，但我同意样式化组件非常有前途。 处理SSR，媒体查询，非常漂亮的语法等。 与JSS相比，它还处理自动前缀和主题化。

据我所知，它内部使用了postcss，在运行时使用时不会给出令人满意的性能，因为它是一个完整的css解析器，具有许多边缘案例处理和插件。 我可以想象将其预处理为JSS JSON，但是老实说，与仅使用JS相比，使用CSS语言并将其与JS变量和函数调用混合并没有太大价值。

只需提一下，当前已建立样式的组件的大小为250kb，已经缩小。 公平地说，这是因为它们捆绑了React和co，但是，即使是PostCSS解析器，也只有13kb（未压缩，可能是2kb〜），这已经差不多是JSS或Fela的大小了。

尽管对于（表示性）组件的快速简单原型制作来说，它很可爱，但是我看不到其他解决方案无法提供的任何好处/功能。

我同意，我在自己开发的图书馆中对其进行了尝试，而且出版量太大了。 我敢肯定他们会在这方面取得进展，但看来JSS的工作已接近完成，并能提供大多数相同的好处。

我最近使用了react-toolbox ，他们使用CSS模块进行主题化，这些主题基本上只依赖于webpack的sassLoader 。 对我来说，它真的很好。 也许值得研究。

嘿，我不得不赞同@mgcrea的意见，对react-toolbox主题的支持简直令人称奇–切换IM是因为自定义组件的外观是前端故事中最重要的方面。

我认为任何人都不应期望良好的旧CSS样式成为Material UI中的一等公民，这就是react-toolbox开始的原因

至少在阅读了有关该主题的许多问题和帖子后，我的印象才如此。 我可以模糊地记得诸如团队致力于更好地与React Native兼容的事情，以及关于样式化边缘案例的许多评论，这些评论使用JSS更容易解决。

但是，这些信息在许多讨论中丢失了。 因为这是一个有争议的话题，所以我认为，如果可以有一个关于项目目标和理念的Wiki页面（由核心维护者编写），并且对Java样式为何如此根深蒂固，将具有巨大的价值。框架。

我真的很喜欢Material UI，因为它是React上最活跃，最优美的材料样式框架。 但是，当我想与第三方组件保持统一的样式时，JSS一直困扰着我。

对于我自己，我很欣赏Material-UI进行样式设置的方式，而不是诸如react-toolbox之类的原因，原因如下：在我们的一个项目中，我们能够让用户选择动态主题：

由于用户可能会选择我们无法提前确定的颜色对，因此无论使用哪种主题方案，都必须是高度动态的。 用，可以实时更改主题，b / c所有样式都是内联生成的：我要做的就是给它提供原色/强调色。

在react-toolbox等中。 等，从我所看到的来看，这似乎是一件比较琐事。

@jrop yeah在这种非常特殊的情况下，您需要动态JSS，但是对于许多应用程序来说，这不是一个重要的要求，并且当前定制（甚至不谈论UI测试）material-ui的故事是完全不可接受的。 我们正在构建一个高度可视化和设计良好的应用程序，该应用程序不能仅使用默认的材质用户界面外观，因为我们主要需要/想要其中的行为部分。

@DominikGuzei，您可以使用jss自定义next分支。 这不是您在当前版本中看到的。

伙计们，我觉得我们在这里打败一匹死马。 next分支在主题化方面选择了另一条路径（已大大改进），并允许替代。 它不再使用内联样式，并提供了我所要求的灵活性。 对于其他想要更多可定制性的用户，他们可以在next组件上使用HOC并编写自己的样式表。

@nathanmarks ，由于已经做出了此决定（据我所知，并且效果很好👍），我建议您编写摘要并关闭/锁定此问题，以便发现该问题的人员理解前进的方向。

如果可以有一个关于项目目标和理念的Wiki页面（由核心维护者编写），并且强烈说明Java样式为何如此根深蒂固到框架中。

@fgarcia我在本周早些时候在巴黎的一次本地活动上发表了有关Material-UI使用的样式方法的发展的演讲。 您可能会对幻灯片和_notes_：迈向更好的风格的旅程感兴趣。 我专注于挑战，问题和解决方案。

用户选择动态主题

CSS-Modules的静态样式生成方面有很多后果。
在运行时注入样式的成本效率较低，但允许我们：

• 通过样式实现为我们提供了更大的灵活性。 例如， CircularProgress具有固定的thickness与CSS关键帧动画的实现方式相关。 使用动态样式，我们可以添加厚度属性，以便用户可以动态更改值。 ⚠️不要被滥用。
• 在大型应用程序上，它只允许为屏幕上显示的组件注入所需的样式。 减少浏览器引导页面所需的工作量。 因此，交互后第一次绘制的时间更快。 例如，用SSR内嵌关键CSS。
• 允许用户使用动态主题和组件的变体。 例如，使用所需的所有颜色变化来更改按钮的颜色。

@oliviertassinari真是

@oliviertassinari感谢您的好处摘要。 当您查看这些方面时，绝对很有趣。 目前，JSS及其生态系统（也包括postcss）的不利之处在于，所有这些都是最前沿的，您不能像简单的CSS模块+ SASS那样依赖完善的工具链和知识库。 但这就是您为创新付出的代价，这取决于您是否有特定的要求/是否愿意为错误付出的代价以及文件记录较少的路径。

JSS已在css-modules之前创建。 CSS模块之所以变得越来越流行，是因为它解决了大多数用户的问题，而又没有从根本上改变语法。

话虽如此，您正在使用react，这也是一种“新”技术。 如果您想使用SASS，也许您也应该选择vanilajs或bonesjs）

@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的讨论并没有找到终点（还好吗？）。 对我来说，目前看来是五十/五十。

关于SASS，react-toolbox当前正朝着它的方向迁移，转而使用完整的postCSS解决方案，我个人认为postCSS（带有sassLike插件）是一个更好的选择，功能更强大，而且没有构建部门。

所有JS（尤其是React）的样式显然仍处于快速发展状态。 因此，无论您做什么，我都将尽力避免被人接受-恰好适合当前广泛使用。

考虑只在有* style属性的地方添加* className属性。 期。

全面披露：我是阿芙罗狄蒂的快乐用户。

添加className仍然需要!important骇客，因为内联样式（来自style属性）优先。

@ligaz当然，您是对的。 阿芙罗狄蒂默认将!important到所有内容，因此也许我对“广泛使用”的想法严重歪斜了。

@ligaz @estaub - next已被编码为_without_ style并允许组件的用户通过提供className （以及对复杂组件的各个部分使用多个类名）进行覆盖。

维护人员在next分支上设置的样式范例正在使用JSS。 使用起来很高兴，并且很容易以个人或主题为基础进行覆盖。

这匹马死了。 让我们停止殴打它。 @oliviertassinari我建议您使用next上的方向说明来关闭并锁定此问题。

嗨@rosskevin-您能否在接下来的工作中以任何示例向我指出？

我目前正在寻找一个新项目的框架，我很想使用Material UI，但接下来需要您提到的更改。 我已经将下一个分支添加到了测试项目中，并添加了一个简单的组件，并且看到了一个充满内联样式的检查器，所以我猜我在做错什么了吗？

任何进一步的细节将非常有帮助！

谢谢

@giuseppepaul next尚未在npm上发布，因为它是Alpha之前的版本，尚未完成。 您可以克隆https://github.com/callemall/material-ui.git#next并运行docs/site以查看没有更多的内联样式。 它还具有相当数量的演示。

我正在发布我自己的下一个私有版本（以便我可以控制更新），并在即将投入生产的应用程序中使用它。

这匹马死了。 让我们停止殴打它。 @oliviertassinari我建议您关闭并锁定此问题，并在下一步声明方向。

那匹马还没死。 但是绝对是一个紧要关头。
我同意，让我们结束这个问题。

非常感谢@nathanmarks在这个故事上的辛勤工作👏！
我已经在＃5718前进的道路上收集了更多信息。

你好，
IconButton具有CSS3 transition属性，可产生涟漪效应。 在Card @next的文档的复杂交互中，您向转换添加了transition到转换，以在图标反转时添加转换。
如果我在我的应用程序上执行相同的操作，则一个过渡（波纹或反转）将覆盖另一个过渡（一个元素不能具有两个属性，否则一个属性将覆盖另一个属性）。
但是，您的V形图标已成功应用了两个transitions 。 因为以某种方式您会合并由IconButton和代码中定义的转换提供的转换。 您如何实现的？
其他一些东西对我来说是晦涩的，我找不到相关的文档。 theme具有许多方法/属性，如breakpoints （此处未使用） transitions （此处已使用）。 已经有关于theme MuiThemeProvider.createDefaultContext()返回值的theme属性的文档了，因为它似乎很有用，尤其是在代码中广泛使用了它。
this.context.styleManager.render(styleSheet) ？ 什么 ？
您还使用了jss-theme-reactor ，与react-jss相比，我仍然不明白这一点。

@NitroBAY该线程结束。 请在正确的频道上询问您的问题。如果您发现错误或希望改进文档，请打开一个问题。 否则，您可以使用gitter.im的StackOverflow。