React官网的RECENT POSTS阅读

React.renderComponent(, domNode)

我们收到关于React问题中，有大部分是关于props的，特别是人们希望对props进行验证或者使其有个合理的默认值。

在使用props之前，我们经常对props的某些参数进行某些特殊的处理，例如：需要确定这些属性是否是特定的类型、需求限定某些值、某些参数的成分是必须的。这些验证我们都可以在render里面处理，但是这回使render显得臃肿！

现在，React v.04带来的内建的验证模块，你可以写你自己的限定

React.createClass({
  propTypes: {
    // An optional string prop named "description".
    description: React.PropTypes.string,
    // A required enum prop named "category".
    category: React.PropTypes.oneOf(["News","Photos"]).isRequired,
    // A prop named "dialog" that requires an instance of Dialog.
    dialog: React.PropTypes.instanceOf(Dialog).isRequired
  },
  ...
});

在以往的例子里面，我们经常看到以下代码：

React.createClass({
  render: function() {
    var value = this.props.value || "default value";
    return 
{value}
;
  }
});

如果对几个穿插在几个不同组件的props进行以上操作，这将会产生大量的冗余代码。在React v0.04中，你可以以申明的方式提供默认值。

React.createClass({
  getDefaultProps: function() {
    return {
      value: "default value"
    };
  }
  ...
});

在render之前，我们使用这些函数进行处理（我们也会在render之前支持所有的验证函数），以保证你在使用的时候拿到的数据是你所需要的。

Both of these features are entirely optional. We"ve found them to be increasingly valuable at Facebook as our applications grow and evolve, and we hope others find them useful as well.

React v0.4.1版本只是进行了小小的改动。主要是进行修复。部分代码在底层修改了，但是这不会影响你调用我们的公共Api。

setState的callback参数，会在组件域调用。

click事件已经在移动Safari上支持。

阻止已经在Object.prototype上存在的事件错误处理。

不用设置先前就已经定义了的DOM属性为undefined。

优化对iframe属性的支持。

增加checksums属性来检测和校验服务端渲染和客户端实际渲染内容的是否一致。

改良环境检测机制，使其能运行在非浏览器环境。

Improved environment detection so it can be run in a non-browser environment.

今天我们很高兴的宣布PyReact的初始版本的发布。它使得在你的pyhton应用中能够很好的使用React和JSX。PyReact设计的宗旨是提供一个转化JSX为JavaScript的API。

from react import jsx
# For multiple paths, use the JSXTransformer class.
transformer = jsx.JSXTransformer()
for jsx_path, js_path in my_paths:
    transformer.transform(jsx_path, js_path)
# For a single file, you can use a shortcut method.
jsx.transform("path/to/input/file.jsx", "path/to/output/file.js")

#install
$ pip install PyReact
#use
PIPELINE_COMPILERS = ( "react.utils.pipeline.JSXCompiler",)

Jordan Walke 实现了一个完整的react项目react-page。其支持客户端和服务端的渲染、使用模板系统进行转化和打包、实时重载。

为什么使用服务端渲染？

提高页面初始化速度

在下载JavaScript前，一些标签元素将会被展示给用户。

在服务端标签元素的构建远远快于客户端。

更快的开发和构建原型

不用等待任何监听脚本或打包器。

更容易的部署

SEO

服务端渲染是如何进行的？

在服务端构建、发送标签给客户端，这样用户可以很快的看到内容。

然后对应的JavaScript将会被打包送往客户端。

浏览器运行对应JavaScript，这样所有的事件句柄、交互、数据更新等将会无缝隙的对服务端生成的标记进行绑定。

肉眼看来这一切好像都是发生在客户端，只是更快。

优化内存使用：通过使用 GC PAUSES（GC：Garbage Collection，垃圾收集，垃圾回收）机制，减少核心内存分配。

提升性能：为了提供代码运行速度，我们从V8和Nitro中剔除了一些slow path code。

