目前还没有很多“最佳实践”。对于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

我所做的是为每个可重用组件提供一个唯一的自定义元素名称，然后为该组件创建一个CSS文件，特别是包含该组件的所有样式选项(并且仅针对该组件)。

var MyDiv = React.createClass({
  render: function() {
    return <custom-component style={style}> Have a good and productive day! </custom-component>;
  }
});

在文件'custom-component.css'中，每个条目都以custom-component标签开始:

custom-component { 
   display: block; /* have it work as a div */
   color: 'white'; 
   fontSize: 200; 
} 
custom-component h1 { 
  font-size: 1.4em; 
}

这意味着你不会失去关注点分离的关键概念。视图与样式。如果你共享你的组件，其他人更容易将其主题化以匹配他们网页的其余部分。

我更喜欢使用样式化组件。为设计提供了较好的解决方案。

import React, { Component, Fragment } from 'react'
import styled from 'styled-components';

const StyledDiv = styled.div`
    display: block;
    margin-left: auto;
    margin-right: auto;
    font-size:200; // here we can set static
    color: ${props => props.color} // set dynamic color by props
`;

export default class RenderHtml extends Component {
    render() {
        return (
            <Fragment>
                <StyledDiv color={'white'}>
                    Have a good and productive day!
                </StyledDiv>
            </Fragment>
        )
    }
}

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

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

对于某些组件，使用内联样式更容易。此外，我发现它更容易和更简洁(因为我使用Javascript而不是CSS)动画组件样式。

对于独立组件，我使用“扩展操作符”或“…”。对我来说，它清晰、美丽，在狭小的空间里也能工作。下面是我制作的一个加载动画来展示它的好处:

<div style={{...this.styles.container, ...this.state.opacity}}>
    <div style={{...this.state.colors[0], ...this.styles.block}}/>
    <div style={{...this.state.colors[1], ...this.styles.block}}/>
    <div style={{...this.state.colors[2], ...this.styles.block}}/>
    <div style={{...this.state.colors[7], ...this.styles.block}}/>
    <div style={{...this.styles.block}}/>
    <div style={{...this.state.colors[3], ...this.styles.block}}/>
    <div style={{...this.state.colors[6], ...this.styles.block}}/>
    <div style={{...this.state.colors[5], ...this.styles.block}}/>
    <div style={{...this.state.colors[4], ...this.styles.block}}/>
  </div>

    this.styles = {
  container: {
    'display': 'flex',
    'flexDirection': 'row',
    'justifyContent': 'center',
    'alignItems': 'center',
    'flexWrap': 'wrap',
    'width': 21,
    'height': 21,
    'borderRadius': '50%'
  },
  block: {
    'width': 7,
    'height': 7,
    'borderRadius': '50%',
  }
}
this.state = {
  colors: [
    { backgroundColor: 'red'},
    { backgroundColor: 'blue'},
    { backgroundColor: 'yellow'},
    { backgroundColor: 'green'},
    { backgroundColor: 'white'},
    { backgroundColor: 'white'},
    { backgroundColor: 'white'},
    { backgroundColor: 'white'},
    { backgroundColor: 'white'},
  ],
  opacity: {
    'opacity': 0
  }
}

2019年11月

在这个行业(一家财富500强公司)工作，我不允许做任何内联样式。在我们的团队中，我们认为内联样式是不可读和不可维护的。而且，在亲眼看到内联样式如何使支持应用程序变得完全无法忍受之后，我不得不同意这一点。我完全反对内联样式。

内联样式的问题是内容安全策略(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的信息