2020年更新:最好的做法是使用一个已经为你完成了艰苦工作的库，并且在你进行转换时不会杀死你的团队，正如本视频中最初接受的答案所指出的那样(它仍然相关)。为了了解趋势，这是一个非常有用的图表。在做了自己的研究之后，我选择在我的新项目中使用Emotion，它被证明是非常灵活和可扩展的。

鉴于2015年投票最多的答案是推荐镭，现在已经进入维护模式。因此，增加一些备选方案似乎是合理的。停止使用镭的帖子建议使用几个图书馆。每个链接的网站都有现成的示例，所以我将避免在这里复制和粘贴代码。

Emotion which is "inspired by" styled-components among others, uses styles in js and can be framework agnostic, but definitely promotes its React library. Emotion has been kept up to date as of this post. styled-components is comparable and offers many of the same features as Emotion. Also actively being maintained. Both Emotion and styled-components have similar syntax. It is built specifically to work with React components. JSS Yet another option for styles in js which is framework agnostic though it does have a number of framework packages, React-JSS among them.

James K Nelson在他的信“为什么你不应该用JavaScript样式化React组件”中指出，实际上没有必要使用内联样式及其缺点。他的观点是，旧的无趣的CSS加上较少的/scss是最好的解决方案。他的论文中支持CSS的部分:

可扩展的外部 可分割(内联样式超越一切) define_image_transformation

根据您的配置，内联样式可以为您提供热重载。每次样式改变时，网页都会立即重新呈现。这有助于我更快地开发组件。话虽如此，我相信你可以为CSS + SCSS设置一个热重载环境。

目前还没有很多“最佳实践”。对于React组件，我们这些使用内联样式的人还在进行试验。

有许多不同的方法:React内联风格的库比较图

全有还是全无?

我们所说的“风格”实际上包括以下几个概念:

布局——一个元素/组件与其他元素/组件之间的关系 外观-一个元素/组件的特征 行为和状态——元素/组件在给定状态下的样子

从状态样式开始

React已经管理了组件的状态，这使得状态和行为的风格很自然地适合与组件逻辑的托管。

与其构建使用条件状态类呈现的组件，不如考虑直接添加状态样式:

// Typical component with state-classes
<li 
 className={classnames({ 'todo-list__item': true, 'is-complete': item.complete })} />


// Using inline-styles for state
<li className='todo-list__item'
 style={(item.complete) ? styles.complete : {}} />

请注意，我们正在使用一个类来设置外观样式，但不再使用任何.is前缀的类来表示状态和行为。

我们可以使用Object。assign (ES6)或_。扩展(下划线/lodash)以添加对多个状态的支持:

// Supporting multiple-states with inline-styles
<li 'todo-list__item'
 style={Object.assign({}, item.complete && styles.complete, item.due && styles.due )}>

定制和可重用性

现在我们在使用Object。赋值它变得非常简单，使我们的组件可重复使用不同的风格。如果我们想覆盖默认样式，我们可以在调用站点上使用props来实现，就像这样:<TodoItem dueStyle={fontWeight: "bold"} />。实现如下:

<li 'todo-list__item'
 style={Object.assign({},
         item.due && styles.due,
         item.due && this.props.dueStyles)}>

布局

就我个人而言，我不认为内联布局样式有什么令人信服的理由。有很多很棒的CSS布局系统。我就用一个。

也就是说，不要直接在组件中添加布局样式。用布局组件包装组件。举个例子。

// This couples your component to the layout system
// It reduces the reusability of your component
<UserBadge
 className="col-xs-12 col-sm-6 col-md-8"
 firstName="Michael"
 lastName="Chan" />

// This is much easier to maintain and change
<div class="col-xs-12 col-sm-6 col-md-8">
  <UserBadge
   firstName="Michael"
   lastName="Chan" />
</div>

对于布局支持，我经常尝试将组件设计为100%的宽度和高度。

外观

这是“内联风格”辩论中最有争议的地方。最终，这取决于你设计的组件和你的团队对JavaScript的适应程度。

有一件事是肯定的，你需要图书馆的帮助。浏览器状态(:hover，:focus)和媒体查询在原始React中是痛苦的。

我喜欢镭，因为那些硬部分的语法是为SASS建模而设计的。

代码组织

通常你会在模块外部看到一个style对象。对于todo-list组件，它可能看起来像这样:

var styles = {
  root: {
    display: "block"
  },
  item: {
    color: "black"

    complete: {
      textDecoration: "line-through"
    },

    due: {
      color: "red"
    }
  },
}

getter函数

向模板中添加一堆样式逻辑可能会有点混乱(如上所示)。我喜欢创建getter函数来计算样式:

React.createClass({
  getStyles: function () {
    return Object.assign(
      {},
      item.props.complete && styles.complete,
      item.props.due && styles.due,
      item.props.due && this.props.dueStyles
    );
  },

  render: function () {
    return <li style={this.getStyles()}>{this.props.item}</li>
  }
});

进一步的观察

今年早些时候，我在React Europe上更详细地讨论了所有这些:内联样式和什么时候“只使用CSS”最好。

我很高兴帮助你在这条路上有新的发现:)打我-> @chantastic

这取决于你的应用程序有多大，如果你想使用webpack这样的捆绑器，在构建中将CSS和JS捆绑在一起，以及你想如何管理你的应用程序流!最后，取决于你的情况，你可以做出决定!

在大型项目中，我对组织文件的偏好是将CSS和JS文件分开，这可能更容易共享，更容易让UI人员浏览CSS文件，也更整洁地组织整个应用程序的文件!

始终以这种方式思考，确保在开发阶段所有东西都在它们应该在的地方，正确命名，并且易于其他开发人员找到……

我个人会根据自己的需要来混合它们，比如…… 尝试使用外部css，但如果需要React也会接受style，你需要将它作为一个带有key value的对象传递，如下所示:

import React from 'react';

const App = props => {
  return (
    <div className="app" style={{background: 'red', color: 'white'}}>  /*<<<<look at style here*/
      Hello World...
    </div>
  )
}

export default App;

无论如何，内联css是不推荐的。我们在基于JSS的项目中使用了样式组件。它通过在组件上添加动态类名来保护css覆盖。您还可以根据传递的道具添加css值。