在网络设备里面区分不同的路径是一个很自然的选择，因为网络设备的首要任务是转发网络包，不同的网络包，在设备里面的处理路径不同。fast path就是那些可以依据已有状态转发的路径，在这些路径上，网关，二层地址等都已经准备好了，不需要缓存数据包，而是可以直接转发。slow path是那些需要额外信息的包，比如查找路由，解析MAC地址等。
first path是设备收到流上第一个包所走过的路径，比如tcp里面的syn包，有些实现把三次握手都放到first path里面处理，而有些只需处理syn包，其他包就进入fast path的处理路径。
在NP或者ASIC里面也需要区分slow path和fast path，fast path上的包都放在SRAM里面，而slow path的包放在DRAM里面。不过这也非绝对。决定处理路径的是对于速度的考虑。处理器的速度，内存的速度等。访问内存的速度由速度和带宽两个因素决定。因此，把SRAM放到fast path上，也是很自然的选择。
fast path: Frontend -> simple code generator -> assembler
slow path: Frontend -> IR optimizer (sometimes more than one level of IR) -> code-generator -> assembler

标准化支持：DOM属性的处理。在处理之前不仅有多余的检查和开销，而且还是混淆使用者。现在我们会一直控制你的属性值为string直到渲染。

支持Selection事件。

支持混合事件（池化哟）。

支持一些额外DOM属性：charSet, content, form, httpEquiv, rowSpan, autoCapitalize。

支持额外的SVG属性：rx、ry。

同时支持getInitialState和getDefaultProps。

支持挂载到iframes。

表单组件的bugfix。

增加react.version。

增加react.isValidClass：用户检查某个值是否是有效的组件构造函数。

删除React.autoBind。在React v0.4中弃用，现在正式删除。

重命名：React.unmountAndReleaseReactRootNode 为 React.unmountComponentAtNode。

开始着手于精细的性能分析。

更好的支持服务端渲染。

是React运行于一个严格的安全策略下成为可能。同时使使用React编写chrome插件成为可能。

属性class更名问className。

增加警告提示（非生产环境）。

改善Window兼容性。

我们JSX解释器处理空格上面进行了改变。简单来说就是，在一行上面组件与组件之前的空格将会被保留，而换行(文本节点或者组件)会被忽略。

  Monkeys:
  {listOfMonkeys} {submitButton}

0.8-
React.DOM.div(null,
  " Monkeys: ",
  listOfMonkeys, submitButton
)
0.9+
React.DOM.div(null,
  "Monkeys:",
  listOfMonkeys, " ", submitButton
)

相信这个新特性会非常有空，可以有效减少匆忙之中带来的非期待的空格。

如果你希望保留 后面紧跟换行文本节点 后面的空格，那么你可以在JSX里面使用这种写法：{"Monkeys: }。

我们在去年春天发布了React，但是我们却有意的没有发布版本React v1.0。其实我们已经做好了生产准备，但是我们计划在内部和外部根据开发者怎么使用React来发展API和行为特性。在过去的九个月我们学到了很多，并且思考很多关于1.0对于React意味着什么。在过去的两周内，我在多个项目里面概述了我们打算进入1.0+的世界。今天我书写一点点给我们的用户，以便用户更好的了解我们的计划。

我们在1.0中主要的目的是阐明我们的消息模式，并且聚焦在一个与我们目的相关的API上面进行处理。为了完成这个目的，我们清除一些已经遇到的不友好的模式，真正的帮助开发者写出更好的代码。

在我们正式推出React之前，我们就思考过如何在React里面利用ES6，即类，以此来提高创建React组件的体验。我们觉得使用 React.createClass(…) 不是一个最好的选择。即使在使用方面优劣性没有正确的答案，但是我们在向ES6方面靠拢。我们希望确保这个过程尽可能的简单。例如：

class MyComponent extends React.Component {
  render() {
    ...
  }
}

其他一些ES6的特性我们在React核心使用了。确信后面会有更多的特性加入。

JSX在ES6方面的支持我们已经在react-tools里面搭船上线。已经支持转化大部分的ES6代码转换为老浏览器支持的代码。

尽管我们没有在文档中提及过context，但是它以某种形式在React确切存在的。

While we haven"t documented context, it exists in some form in React already. It exists as a way to pass values through a tree without having to use props at every single point. We"ve seen this need crop up time and time again, so we want to make this as easy as possible. Its use has performance tradeoffs, and there are known weaknesses in our implementation, so we want to make sure this is a solid feature.

从React0.11开始，getDefaultProps()只会在 React.createClass() 调用的时候调用一次，替代原来每次组件渲染时调用。这就意味着 getDefaultProps() 不会改变他的返回值，同时任何对象将会在所有实例中共享。这个改变提示了性能，并且使得将来能够更早的在渲染中做 PropTypes check ，这将使我们能够给出更好的错误提示。

自从React发布以来，开发者基本都遇到过 render nothing 的情况。通常是返回一个空