我知道你可以在React类中指定样式，像这样:
const MyDiv = React.createClass({
render: function() {
const style = {
color: 'white',
fontSize: 200
};
return <div style={style}> Have a good and productive day! </div>;
}
});
我应该瞄准这样做的所有样式，并没有在我的CSS文件中指定的样式吗?
或者我应该完全避免内联样式?
这似乎有点奇怪和混乱做一点两者-两个地方需要检查时调整样式。
当前回答
React中的style属性期望值是一个对象，即键值对。
Style ={}将在其中包含另一个对象，如{float:'right'}，以使其工作。
<span style={{float:'right'}}>Download Audit</span>
希望这能解决问题
其他回答
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.
目前还没有很多“最佳实践”。对于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
下面是JSX语法中基于布尔的样式:
style={{display: this.state.isShowing ? "inherit" : "none"}}
根据您的配置，内联样式可以为您提供热重载。每次样式改变时，网页都会立即重新呈现。这有助于我更快地开发组件。话虽如此，我相信你可以为CSS + SCSS设置一个热重载环境。
内联样式的问题是内容安全策略(CSP)越来越普遍，不允许使用内联样式。因此，我建议完全避免使用内联样式。
更新: 为了进一步解释，CSP是服务器发送的HTTP报头，用于限制页面上可以出现的内容。这只是进一步的缓解措施，可以应用到服务器上，以阻止攻击者在开发人员对站点编写糟糕的代码时做一些调皮的事情。
The purpose of most of these restrictions is to stop XSS (cross-site scripting) attacks. XSS is where an attacker figures out a way to include his own javascript on your page (for example, if I make my username bob<SCRIPT>alert("hello")</SCRIPT> and then post a comment, and you visit the page, it shouldn't show an alert). Developers should deny the ability to have a user add content like this to the site, but just in case they made a mistake, then CSP blocks the page from loading if it finds any script> tags.
CSP只是对开发人员的额外保护级别，以确保如果他们犯了错误，攻击者不会对该站点的访问者造成问题。
所以这一切都是XSS，但如果攻击者不能包括<script>标签，但可以包括<style>标签或在标签上包含style=参数呢?然后，他可能会改变网站的外观，使您被骗点击错误的按钮，或者出现其他问题。这不是什么大问题，但仍然需要避免，CSP可以为您做到这一点。
用于测试CSP站点的一个很好的资源是https://securityheaders.io/
你可以在http://www.html5rocks.com/en/tutorials/security/content-security-policy/上阅读更多关于CSP的信息
