React.js内联样式最佳做法

本文翻译自：React.js inline style best practices

I'm aware that you can specify styles within React classes, like this: 我知道您可以在React类中指定样式，如下所示：

var MyDiv = React.createClass({
  render: function() {
    var style = {
      color: 'white',
      fontSize: 200
    };

    return <div style={style}> Have a good and productive day! </div>;
  }
});

Should I be aiming to do all styling this way, and have no styles at all specified in my CSS file? 我是否应该以这种方式进行所有样式设置，并且在CSS文件中完全没有指定任何样式？

Or should I avoid inline styles completely? 还是应该完全避免使用内联样式？

It seems odd and messy to do a little bit of both - two places would need to be checked when tweaking styling. 两者兼而有之，似乎很奇怪而且很乱-在调整样式时需要检查两个位置。

---

#1楼

参考：https://stackoom.com/question/1onHV/React-js内联样式最佳做法

---

#2楼

The main purpose of the style attribute is for dynamic, state based styles. 样式属性的主要目的是用于基于状态的动态样式。 For example, you could have a width style on a progress bar based on some state, or the position or visibility based on something else. 例如，您可以在进度条上基于某些状态，或者在位置或可见性基于其他状态下具有宽度样式。

Styles in JS impose the limitation that the application can't provide custom styling for a reusable component. JS中的样式强加了限制，即应用程序无法为可重用组件提供自定义样式。 This is perfectly acceptable in the aforementioned situations, but not when you change the visible characteristics, especially color. 在上述情况下，这是完全可以接受的，但当您更改可见特性（尤其是颜色）时，这是完全可以接受的。

---

#3楼

I use inline styles extensively within my React components. 我在React组件中广泛使用内联样式。 I find it so much clearer to colocate styles within components because it's always clear what styles the component does and doesn't have. 我发现将样式并置在组件中非常清晰，因为它总是很清楚组件使用和不使用的样式。 Plus having the full power of Javascript at hand really simplifies more complex styling needs. 加上手头的Java脚本的全部功能确实简化了更复杂的样式需求。

I wasn't convinced at first but after dabbling in it for several months, I'm fully converted and am in process of converting all my CSS to inline or other JS-driven css methods. 一开始我并没有说服，但是经过数月的尝试，我已经完全转换，并且正在将所有CSS转换为内联或其他JS驱动的CSS方法。

This presentation by Facebook employee and React contributor "vjeux" is really helpful as well — https://speakerdeck.com/vjeux/react-css-in-js Facebook员工和React贡献者“ vjeux”的演示也非常有帮助— https://speakerdeck.com/vjeux/react-css-in-js

---

#4楼

The problem with inline styles is Content Security Policies (CSP) are becoming more common, which do not allow it. 内联样式的问题是内容安全策略（CSP）变得越来越普遍，不允许这样做。 Therefore, I recommend avoiding inline styles completely. 因此，我建议完全避免使用内联样式。

Update: To explain further, CSP are HTTP headers sent by the server that restrict what content can appear on the page. 更新：为了进一步说明，CSP是服务器发送的HTTP标头，它们限制了可以在页面上显示的内容。 It is simply a further mitigation that can be applied to a server to stop an attacker from doing something naughty if the developer code the site poorly. 如果开发人员对站点的编码不正确，则可以将其简单地应用到服务器上，以阻止攻击者做任何顽皮的事情。

The purpose of most of these restrictions is to stop XSS (cross-site scripting) attacks. 这些限制的大多数目的是阻止XSS（跨站点脚本）攻击。 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). XSS是攻击者找出在页面上包含他自己的javascript的方法（例如，如果我使我的用户名bob<SCRIPT>alert("hello")</SCRIPT>然后发表评论，则您访问了页，它不应显示警报）。 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会在发现任何script>标签的情况下阻止该页面的加载。

CSP are just an extra level of protection for developers to ensure if they made a mistake, that an attacker can't cause problems to visitors to that site. CSP只是对开发人员的一种额外保护，可确保开发人员犯了一个错误，即攻击者不会对该站点的访问者造成问题。

So that all is XSS, but what if the attacker can't include <script> tags but can include <style> tags or include a style= parameter on a tag? 这样就全都是XSS了，但是如果攻击者不能包含<script>标签，但可以包含<style>标签或在标签上包含style=参数怎么办？ Then he might be able to change the look of the site in such a way that you're tricked into clicking the wrong button, or some other problem. 然后，他也许可以以某种方式来更改网站的外观，从而使您被诱骗单击错误的按钮或其他问题。 This is much less of a concern, but still something to avoid, and CSP does that for you. 这不是什么要担心的问题，但是仍然需要避免，CSP会为您做到这一点。

A good resource for testing a site for CSP is https://securityheaders.io/ https://securityheaders.io/是测试CSP网站的一个很好的资源。

You can read more about CSP at: http://www.html5rocks.com/en/tutorials/security/content-security-policy/ 您可以在以下位置阅读有关CSP的更多信息： http : //www.html5rocks.com/zh-cn/tutorials/security/content-security-policy/

---

#5楼

I usually have scss file associated to each React component. 我通常有与每个React组件相关联的scss文件。 But, I don't see reason why you wouldn't encapsulate the component with logic and look in it. 但是，我不明白为什么您不使用逻辑封装组件并查看它的原因。 I mean, you have similar thing with web components. 我的意思是，Web组件也有类似的问题。

---

#6楼

What I do is give each one of my reusable component a unique custom element name and then create a css file for that component, specifically, with all styling options for that component (and only for that component). 我要做的是为我的每个可重用组件提供一个唯一的自定义元素名称，然后为该组件创建一个css文件，尤其是为该组件（以及仅针对该组件）提供所有样式选项。

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

And in file 'custom-component.css', every entry will start with the custom-component tag: 在文件“ 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; 
}

That means you don't loose the critical notion of separating of concern. 这意味着您不会松开关注点分离的关键概念。 View vs style. 视图与风格。 If you share your component, it is easier for other to theme it to match the rest of their web page. 如果共享您的组件，则其他人可以更轻松地为其设置主题以使其与其余网页匹配。