Perhaps the biggest reason was to create a defined API for dealing with
+internals, so that other tools could benefit as well and not have to depend on
+implementation details. This gives us more freedom to refactor things
+internally without worrying about breaking tooling.
+
+
The current version of the devtools is a fork of Blink's "Elements" pane, and
+is imperative, mutation-driven, and tightly integrated with Chrome-specific
+APIs. The new devtools are much less coupled to Chrome, and easier to reason
+about thanks to React.
First, disable the Chrome web store version, or it will break things. Then
+download the .crx and
+drag it into your chrome://extensions page. If it's not working to drag it
+from the downloads bar, try opening your downloads folder and drag it from
+there.
+
+
Once we've determined that there aren't any major regressions, we'll update
+the official web store version, and everyone will be automatically upgraded.
Perhaps the biggest reason was to create a defined API for dealing with
+internals, so that other tools could benefit as well and not have to depend on
+implementation details. This gives us more freedom to refactor things
+internally without worrying about breaking tooling.
+
+
The current version of the devtools is a fork of Blink's "Elements" pane, and
+is imperative, mutation-driven, and tightly integrated with Chrome-specific
+APIs. The new devtools are much less coupled to Chrome, and easier to reason
+about thanks to React.
First, disable the Chrome web store version, or it will break things. Then
+download the .crx and
+drag it into your chrome://extensions page. If it's not working to drag it
+from the downloads bar, try opening your downloads folder and drag it from
+there.
+
+
Once we've determined that there aren't any major regressions, we'll update
+the official web store version, and everyone will be automatically upgraded.
At the React.js conference in late January 2015, we revealed our next major technology in the React family: Relay.
-
-
Relay is a new way of structuring client applications that co-locates data-fetching requirements and React components. Instead of placing data fetching logic in some other part of the client application – or embedding this logic in a custom endpoint on the server – we instead co-locate a declarative data-fetching specification alongside the React component. The language of this declarative specification is GraphQL.
-
-
GraphQL was not invented to enable Relay. In fact, GraphQL predates Relay by nearly three years. It was invented during the move from Facebook's HTML5-driven mobile applications to purely native applications. It is a query language for graph data that powers the lion's share of interactions in the Facebook Android and iOS applications. Any user of the native iOS or Android app in the last two years has used an app powered by GraphQL.
-
-
We plan to open-source a reference implementation of a GraphQL server and publish a language specification in the coming months. Our goal is to evolve GraphQL to adapt to a wide range of backends, so that projects and companies can use this technology to access their own data. We believe that this is a compelling way to structure servers and to provide powerful abstractions, frameworks and tools – including, but not exclusively, Relay – for product developers.
We will dig into the syntax and semantics of GraphQL in a later post, but even a simple example shows many of its design principles:
-
-
-
Hierarchical: Most product development today involves the creation and manipulation of view hierarchies. To achieve congruence with the structure of these applications, a GraphQL query itself is a hierarchical set of fields. The query is shaped just like the data it returns. It is a natural way for product engineers to describe data requirements.
-
Product-centric: GraphQL is unapologetically driven by the requirements of views and the front-end engineers that write them. We start with their way of thinking and requirements and build the language and runtime necessary to enable that.
-
Client-specified queries: In GraphQL, the specification for queries are encoded in the client rather than the server. These queries are specified at field-level granularity. In the vast majority of applications written without GraphQL, the server determines the data returned in its various scripted endpoints. A GraphQL query, on the other hand, returns exactly what a client asks for and no more.
-
Backwards Compatible: In a world of deployed native mobile applications with no forced upgrades, backwards compatibility is a challenge. Facebook, for example, releases apps on a two week fixed cycle and pledges to maintain those apps for at least two years. This means there are at a minimum 52 versions of our clients per platform querying our servers at any given time. Client-specified queries simplifies managing our backwards compatibility guarantees.
-
Structured, Arbitrary Code: Query languages with field-level granularity have typically queried storage engines directly, such as SQL. GraphQL instead imposes a structure onto a server, and exposes fields that are backed by arbitrary code. This allows for both server-side flexibility and a uniform, powerful API across the entire surface area of an application.
-
Application-Layer Protocol: GraphQL is an application-layer protocol and does not require a particular transport. It is a string that is parsed and interpreted by a server.
-
Strongly-typed: GraphQL is strongly-typed. Given a query, tooling can ensure that the query is both syntactically correct and valid within the GraphQL type system before execution, i.e. at development time, and the server can make certain guarantees about the shape and nature of the response. This makes it easier to build high quality client tools.
-
Introspective: GraphQL is introspective. Clients and tools can query the type system using the GraphQL syntax itself. This is a powerful platform for building tools and client software, such as automatic parsing of incoming data into strongly-typed interfaces. It is especially useful in statically typed languages such as Swift, Objective-C and Java, as it obviates the need for repetitive and error-prone code to shuffle raw, untyped JSON into strongly-typed business objects.
Obviously GraphQL is not the first system to manage client-server interactions. In today's world there are two dominant architectural styles for client-server interaction: REST and ad hoc endpoints.
REST an acronym for Representational State Transfer, which is an architectural style rather than a formal protocol. There is actually much debate about what exactly REST is and is not. We wish to avoid such debates. We are interested in the typical attributes of systems that self-identify as REST, rather than systems which are formally REST.
-
-
Objects in a typical REST system are addressable by URI and interacted with using verbs in the HTTP protocol. An HTTP GET to a particular URI fetches an object and returns a server-specified set of fields. An HTTP PUT edits an object; an HTTP DELETE deletes an object; and so on.
-
-
We believe there are a number of weakness in typical REST systems, ones that are particularly problematic in mobile applications:
-
-
-
Fetching complicated object graphs require multiple round trips between the client and server to render single views. For mobile applications operating in variable network conditions, these multiple roundtrips are highly undesirable.
-
Invariably fields and additional data are added to REST endpoints as the system requirements change. However, old clients also receive this additional data as well, because the data fetching specification is encoded on the server rather than the client. As result, these payloads tend to grow over time for all clients. When this becomes a problem for a system, one solution is to overlay a versioning system onto the REST endpoints. Versioning also complicates a server, and results in code duplication, spaghetti code, or a sophisticated, hand-rolled infrastructure to manage it. Another solution to limit over-fetching is to provide multiple views – such as “compact” vs “full” – of the same REST endpoint, however this coarse granularity often does not offer adequate flexibility.
-
REST endpoints are usually weakly-typed and lack machine-readable metadata. While there is much debate about the merits of strong- versus weak-typing in distributed systems, we believe in strong typing because of the correctness guarantees and tooling opportunities it provides. Developer deal with systems that lack this metadata by inspecting frequently out-of-date documentation and then writing code against the documentation.
-
Many of these attributes are linked to the fact that “REST is intended for long-lived network-based applications that span multiple organizations” according to its inventor. This is not a requirement for APIs that serve a client app built within the same organization.
-
-
-
Nearly all externally facing REST APIs we know of trend or end up in these non-ideal states, as well as nearly all internal REST APIs. The consequences of opaqueness and over-fetching are more severe in internal APIs since their velocity of change and level of usage is almost always higher.
-
-
Because of multiple round-trips and over-fetching, applications built in the REST style inevitably end up building ad hoc endpoints that are superficially in the REST style. These actually couple the data to a particular view which explicitly violates one of REST's major goals. Most REST systems of any complexity end up as a continuum of endpoints that span from “traditional” REST to ad hoc endpoints.
Many applications have no formalized client-server contract. Product developers access server capabilities through ad hoc endpoints and write custom code to fetch the data they need. Servers define procedures, and they return data. This approach has the virtue of simplicity, but can often become untenable as systems age.
-
-
-
These systems typically define a custom endpoint per view. For systems with a wide surface area this can quickly grow into a maintenance nightmare of orphaned endpoints, inconsistent tooling, and massive server code duplication. Disciplined engineering organizations can mitigate these issues with great engineering practices, high quality abstractions, and custom tooling. However, given our experience we believe that custom endpoints tend to lead to entropic server codebases.
-
Much like REST, the payloads of custom endpoints grow monotonically (even with mitigation from versioning systems) as the server evolves. Deployed clients cannot break, and, with rapid release cycles and backwards compatibility guarantees, distributed applications will have large numbers of extant versions. Under these constraints it is difficult remove data from a custom endpoint.
-
Custom endpoints tend to – for a client developer – create a clunky, multi-language, multi-environment development process. No matter if the data has been accessed before in a different view, they are required to first change the custom endpoint, then deploy that code to a server accessible from a mobile device, and only then change the client to utilize that data. In GraphQL – unless the data in the view is completely new to the entire system – a product developer adds a field to a GraphQL query and the work on the client continues unabated.
-
Much like REST, most systems with custom endpoints do not have a formalized type system, which eliminates the possibility for the tools and guarantees that introspective type systems can provide. Some custom-endpoint-driven systems do use a strongly typed serialization scheme, such as Protocol Buffers, Thrift, or XML. Those do allow for direct parsing of responses into typed classes and eliminating boilerplate shuffling from JSON into handwritten classes. These systems are as not as expressive and flexible as GraphQL, and the other downsides of ad hoc endpoints remain.
-
-
-
We believe that GraphQL represents a novel way of structuring the client-server contract. Servers publish a type system specific to their application, and GraphQL provides a unified language to query data within the constraints of that type system. That language allows product developers to express data requirements in a form natural to them: a declarative and hierarchal one.
-
-
This is a liberating platform for product developers. With GraphQL, no more contending with ad hoc endpoints or object retrieval with multiple roundtrips to access server data; instead an elegant, hierarchical, declarative query dispatched to a single endpoint. No more frequent jumps between client and server development environments to do experimentation or to change or create views of existing data; instead experiments are done and new views built within a native, client development environment exclusively. No more shuffling unstructured data from ad hoc endpoints into business objects; instead a powerful, introspective type system that serves as a platform for tool building.
-
-
Product developers are free to focus on their client software and requirements while rarely leaving their development environment; they can more confidently support shipped clients as a system evolves; and they are using a protocol designed to operate well within the constraints of mobile applications. Product developers can query for exactly what they want, in the way they think about it, across their entire application's data model.
Over the coming months, we will share more technical details about GraphQL, including additional language features, tools that support it, and how it is built and used at Facebook. These posts will culminate in a formal specification of GraphQL to guide implementors across various languages and platforms. We also plan on releasing a reference implementation in the summer, in order to provide a basis for custom deployments and a platform for experimentation. We're incredibly excited to share this system and work with the open source community to improve it.
v0.9 has only been out for a month, but we’re getting ready to push out v0.10 already. Unlike v0.9 which took a long time, we don't have a long list of changes to talk about.
+
+
The release candidate is available for download from the CDN:
The main purpose of this release is to provide a smooth upgrade path as we evolve some of the implementation of core. In v0.9 we started warning in cases where you called methods on unmounted components. This is part of an effort to enforce the idea that the return value of a component (React.DOM.div(), MyComponent()) is in fact not a reference to the component instance React uses in the virtual DOM. The return value is instead a light-weight object that React knows how to use. Since the return value currently is a reference to the same object React uses internally, we need to make this transition in stages as many people have come to depend on this implementation detail.
+
+
In 0.10, we’re adding more warnings to catch a similar set of patterns. When a component is mounted we clone it and use that object for our internal representation. This allows us to capture calls you think you’re making to a mounted component. We’ll forward them on to the right object, but also warn you that this is breaking. See “Access to the Mounted Instance” on this page. Most of the time you can solve your pattern by using refs.
+
+
Storing a reference to your top level component is a pattern touched upon on that page, but another examples that demonstrates what we see a lot of:
+
// This is a common pattern. However instance here really refers to a
+// "descriptor", not necessarily the mounted instance.
+varinstance=<MyComponent/>;
+React.renderComponent(instance);
+// ...
+instance.setProps(...);
+
+// The change here is very simple. The return value of renderComponent will be
+// the mounted instance.
+varinstance=React.renderComponent(<MyComponent/>)
+// ...
+instance.setProps(...);
+
+
These warnings and method forwarding are only enabled in the development build. The production builds continue to work as they did in v0.9. We strongly encourage you to use the development builds to catch these warnings and fix the call sites.
+
+
The plan for v0.11 is that we will go fully to "descriptors". Method calls on the return value of MyComponent() will fail hard.
Added an option argument to transform function. The only option supported is harmony, which behaves the same as jsx --harmony on the command line. This uses the ES6 transforms from jstransform.
There have been many posts recently covering the why and how of React. This week's community round-up includes a collection of recent articles to help you get started with React, along with a few posts that explain some of the inner workings.
While we're talking about tree diffing: Matt Esch (@MatthewEsch) created this project, which aims to implement the virtual DOM and a corresponding diff algorithm as separate modules.
James Padosley wrote a short post on the basics (and merits) of React: What is React?
-
-
-
What I like most about React is that it doesn't impose heady design patterns and data-modelling abstractions on me. [...] Its opinions are so minimal and its abstractions so focused on the problem of the DOM, that you can merrily slap your design choices atop.
React expects you to do the work of getting and pushing data from the server. This makes it very easy to implement React as a front end solution, since it simply expects you to hand it data. React does all the other work.
Beginner tutorial: Implementing the board game Go #
-
Chris LaRose walks through the steps of creating a Go app in React, showing how to separate application logic from the rendered components. Check out his tutorial or go straight to the code.
"React: Finally, a great server/client web stack" #
-
Eric Florenzano (@ericflo) sheds some light on what makes React perfect for server rendering:
-
-
-
[...] the ideal solution would fully render the markup on the server, deliver it to the client so that it can be shown to the user instantly. Then it would asynchronously load some Javascript that would attach to the rendered markup, and invisibly promote the page into a full app that can render its own markup. [...]
-
-
What I've discovered is that enough of the pieces have come together, that this futuristic-sounding web environment is actually surprisingly easy to do now with React.js.
[#reactjs](https://twitter.com/search?q=%23reactjs&src=hash) has very simple API, but it's amazing how much work has been done under the hood to make it blazing fast.
[#reactjs]((https://twitter.com/search?q=%23reactjs&src=hash) makes refactoring your HTML as easy & natural as refactoring your javascript [@react_js](https://twitter.com/react_js)
There have been many posts recently covering the why and how of React. This week's community round-up includes a collection of recent articles to help you get started with React, along with a few posts that explain some of the inner workings.
While we're talking about tree diffing: Matt Esch (@MatthewEsch) created this project, which aims to implement the virtual DOM and a corresponding diff algorithm as separate modules.
James Padosley wrote a short post on the basics (and merits) of React: What is React?
+
+
+
What I like most about React is that it doesn't impose heady design patterns and data-modelling abstractions on me. [...] Its opinions are so minimal and its abstractions so focused on the problem of the DOM, that you can merrily slap your design choices atop.
React expects you to do the work of getting and pushing data from the server. This makes it very easy to implement React as a front end solution, since it simply expects you to hand it data. React does all the other work.
Beginner tutorial: Implementing the board game Go #
+
Chris LaRose walks through the steps of creating a Go app in React, showing how to separate application logic from the rendered components. Check out his tutorial or go straight to the code.
"React: Finally, a great server/client web stack" #
+
Eric Florenzano (@ericflo) sheds some light on what makes React perfect for server rendering:
+
+
+
[...] the ideal solution would fully render the markup on the server, deliver it to the client so that it can be shown to the user instantly. Then it would asynchronously load some Javascript that would attach to the rendered markup, and invisibly promote the page into a full app that can render its own markup. [...]
+
+
What I've discovered is that enough of the pieces have come together, that this futuristic-sounding web environment is actually surprisingly easy to do now with React.js.
[#reactjs](https://twitter.com/search?q=%23reactjs&src=hash) has very simple API, but it's amazing how much work has been done under the hood to make it blazing fast.
[#reactjs]((https://twitter.com/search?q=%23reactjs&src=hash) makes refactoring your HTML as easy & natural as refactoring your javascript [@react_js](https://twitter.com/react_js)
React got featured on the front-page of Hacker News thanks to the Om library. If you try it out for the first time, take a look at the docs and do not hesitate to ask questions on the Google Group, IRC or Stack Overflow. We are trying our best to help you out!
David Nolen announced Om, a thin wrapper on-top of React in ClojureScript. It stands out by only using immutable data structures. This unlocks the ability to write a very efficient shouldComponentUpdate and get huge performance improvements on some tasks.
-
-
-
We've known this for some time over here in the ClojureScript corner of the world - all of our collections are immutable and modeled directly on the original Clojure versions written in Java. Modern JavaScript engines have now been tuned to the point that it's no longer uncommon to see collection performance within 2.5X of the Java Virtual Machine.
-
-
Wait, wait, wait. What does the performance of persistent data structures have to do with the future of JavaScript MVCs?
Managing the scroll position when new content is inserted is usually very tricky to get right. Vjeux discovered that componentWillUpdate and componentDidUpdate were triggered exactly at the right time to manage the scroll position.
-
-
-
We can check the scroll position before the component has updated with componentWillUpdate and scroll if necessary at componentDidUpdate
React declarative approach is well suited to write games. Cheng Lou wrote the famous Lights Out game in React. It's a good example of use of TransitionGroup to implement animations.
-
Stoyan Stefanov wrote a bookmarklet to process tables on the internet. It adds a little "pop" button that expands to a full-screen view with sorting, editing and export to csv and json.
-
William Högman Rudenmalm wrote an article on how to write good React components. This is full of good advice.
-
-
-
The idea of dividing software into smaller parts or components is hardly new - It is the essance of good software. The same principles that apply to software in general apply to building React components. That doesn’t mean that writing good React components is just about applying general rules.
-
-
The web offers a unique set of challenges, which React offers interesting solutions to. First and foremost among these solutions is the what is called the Mock DOM. Rather than having user code interface with the DOM in a direct fashion, as is the case with most DOM manipulation libraries.
-
-
You build a model of how you want the DOM end up like. React then inserts this model into the DOM. This is very useful for updates because React simply compares the model or mock DOM against the actual DOM, and then only updates based on the difference between the two states.
React got featured on the front-page of Hacker News thanks to the Om library. If you try it out for the first time, take a look at the docs and do not hesitate to ask questions on the Google Group, IRC or Stack Overflow. We are trying our best to help you out!
David Nolen announced Om, a thin wrapper on-top of React in ClojureScript. It stands out by only using immutable data structures. This unlocks the ability to write a very efficient shouldComponentUpdate and get huge performance improvements on some tasks.
+
+
+
We've known this for some time over here in the ClojureScript corner of the world - all of our collections are immutable and modeled directly on the original Clojure versions written in Java. Modern JavaScript engines have now been tuned to the point that it's no longer uncommon to see collection performance within 2.5X of the Java Virtual Machine.
+
+
Wait, wait, wait. What does the performance of persistent data structures have to do with the future of JavaScript MVCs?
Managing the scroll position when new content is inserted is usually very tricky to get right. Vjeux discovered that componentWillUpdate and componentDidUpdate were triggered exactly at the right time to manage the scroll position.
+
+
+
We can check the scroll position before the component has updated with componentWillUpdate and scroll if necessary at componentDidUpdate
React declarative approach is well suited to write games. Cheng Lou wrote the famous Lights Out game in React. It's a good example of use of TransitionGroup to implement animations.
+
Stoyan Stefanov wrote a bookmarklet to process tables on the internet. It adds a little "pop" button that expands to a full-screen view with sorting, editing and export to csv and json.
+
William Högman Rudenmalm wrote an article on how to write good React components. This is full of good advice.
+
+
+
The idea of dividing software into smaller parts or components is hardly new - It is the essance of good software. The same principles that apply to software in general apply to building React components. That doesn’t mean that writing good React components is just about applying general rules.
+
+
The web offers a unique set of challenges, which React offers interesting solutions to. First and foremost among these solutions is the what is called the Mock DOM. Rather than having user code interface with the DOM in a direct fashion, as is the case with most DOM manipulation libraries.
+
+
You build a model of how you want the DOM end up like. React then inserts this model into the DOM. This is very useful for updates because React simply compares the model or mock DOM against the actual DOM, and then only updates based on the difference between the two states.
This release focuses on fixing some small bugs that have been uncovered over the past two weeks. I would like to thank everybody involved, specifically members of the community who fixed half of the issues found. Thanks to Ben Alpert, Andrey Popp, and Laurence Rowe for their contributions!
This release focuses on fixing some small bugs that have been uncovered over the past two weeks. I would like to thank everybody involved, specifically members of the community who fixed half of the issues found. Thanks to Ben Alpert, Andrey Popp, and Laurence Rowe for their contributions!
Today we're happy to announce the initial release of PyReact, which makes it easier to use React and JSX in your Python applications. It's designed to provide an API to transform your JSX files into JavaScript, as well as provide access to the latest React source files.
Transform your JSX files via the provided jsx module:
-
fromreactimportjsx
-
-# For multiple paths, use the JSXTransformer class.
-transformer=jsx.JSXTransformer()
-forjsx_path,js_pathinmy_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')
-
-
For full paths to React files, use the source module:
-
fromreactimportsource
-
-# path_for raises IOError if the file doesn't exist.
-react_js=source.path_for('react.min.js')
-
PyReact is hosted on PyPI, and can be installed with pip:
-
$ pip install PyReact
-
-
Alternatively, add it into your requirements file:
-
PyReact==0.1.1
-
-
Dependencies: PyReact uses PyExecJS to execute the bundled React code, which requires that a JS runtime environment is installed on your machine. We don't explicitly set a dependency on a runtime environment; Mac OS X comes bundled with one. If you're on a different platform, we recommend PyV8.
-
-
For the initial release, we've only tested on Python 2.7. Look out for support for Python 3 in the future, and if you see anything that can be improved, we welcome your contributions!
Today we're happy to announce the initial release of PyReact, which makes it easier to use React and JSX in your Python applications. It's designed to provide an API to transform your JSX files into JavaScript, as well as provide access to the latest React source files.
Transform your JSX files via the provided jsx module:
+
fromreactimportjsx
+
+# For multiple paths, use the JSXTransformer class.
+transformer=jsx.JSXTransformer()
+forjsx_path,js_pathinmy_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')
+
+
For full paths to React files, use the source module:
+
fromreactimportsource
+
+# path_for raises IOError if the file doesn't exist.
+react_js=source.path_for('react.min.js')
+
PyReact is hosted on PyPI, and can be installed with pip:
+
$ pip install PyReact
+
+
Alternatively, add it into your requirements file:
+
PyReact==0.1.1
+
+
Dependencies: PyReact uses PyExecJS to execute the bundled React code, which requires that a JS runtime environment is installed on your machine. We don't explicitly set a dependency on a runtime environment; Mac OS X comes bundled with one. If you're on a different platform, we recommend PyV8.
+
+
For the initial release, we've only tested on Python 2.7. Look out for support for Python 3 in the future, and if you see anything that can be improved, we welcome your contributions!
Over the past 2 months we've been taking feedback and working hard to make React even better. We fixed some bugs, made some under-the-hood improvements, and added several features that we think will improve the experience developing with React. Today we're proud to announce the availability of React v0.4!
-
-
This release could not have happened without the support of our growing community. Since launch day, the community has contributed blog posts, questions to the Google Group, and issues and pull requests on GitHub. We've had contributions ranging from documentation improvements to major changes to React's rendering. We've seen people integrate React into the tools they're using and the products they're building, and we're all very excited to see what our budding community builds next!
-
-
React v0.4 has some big changes. We've also restructured the documentation to better communicate how to use React. We've summarized the changes below and linked to documentation where we think it will be especially useful.
Switch from using id attribute to data-reactid to track DOM nodes. This allows you to integrate with other JS and CSS libraries more easily.
-
Support for more DOM elements and attributes (e.g., <canvas>)
-
Improved server-side rendering APIs. React.renderComponentToString(<component>, callback) allows you to use React on the server and generate markup which can be sent down to the browser.
Improvements to forms. We've written wrappers around <input>, <textarea>, <option>, and <select> in order to standardize many inconsistencies in browser implementations. This includes support for defaultValue, and improved implementation of the onChange event, and circuit completion. Read the docs for details...
-
We've implemented an improved synthetic event system that conforms to the W3C spec.
-
Updates to your component are batched now, which may result in a significantly faster re-render of components. this.setState now takes an optional callback as its second parameter. If you were using onClick={this.setState.bind(this, state)} previously, you'll want to make sure you add a third parameter so that the event is not treated as the callback.
Support for comment nodes <div>{/* this is a comment and won't be rendered */}</div>
-
Children are now transformed directly into arguments instead of being wrapped in an array
-E.g. <div><Component1/><Component2/></div> is transformed into React.DOM.div(null, Component1(null), Component2(null)).
-Previously this would be transformed into React.DOM.div(null, [Component1(null), Component2(null)]).
-If you were using React without JSX previously, your code should still work.
Over the past 2 months we've been taking feedback and working hard to make React even better. We fixed some bugs, made some under-the-hood improvements, and added several features that we think will improve the experience developing with React. Today we're proud to announce the availability of React v0.4!
+
+
This release could not have happened without the support of our growing community. Since launch day, the community has contributed blog posts, questions to the Google Group, and issues and pull requests on GitHub. We've had contributions ranging from documentation improvements to major changes to React's rendering. We've seen people integrate React into the tools they're using and the products they're building, and we're all very excited to see what our budding community builds next!
+
+
React v0.4 has some big changes. We've also restructured the documentation to better communicate how to use React. We've summarized the changes below and linked to documentation where we think it will be especially useful.
Switch from using id attribute to data-reactid to track DOM nodes. This allows you to integrate with other JS and CSS libraries more easily.
+
Support for more DOM elements and attributes (e.g., <canvas>)
+
Improved server-side rendering APIs. React.renderComponentToString(<component>, callback) allows you to use React on the server and generate markup which can be sent down to the browser.
Improvements to forms. We've written wrappers around <input>, <textarea>, <option>, and <select> in order to standardize many inconsistencies in browser implementations. This includes support for defaultValue, and improved implementation of the onChange event, and circuit completion. Read the docs for details...
+
We've implemented an improved synthetic event system that conforms to the W3C spec.
+
Updates to your component are batched now, which may result in a significantly faster re-render of components. this.setState now takes an optional callback as its second parameter. If you were using onClick={this.setState.bind(this, state)} previously, you'll want to make sure you add a third parameter so that the event is not treated as the callback.
Support for comment nodes <div>{/* this is a comment and won't be rendered */}</div>
+
Children are now transformed directly into arguments instead of being wrapped in an array
+E.g. <div><Component1/><Component2/></div> is transformed into React.DOM.div(null, Component1(null), Component2(null)).
+Previously this would be transformed into React.DOM.div(null, [Component1(null), Component2(null)]).
+If you were using React without JSX previously, your code should still work.
We have a ton of great stuff coming in v0.4, but in the meantime we're releasing v0.3.3. This release addresses some small issues people were having and simplifies our tools to make them easier to use.
Upgrade Commoner so require statements are no longer relativized when passing through the transformer. This was a feature needed when building React, but doesn't translate well for other consumers of bin/jsx.
-
Upgraded our dependencies on Commoner and Recast so they use a different directory for their cache.
Allow reusing the same DOM node to render different components. e.g. React.renderComponent(<div/>, domNode); React.renderComponent(<span/>, domNode); will work now.
Improved the in-browser transformer so that transformed scripts will execute in the expected scope. The allows components to be defined and used from separate files.
We have a ton of great stuff coming in v0.4, but in the meantime we're releasing v0.3.3. This release addresses some small issues people were having and simplifies our tools to make them easier to use.
Upgrade Commoner so require statements are no longer relativized when passing through the transformer. This was a feature needed when building React, but doesn't translate well for other consumers of bin/jsx.
+
Upgraded our dependencies on Commoner and Recast so they use a different directory for their cache.
Allow reusing the same DOM node to render different components. e.g. React.renderComponent(<div/>, domNode); React.renderComponent(<span/>, domNode); will work now.
Improved the in-browser transformer so that transformed scripts will execute in the expected scope. The allows components to be defined and used from separate files.
+
+
+
+
+
+
+
+
+
+
+
+
Community Round-up #2
diff --git a/blog/page2/index.html b/blog/page2/index.html
index 927b23531a..9c2fcb6026 100644
--- a/blog/page2/index.html
+++ b/blog/page2/index.html
@@ -66,6 +66,8 @@
At the React.js conference in late January 2015, we revealed our next major technology in the React family: Relay.
+
+
Relay is a new way of structuring client applications that co-locates data-fetching requirements and React components. Instead of placing data fetching logic in some other part of the client application – or embedding this logic in a custom endpoint on the server – we instead co-locate a declarative data-fetching specification alongside the React component. The language of this declarative specification is GraphQL.
+
+
GraphQL was not invented to enable Relay. In fact, GraphQL predates Relay by nearly three years. It was invented during the move from Facebook's HTML5-driven mobile applications to purely native applications. It is a query language for graph data that powers the lion's share of interactions in the Facebook Android and iOS applications. Any user of the native iOS or Android app in the last two years has used an app powered by GraphQL.
+
+
We plan to open-source a reference implementation of a GraphQL server and publish a language specification in the coming months. Our goal is to evolve GraphQL to adapt to a wide range of backends, so that projects and companies can use this technology to access their own data. We believe that this is a compelling way to structure servers and to provide powerful abstractions, frameworks and tools – including, but not exclusively, Relay – for product developers.
We will dig into the syntax and semantics of GraphQL in a later post, but even a simple example shows many of its design principles:
+
+
+
Hierarchical: Most product development today involves the creation and manipulation of view hierarchies. To achieve congruence with the structure of these applications, a GraphQL query itself is a hierarchical set of fields. The query is shaped just like the data it returns. It is a natural way for product engineers to describe data requirements.
+
Product-centric: GraphQL is unapologetically driven by the requirements of views and the front-end engineers that write them. We start with their way of thinking and requirements and build the language and runtime necessary to enable that.
+
Client-specified queries: In GraphQL, the specification for queries are encoded in the client rather than the server. These queries are specified at field-level granularity. In the vast majority of applications written without GraphQL, the server determines the data returned in its various scripted endpoints. A GraphQL query, on the other hand, returns exactly what a client asks for and no more.
+
Backwards Compatible: In a world of deployed native mobile applications with no forced upgrades, backwards compatibility is a challenge. Facebook, for example, releases apps on a two week fixed cycle and pledges to maintain those apps for at least two years. This means there are at a minimum 52 versions of our clients per platform querying our servers at any given time. Client-specified queries simplifies managing our backwards compatibility guarantees.
+
Structured, Arbitrary Code: Query languages with field-level granularity have typically queried storage engines directly, such as SQL. GraphQL instead imposes a structure onto a server, and exposes fields that are backed by arbitrary code. This allows for both server-side flexibility and a uniform, powerful API across the entire surface area of an application.
+
Application-Layer Protocol: GraphQL is an application-layer protocol and does not require a particular transport. It is a string that is parsed and interpreted by a server.
+
Strongly-typed: GraphQL is strongly-typed. Given a query, tooling can ensure that the query is both syntactically correct and valid within the GraphQL type system before execution, i.e. at development time, and the server can make certain guarantees about the shape and nature of the response. This makes it easier to build high quality client tools.
+
Introspective: GraphQL is introspective. Clients and tools can query the type system using the GraphQL syntax itself. This is a powerful platform for building tools and client software, such as automatic parsing of incoming data into strongly-typed interfaces. It is especially useful in statically typed languages such as Swift, Objective-C and Java, as it obviates the need for repetitive and error-prone code to shuffle raw, untyped JSON into strongly-typed business objects.
Obviously GraphQL is not the first system to manage client-server interactions. In today's world there are two dominant architectural styles for client-server interaction: REST and ad hoc endpoints.
REST an acronym for Representational State Transfer, which is an architectural style rather than a formal protocol. There is actually much debate about what exactly REST is and is not. We wish to avoid such debates. We are interested in the typical attributes of systems that self-identify as REST, rather than systems which are formally REST.
+
+
Objects in a typical REST system are addressable by URI and interacted with using verbs in the HTTP protocol. An HTTP GET to a particular URI fetches an object and returns a server-specified set of fields. An HTTP PUT edits an object; an HTTP DELETE deletes an object; and so on.
+
+
We believe there are a number of weakness in typical REST systems, ones that are particularly problematic in mobile applications:
+
+
+
Fetching complicated object graphs require multiple round trips between the client and server to render single views. For mobile applications operating in variable network conditions, these multiple roundtrips are highly undesirable.
+
Invariably fields and additional data are added to REST endpoints as the system requirements change. However, old clients also receive this additional data as well, because the data fetching specification is encoded on the server rather than the client. As result, these payloads tend to grow over time for all clients. When this becomes a problem for a system, one solution is to overlay a versioning system onto the REST endpoints. Versioning also complicates a server, and results in code duplication, spaghetti code, or a sophisticated, hand-rolled infrastructure to manage it. Another solution to limit over-fetching is to provide multiple views – such as “compact” vs “full” – of the same REST endpoint, however this coarse granularity often does not offer adequate flexibility.
+
REST endpoints are usually weakly-typed and lack machine-readable metadata. While there is much debate about the merits of strong- versus weak-typing in distributed systems, we believe in strong typing because of the correctness guarantees and tooling opportunities it provides. Developer deal with systems that lack this metadata by inspecting frequently out-of-date documentation and then writing code against the documentation.
+
Many of these attributes are linked to the fact that “REST is intended for long-lived network-based applications that span multiple organizations” according to its inventor. This is not a requirement for APIs that serve a client app built within the same organization.
+
+
+
Nearly all externally facing REST APIs we know of trend or end up in these non-ideal states, as well as nearly all internal REST APIs. The consequences of opaqueness and over-fetching are more severe in internal APIs since their velocity of change and level of usage is almost always higher.
+
+
Because of multiple round-trips and over-fetching, applications built in the REST style inevitably end up building ad hoc endpoints that are superficially in the REST style. These actually couple the data to a particular view which explicitly violates one of REST's major goals. Most REST systems of any complexity end up as a continuum of endpoints that span from “traditional” REST to ad hoc endpoints.
Many applications have no formalized client-server contract. Product developers access server capabilities through ad hoc endpoints and write custom code to fetch the data they need. Servers define procedures, and they return data. This approach has the virtue of simplicity, but can often become untenable as systems age.
+
+
+
These systems typically define a custom endpoint per view. For systems with a wide surface area this can quickly grow into a maintenance nightmare of orphaned endpoints, inconsistent tooling, and massive server code duplication. Disciplined engineering organizations can mitigate these issues with great engineering practices, high quality abstractions, and custom tooling. However, given our experience we believe that custom endpoints tend to lead to entropic server codebases.
+
Much like REST, the payloads of custom endpoints grow monotonically (even with mitigation from versioning systems) as the server evolves. Deployed clients cannot break, and, with rapid release cycles and backwards compatibility guarantees, distributed applications will have large numbers of extant versions. Under these constraints it is difficult remove data from a custom endpoint.
+
Custom endpoints tend to – for a client developer – create a clunky, multi-language, multi-environment development process. No matter if the data has been accessed before in a different view, they are required to first change the custom endpoint, then deploy that code to a server accessible from a mobile device, and only then change the client to utilize that data. In GraphQL – unless the data in the view is completely new to the entire system – a product developer adds a field to a GraphQL query and the work on the client continues unabated.
+
Much like REST, most systems with custom endpoints do not have a formalized type system, which eliminates the possibility for the tools and guarantees that introspective type systems can provide. Some custom-endpoint-driven systems do use a strongly typed serialization scheme, such as Protocol Buffers, Thrift, or XML. Those do allow for direct parsing of responses into typed classes and eliminating boilerplate shuffling from JSON into handwritten classes. These systems are as not as expressive and flexible as GraphQL, and the other downsides of ad hoc endpoints remain.
+
+
+
We believe that GraphQL represents a novel way of structuring the client-server contract. Servers publish a type system specific to their application, and GraphQL provides a unified language to query data within the constraints of that type system. That language allows product developers to express data requirements in a form natural to them: a declarative and hierarchal one.
+
+
This is a liberating platform for product developers. With GraphQL, no more contending with ad hoc endpoints or object retrieval with multiple roundtrips to access server data; instead an elegant, hierarchical, declarative query dispatched to a single endpoint. No more frequent jumps between client and server development environments to do experimentation or to change or create views of existing data; instead experiments are done and new views built within a native, client development environment exclusively. No more shuffling unstructured data from ad hoc endpoints into business objects; instead a powerful, introspective type system that serves as a platform for tool building.
+
+
Product developers are free to focus on their client software and requirements while rarely leaving their development environment; they can more confidently support shipped clients as a system evolves; and they are using a protocol designed to operate well within the constraints of mobile applications. Product developers can query for exactly what they want, in the way they think about it, across their entire application's data model.
Over the coming months, we will share more technical details about GraphQL, including additional language features, tools that support it, and how it is built and used at Facebook. These posts will culminate in a formal specification of GraphQL to guide implementors across various languages and platforms. We also plan on releasing a reference implementation in the summer, in order to provide a basis for custom deployments and a platform for experimentation. We're incredibly excited to share this system and work with the open source community to improve it.
At React.js Conf in January we gave a preview of Relay, a new framework for building data-driven applications in React. In this post, we'll describe the process of creating a Relay application. This post assumes some familiarity with the concepts of Relay and GraphQL, so if you haven't already we recommend reading our introductory blog post or watching the conference talk.
-
-
We're working hard to prepare GraphQL and Relay for public release. In the meantime, we'll continue to provide information about what you can expect.
The diagram below shows the main parts of the Relay architecture on the client and the server:
-
-
-
-
The main pieces are as follows:
-
-
-
Relay Components: React components annotated with declarative data descriptions.
-
Actions: Descriptions of how data should change in response to user actions.
-
Relay Store: A client-side data store that is fully managed by the framework.
-
Server: An HTTP server with GraphQL endpoints (one for reads, one for writes) that respond to GraphQL queries.
-
-
-
This post will focus on Relay components that describe encapsulated units of UI and their data dependencies. These components form the majority of a Relay application.
To see how components work and can be composed, let's implement a basic version of the Facebook News Feed in Relay. Our application will have two components: a <NewsFeed> that renders a list of <Story> items. We'll introduce the plain React version of each component first and then convert it to a Relay component. The goal is something like the following:
The first step is a React <Story> component that accepts a story prop with the story's text and author information. Note that all examples uses ES6 syntax and elide presentation details to focus on the pattern of data access.
Before adding the GraphQL query, let's look at the component hierarchy this creates:
-
-
-
-
Most props will be passed through from the container to the original component. However, Relay will return the query results for a prop whenever a query is defined. In this case we'll add a GraphQL query for story:
Queries use ES6 template literals tagged with the graphql function. Similar to how JSX transpiles to plain JavaScript objects and function calls, these template literals transpile to plain objects that describe queries. Note that the query's structure closely matches the object structure that we expected in <Story>'s render function.
We can render a Relay component by providing Relay with the component (<Story>) and the ID of the data (a story ID). Given this information, Relay will first fetch the results of the query and then render() the component. The value of props.story will be a plain JavaScript object such as the following:
-
{
- author:{
- name:"Greg",
- profile_picture:{
- uri:"https://…"
- }
- },
- text:"The first Relay blog post is up…"
-}
-
-
Relay guarantees that all data required to render a component will be available before it is rendered. This means that <Story> does not need to handle a loading state; the story is guaranteed to be available before render() is called. We have found that this invariant simplifies our application code and improves the user experience. Of course, Relay also has options to delay the fetching of some parts of our queries.
-
-
The diagram below shows how Relay containers make data available to our React components:
<NewsFeed> has two new requirements: it composes <Story> and requests more data at runtime.
-
-
Just as React views can be nested, Relay queries can compose queries from child components. Composition in GraphQL uses ES6 template literal substitution: ${Component.getQuery('prop')}. Pagination can be accomplished with a query parameter, specified with <param> (as in stories(first: <count>)):
Whenever <NewsFeed> is rendered, Relay will recursively expand all the composed queries and fetch them in a single trip to the server. In this case, the text and author data will be fetched for each of the 3 story nodes.
-
-
Query parameters are available to components as props.queryParams and can be modified with props.setQueryParams(nextParams). We can use these to implement pagination:
Now when loadMore() is called, Relay will send a GraphQL request for the additional five stories. When these stories are fetched, the component will re-render with the new stories available in props.viewer.stories and the updated count reflected in props.queryParams.count.
These two components form a solid core for our application. With the use of Relay containers and GraphQL queries, we've enabled the following benefits:
-
-
-
Automatic and efficient pre-fetching of data for an entire view hierarchy in a single network request.
-
Trivial pagination with automatic optimizations to fetch only the additional items.
-
View composition and reusability, so that <Story> can be used on its own or within <NewsFeed>, without any changes to either component.
-
Automatic subscriptions, so that components will re-render if their data changes. Unaffected components will not re-render unnecessarily.
-
Exactly zero lines of imperative data fetching logic. Relay takes full advantage of React's declarative component model.
-
-
-
But Relay has many more tricks up its sleeve. For example, it's built from the start to handle reads and writes, allowing for features like optimistic client updates with transactional rollback. Relay can also defer fetching select parts of queries, and it uses a local data store to avoid fetching the same data twice. These are all powerful features that we hope to explore in future posts.
At React.js Conf in January we gave a preview of Relay, a new framework for building data-driven applications in React. In this post, we'll describe the process of creating a Relay application. This post assumes some familiarity with the concepts of Relay and GraphQL, so if you haven't already we recommend reading our introductory blog post or watching the conference talk.
+
+
We're working hard to prepare GraphQL and Relay for public release. In the meantime, we'll continue to provide information about what you can expect.
The diagram below shows the main parts of the Relay architecture on the client and the server:
+
+
+
+
The main pieces are as follows:
+
+
+
Relay Components: React components annotated with declarative data descriptions.
+
Actions: Descriptions of how data should change in response to user actions.
+
Relay Store: A client-side data store that is fully managed by the framework.
+
Server: An HTTP server with GraphQL endpoints (one for reads, one for writes) that respond to GraphQL queries.
+
+
+
This post will focus on Relay components that describe encapsulated units of UI and their data dependencies. These components form the majority of a Relay application.
To see how components work and can be composed, let's implement a basic version of the Facebook News Feed in Relay. Our application will have two components: a <NewsFeed> that renders a list of <Story> items. We'll introduce the plain React version of each component first and then convert it to a Relay component. The goal is something like the following:
The first step is a React <Story> component that accepts a story prop with the story's text and author information. Note that all examples uses ES6 syntax and elide presentation details to focus on the pattern of data access.
Before adding the GraphQL query, let's look at the component hierarchy this creates:
+
+
+
+
Most props will be passed through from the container to the original component. However, Relay will return the query results for a prop whenever a query is defined. In this case we'll add a GraphQL query for story:
Queries use ES6 template literals tagged with the graphql function. Similar to how JSX transpiles to plain JavaScript objects and function calls, these template literals transpile to plain objects that describe queries. Note that the query's structure closely matches the object structure that we expected in <Story>'s render function.
We can render a Relay component by providing Relay with the component (<Story>) and the ID of the data (a story ID). Given this information, Relay will first fetch the results of the query and then render() the component. The value of props.story will be a plain JavaScript object such as the following:
+
{
+ author:{
+ name:"Greg",
+ profile_picture:{
+ uri:"https://…"
+ }
+ },
+ text:"The first Relay blog post is up…"
+}
+
+
Relay guarantees that all data required to render a component will be available before it is rendered. This means that <Story> does not need to handle a loading state; the story is guaranteed to be available before render() is called. We have found that this invariant simplifies our application code and improves the user experience. Of course, Relay also has options to delay the fetching of some parts of our queries.
+
+
The diagram below shows how Relay containers make data available to our React components:
<NewsFeed> has two new requirements: it composes <Story> and requests more data at runtime.
+
+
Just as React views can be nested, Relay queries can compose queries from child components. Composition in GraphQL uses ES6 template literal substitution: ${Component.getQuery('prop')}. Pagination can be accomplished with a query parameter, specified with <param> (as in stories(first: <count>)):
Whenever <NewsFeed> is rendered, Relay will recursively expand all the composed queries and fetch them in a single trip to the server. In this case, the text and author data will be fetched for each of the 3 story nodes.
+
+
Query parameters are available to components as props.queryParams and can be modified with props.setQueryParams(nextParams). We can use these to implement pagination:
Now when loadMore() is called, Relay will send a GraphQL request for the additional five stories. When these stories are fetched, the component will re-render with the new stories available in props.viewer.stories and the updated count reflected in props.queryParams.count.
These two components form a solid core for our application. With the use of Relay containers and GraphQL queries, we've enabled the following benefits:
+
+
+
Automatic and efficient pre-fetching of data for an entire view hierarchy in a single network request.
+
Trivial pagination with automatic optimizations to fetch only the additional items.
+
View composition and reusability, so that <Story> can be used on its own or within <NewsFeed>, without any changes to either component.
+
Automatic subscriptions, so that components will re-render if their data changes. Unaffected components will not re-render unnecessarily.
+
Exactly zero lines of imperative data fetching logic. Relay takes full advantage of React's declarative component model.
+
+
+
But Relay has many more tricks up its sleeve. For example, it's built from the start to handle reads and writes, allowing for features like optimistic client updates with transactional rollback. Relay can also defer fetching select parts of queries, and it uses a local data store to avoid fetching the same data twice. These are all powerful features that we hope to explore in future posts.
Over the weekend we pushed out our first (and hopefully only) release candidate for React v0.13!
-
-
We've talked a little bit about the changes that are coming. The splashiest of these changes is support for ES6 Classes. You can read more about this in our beta announcement. We're really excited about this! Sebastian also posted earlier this morning about some of the other changes coming focused around ReactElement. The changes we've been working on there will hopefully enable lots of improvements to performance and developer experience.
Mutating props after an element is created is deprecated and will cause warnings in development mode; future versions of React will incorporate performance optimizations assuming that props aren't mutated
-
Static methods (defined in statics) are no longer autobound to the component class
-
ref resolution order has changed slightly such that a ref to a component is available immediately after its componentDidMount method is called; this change should be observable only if your component calls a parent component's callback within your componentDidMount, which is an anti-pattern and should be avoided regardless
-
Calls to setState in life-cycle methods are now always batched and therefore asynchronous. Previously the first call on the first mount was synchronous.
-
setState and forceUpdate on an unmounted component now warns instead of throwing. That avoids a possible race condition with Promises.
-
Access to most internal properties has been completely removed, including this._pendingState and this._rootNodeID.
Support for using ES6 classes to build React components; see the v0.13.0 beta 1 notes for details
-
Added new top-level API React.findDOMNode(component), which should be used in place of component.getDOMNode(). The base class for ES6-based components will not have getDOMNode. This change will enable some more patterns moving forward.
-
New ref style, allowing a callback to be used in place of a name: <Photo ref={(c) => this._photo = c} /> allows you to reference the component with this._photo (as opposed to ref="photo" which gives this.refs.photo)
-
this.setState() can now take a function as the first argument for transactional state updates, such as this.setState((state, props) => ({count: state.count + 1})); -- this means that you no longer need to use this._pendingState, which is now gone.
-
Support for iterators and immutable-js sequences as children
ComponentClass.type is deprecated. Just use ComponentClass (usually as element.type === ComponentClass)
-
Some methods that are available on createClass-based components are removed or deprecated from ES6 classes (for example, getDOMNode, setProps, replaceState).
When transforming ES6 syntax, class methods are no longer enumerable by default, which requires Object.defineProperty; if you support browsers such as IE8, you can pass --target es3 to mirror the old behavior
--target option is available on the jsx command, allowing users to specify and ECMAScript version to target.
-
-
-
es5 is the default.
-
es3 restored the previous default behavior. An additional transform is added here to ensure the use of reserved words as properties is safe (eg this.static will become this['static'] for IE8 compatibility).
-
-
The transform for the call spread operator has also been enabled.
A change was made to how some JSX was parsed, specifically around the use of > or } when inside an element. Previously it would be treated as a string but now it will be treated as a parse error. We will be releasing a standalone executable to find and fix potential issues in your JSX code.
Over the weekend we pushed out our first (and hopefully only) release candidate for React v0.13!
+
+
We've talked a little bit about the changes that are coming. The splashiest of these changes is support for ES6 Classes. You can read more about this in our beta announcement. We're really excited about this! Sebastian also posted earlier this morning about some of the other changes coming focused around ReactElement. The changes we've been working on there will hopefully enable lots of improvements to performance and developer experience.
Mutating props after an element is created is deprecated and will cause warnings in development mode; future versions of React will incorporate performance optimizations assuming that props aren't mutated
+
Static methods (defined in statics) are no longer autobound to the component class
+
ref resolution order has changed slightly such that a ref to a component is available immediately after its componentDidMount method is called; this change should be observable only if your component calls a parent component's callback within your componentDidMount, which is an anti-pattern and should be avoided regardless
+
Calls to setState in life-cycle methods are now always batched and therefore asynchronous. Previously the first call on the first mount was synchronous.
+
setState and forceUpdate on an unmounted component now warns instead of throwing. That avoids a possible race condition with Promises.
+
Access to most internal properties has been completely removed, including this._pendingState and this._rootNodeID.
Support for using ES6 classes to build React components; see the v0.13.0 beta 1 notes for details
+
Added new top-level API React.findDOMNode(component), which should be used in place of component.getDOMNode(). The base class for ES6-based components will not have getDOMNode. This change will enable some more patterns moving forward.
+
New ref style, allowing a callback to be used in place of a name: <Photo ref={(c) => this._photo = c} /> allows you to reference the component with this._photo (as opposed to ref="photo" which gives this.refs.photo)
+
this.setState() can now take a function as the first argument for transactional state updates, such as this.setState((state, props) => ({count: state.count + 1})); -- this means that you no longer need to use this._pendingState, which is now gone.
+
Support for iterators and immutable-js sequences as children
ComponentClass.type is deprecated. Just use ComponentClass (usually as element.type === ComponentClass)
+
Some methods that are available on createClass-based components are removed or deprecated from ES6 classes (for example, getDOMNode, setProps, replaceState).
When transforming ES6 syntax, class methods are no longer enumerable by default, which requires Object.defineProperty; if you support browsers such as IE8, you can pass --target es3 to mirror the old behavior
--target option is available on the jsx command, allowing users to specify and ECMAScript version to target.
+
+
+
es5 is the default.
+
es3 restored the previous default behavior. An additional transform is added here to ensure the use of reserved words as properties is safe (eg this.static will become this['static'] for IE8 compatibility).
+
+
The transform for the call spread operator has also been enabled.
A change was made to how some JSX was parsed, specifically around the use of > or } when inside an element. Previously it would be treated as a string but now it will be treated as a parse error. We will be releasing a standalone executable to find and fix potential issues in your JSX code.
Today I'm really happy to announce the React.js Conf Diversity Scholarship! We believe that a diverse set of viewpoints and opinions is really important to build a thriving community. In an ideal world, every part of the tech community would be made up of people from all walks of life. However the reality is that we must be proactive and make an effort to make sure everybody has a voice. As conference organizers we worked closely with the Diversity Team here at Facebook to set aside 10 tickets and provide a scholarship. 10 tickets may not be many in the grand scheme but we really believe that this will have a positive impact on the discussions we have at the conference.
-
-
I'm really excited about this and I hope you are too! The full announcement is below:
-
-
-
-
The Diversity Team at Facebook is excited to announce that we are now accepting applications for the React.js Conf scholarship!
-
-
Beginning today, those studying or working in computer science or a related field can apply for an all-expense paid scholarship to attend the React.js Conf at Facebook’s Headquarters in Menlo Park, CA on January 28 & 29, 2015. React opens a world of new possibilities such as server-side rendering, real-time updates, different rendering targets like SVG and canvas. Join us at React.js Conf to shape the future of client-side applications! For more information about the React.js conference, please see the website and previousupdates on our blog.
-
-
At Facebook, we believe that anyone anywhere can make a positive impact by developing products to make the world more open and connected to the people and things they care about. Given the current realities of the tech industry and the lack of representation of communities we seek to serve, applicants currently under-represented in Computer Science and related fields are strongly encouraged to apply.
-Facebook will make determinations on scholarship recipients in its sole discretion. Facebook complies with all equal opportunity laws.
Today I'm really happy to announce the React.js Conf Diversity Scholarship! We believe that a diverse set of viewpoints and opinions is really important to build a thriving community. In an ideal world, every part of the tech community would be made up of people from all walks of life. However the reality is that we must be proactive and make an effort to make sure everybody has a voice. As conference organizers we worked closely with the Diversity Team here at Facebook to set aside 10 tickets and provide a scholarship. 10 tickets may not be many in the grand scheme but we really believe that this will have a positive impact on the discussions we have at the conference.
+
+
I'm really excited about this and I hope you are too! The full announcement is below:
+
+
+
+
The Diversity Team at Facebook is excited to announce that we are now accepting applications for the React.js Conf scholarship!
+
+
Beginning today, those studying or working in computer science or a related field can apply for an all-expense paid scholarship to attend the React.js Conf at Facebook’s Headquarters in Menlo Park, CA on January 28 & 29, 2015. React opens a world of new possibilities such as server-side rendering, real-time updates, different rendering targets like SVG and canvas. Join us at React.js Conf to shape the future of client-side applications! For more information about the React.js conference, please see the website and previousupdates on our blog.
+
+
At Facebook, we believe that anyone anywhere can make a positive impact by developing products to make the world more open and connected to the people and things they care about. Given the current realities of the tech industry and the lack of representation of communities we seek to serve, applicants currently under-represented in Computer Science and related fields are strongly encouraged to apply.
+Facebook will make determinations on scholarship recipients in its sole discretion. Facebook complies with all equal opportunity laws.
Every few weeks someone asks us when we are going to organize a conference for React. Our answer has always been "some day". In the mean time, people have been talking about React at other JavaScript conferences around the world. But now the time has finally come for us to have a conference of our own.
-
-
We're happy to announce React.js Conf! It will take place January 28-29, 2015 on Facebook's campus in Menlo Park, California.
-
-
Before we open registration, we're looking for great talks. We want to see how you pushed application development forward! If you ever talked to a meet-up, pitched React to your co-workers, or done something awesome and want to talk about it, let us know!
-
-
Here are some areas of research we want to explore during the conference if you need some inspiration: server-side rendering, data fetching, language features (eg es6, clojure), immutability, rendering targets (eg svg, canvas), real-time updates...
-
-
We look forward to seeing many of you in person in just a few short months!
Every few weeks someone asks us when we are going to organize a conference for React. Our answer has always been "some day". In the mean time, people have been talking about React at other JavaScript conferences around the world. But now the time has finally come for us to have a conference of our own.
+
+
We're happy to announce React.js Conf! It will take place January 28-29, 2015 on Facebook's campus in Menlo Park, California.
+
+
Before we open registration, we're looking for great talks. We want to see how you pushed application development forward! If you ever talked to a meet-up, pitched React to your co-workers, or done something awesome and want to talk about it, let us know!
+
+
Here are some areas of research we want to explore during the conference if you need some inspiration: server-side rendering, data fetching, language features (eg es6, clojure), immutability, rendering targets (eg svg, canvas), real-time updates...
+
+
We look forward to seeing many of you in person in just a few short months!
Today we're releasing React v0.11.2 to add a few small features.
-
-
We're adding support for two more DOM elements, <dialog> and <picture>, as well as the associated attributes needed to use these elements: open, media, and sizes. While not all browsers support these natively, some of our cutting edge users want to make use of them, so we're making them available to everybody.
-
-
We're also doing some work to prepare for v0.12 and improve compatibility between the versions. To do this we are replacing React.createDescriptor with React.createElement. createDescriptor will continue to work with a warning and will be gone in v0.12. Chances are that this won't affect anybody.
-
-
And lastly, on the heels of announcing Flow at @Scale yesterday, we're adding the ability to strip TypeScript-like type annotations as part of the jsx transform. To use, simply use the --strip-types flag on the command line, or set stripTypes in the options object when calling the API. We'll be talking about Flow more in the coming months. But for now, it's helpful to know that it is a flow-sensitive JavaScript type checker we will be open sourcing soon.
-
-
The release is available for download from the CDN:
Today we're releasing React v0.11.2 to add a few small features.
+
+
We're adding support for two more DOM elements, <dialog> and <picture>, as well as the associated attributes needed to use these elements: open, media, and sizes. While not all browsers support these natively, some of our cutting edge users want to make use of them, so we're making them available to everybody.
+
+
We're also doing some work to prepare for v0.12 and improve compatibility between the versions. To do this we are replacing React.createDescriptor with React.createElement. createDescriptor will continue to work with a warning and will be gone in v0.12. Chances are that this won't affect anybody.
+
+
And lastly, on the heels of announcing Flow at @Scale yesterday, we're adding the ability to strip TypeScript-like type annotations as part of the jsx transform. To use, simply use the --strip-types flag on the command line, or set stripTypes in the options object when calling the API. We'll be talking about Flow more in the coming months. But for now, it's helpful to know that it is a flow-sensitive JavaScript type checker we will be open sourcing soon.
+
+
The release is available for download from the CDN:
Atom, GitHub's code editor, is now using React to build the editing experience. They made the move in order to improve performance. By default, React helped them eliminate unnecessary reflows, enabling them to focus on architecting the rendering pipeline in order to minimize repaints by using hardware acceleration. This is a testament to the fact that React's architecture is perfect for high performant applications.
At the last JSConf.us, Vjeux talked about the design decisions made in the API that allows it to scale to a large number of developers. If you don't have 20 minutes, take a look at the annotated slides.
One of the best features of React is that it provides the foundations to implement concepts that were otherwise extremely difficult, like server-side rendering, undo-redo, rendering to non-DOM environments like canvas... Dan Abramov got hot code reloading working with webpack in order to live edit a React project!
There are a couple of React-related projects that recently appeared on Yahoo's GitHub, the first one being an internationalization mixin. It's great to see them getting excited about React and contributing back to the community.
Josephine Hall, working at Icelab, used React to write a mobile-focused application. She wrote a blog post “Thinking and Learning React.js” to share her experience with elements they had to use. You'll learn about routing, event dispatch, touchable components, and basic animations.
One of the strengths of React is that it plays nicely with other libraries. Jim Cowart proved it by writing a tutorial that explains how to write React component adapters for KendoUI.
Ingvar Stepanyan extended the Acorn JavaScript parser to support JSX. The result is a JSX parser that's 1.5–2.0x faster than the official JSX implementation. It is an experiment and is not meant to be used for serious things, but it's always a good thing to get competition on performance!
Atom, GitHub's code editor, is now using React to build the editing experience. They made the move in order to improve performance. By default, React helped them eliminate unnecessary reflows, enabling them to focus on architecting the rendering pipeline in order to minimize repaints by using hardware acceleration. This is a testament to the fact that React's architecture is perfect for high performant applications.
At the last JSConf.us, Vjeux talked about the design decisions made in the API that allows it to scale to a large number of developers. If you don't have 20 minutes, take a look at the annotated slides.
One of the best features of React is that it provides the foundations to implement concepts that were otherwise extremely difficult, like server-side rendering, undo-redo, rendering to non-DOM environments like canvas... Dan Abramov got hot code reloading working with webpack in order to live edit a React project!
There are a couple of React-related projects that recently appeared on Yahoo's GitHub, the first one being an internationalization mixin. It's great to see them getting excited about React and contributing back to the community.
Josephine Hall, working at Icelab, used React to write a mobile-focused application. She wrote a blog post “Thinking and Learning React.js” to share her experience with elements they had to use. You'll learn about routing, event dispatch, touchable components, and basic animations.
One of the strengths of React is that it plays nicely with other libraries. Jim Cowart proved it by writing a tutorial that explains how to write React component adapters for KendoUI.
Ingvar Stepanyan extended the Acorn JavaScript parser to support JSX. The result is a JSX parser that's 1.5–2.0x faster than the official JSX implementation. It is an experiment and is not meant to be used for serious things, but it's always a good thing to get competition on performance!
Today marks the one-year open-source anniversary of React.
-
-
It’s been a crazy ride. 2.3k commits and 1.5k issues and pull requests later, we’re approaching version 1.0 and nearing 7k Github stars, with big names such as Khan Academy, New York Times, and Airbnb (and naturally, Facebook and Instagram) using React in production, and many more developers blogging their success stories with it. The roadmap gives a glimpse into the future of the library; exciting stuff lies ahead!
-
-
Every success has its story. React was born out of our frustration at existing solutions for building UIs. When it was first suggested at Facebook, few people thought that functionally re-rendering everything and diffing the results could ever perform well. However, support grew after we built the first implementation and people wrote their first components. When we open-sourced React, the initial reception was similarly skeptical. It challenges many pre-established conventions and received mostly disapproving first-impressions, intermingled with positive ones that often were votes of confidence in Facebook’s engineering capabilities. On an open, competitive platform such as the web, it's been hard to convince people to try React. JSX, in particular, filtered out a huge chunk of potential early adopters.
-
-
Fast forward one year, React has strongly grown in popularity. Special acknowledgments go to Khan Academy, the ClojureScript community, and established frameworks such as Ember and Angular for contributing to and debating on our work. We'd also like to thank all the individual contributors who have taken the time to help out over the past year. React, as a library and as a new paradigm on the web, wouldn't have gained as much traction without them. In the future, we will continue to try to set an example of what's possible to achieve when we rethink about current “best practices”.
Today marks the one-year open-source anniversary of React.
+
+
It’s been a crazy ride. 2.3k commits and 1.5k issues and pull requests later, we’re approaching version 1.0 and nearing 7k Github stars, with big names such as Khan Academy, New York Times, and Airbnb (and naturally, Facebook and Instagram) using React in production, and many more developers blogging their success stories with it. The roadmap gives a glimpse into the future of the library; exciting stuff lies ahead!
+
+
Every success has its story. React was born out of our frustration at existing solutions for building UIs. When it was first suggested at Facebook, few people thought that functionally re-rendering everything and diffing the results could ever perform well. However, support grew after we built the first implementation and people wrote their first components. When we open-sourced React, the initial reception was similarly skeptical. It challenges many pre-established conventions and received mostly disapproving first-impressions, intermingled with positive ones that often were votes of confidence in Facebook’s engineering capabilities. On an open, competitive platform such as the web, it's been hard to convince people to try React. JSX, in particular, filtered out a huge chunk of potential early adopters.
+
+
Fast forward one year, React has strongly grown in popularity. Special acknowledgments go to Khan Academy, the ClojureScript community, and established frameworks such as Ember and Angular for contributing to and debating on our work. We'd also like to thank all the individual contributors who have taken the time to help out over the past year. React, as a library and as a new paradigm on the web, wouldn't have gained as much traction without them. In the future, we will continue to try to set an example of what's possible to achieve when we rethink about current “best practices”.
v0.9 has only been out for a month, but we’re getting ready to push out v0.10 already. Unlike v0.9 which took a long time, we don't have a long list of changes to talk about.
-
-
The release candidate is available for download from the CDN:
The main purpose of this release is to provide a smooth upgrade path as we evolve some of the implementation of core. In v0.9 we started warning in cases where you called methods on unmounted components. This is part of an effort to enforce the idea that the return value of a component (React.DOM.div(), MyComponent()) is in fact not a reference to the component instance React uses in the virtual DOM. The return value is instead a light-weight object that React knows how to use. Since the return value currently is a reference to the same object React uses internally, we need to make this transition in stages as many people have come to depend on this implementation detail.
-
-
In 0.10, we’re adding more warnings to catch a similar set of patterns. When a component is mounted we clone it and use that object for our internal representation. This allows us to capture calls you think you’re making to a mounted component. We’ll forward them on to the right object, but also warn you that this is breaking. See “Access to the Mounted Instance” on this page. Most of the time you can solve your pattern by using refs.
-
-
Storing a reference to your top level component is a pattern touched upon on that page, but another examples that demonstrates what we see a lot of:
-
// This is a common pattern. However instance here really refers to a
-// "descriptor", not necessarily the mounted instance.
-varinstance=<MyComponent/>;
-React.renderComponent(instance);
-// ...
-instance.setProps(...);
-
-// The change here is very simple. The return value of renderComponent will be
-// the mounted instance.
-varinstance=React.renderComponent(<MyComponent/>)
-// ...
-instance.setProps(...);
-
-
These warnings and method forwarding are only enabled in the development build. The production builds continue to work as they did in v0.9. We strongly encourage you to use the development builds to catch these warnings and fix the call sites.
-
-
The plan for v0.11 is that we will go fully to "descriptors". Method calls on the return value of MyComponent() will fail hard.
Added an option argument to transform function. The only option supported is harmony, which behaves the same as jsx --harmony on the command line. This uses the ES6 transforms from jstransform.
-
-
-
-
-
-
diff --git a/css/react.css b/css/react.css
index b4427206bf..eca069973b 100644
--- a/css/react.css
+++ b/css/react.css
@@ -1 +1 @@
-html{font-family:"Helvetica Neue",Helvetica,Roboto,Arial,sans-serif;font-family:proxima-nova,"Helvetica Neue",Helvetica,Roboto,Arial,sans-serif;color:#484848;line-height:1.28}p{margin:0 0 10px}.subHeader{font-size:21px;font-weight:200;line-height:30px;margin-bottom:10px}em{font-style:italic}h1,h2,h3,h4,h5,h6{margin:10px 0;font-family:inherit;font-weight:bold;line-height:20px;color:inherit;text-rendering:optimizelegibility}h1 small,h2 small,h3 small,h4 small,h5 small,h6 small{font-weight:normal;color:#7b7b7b}h1,h2,h3{line-height:40px}h1{font-size:39px}h2{font-size:31px}h3{font-size:23px}h4{font-size:17px}h5{font-size:14px}h6{font-size:11px}h1 small{font-size:24px}h2 small{font-size:18px}h3 small{font-size:16px}h4 small{font-size:14px}ul,ol{margin:0 0 10px 25px;padding:0}ul ul,ul ol,ol ol,ol ul{margin-bottom:0}li{line-height:20px}a{color:#c05b4d;text-decoration:none}a:hover,a:focus{color:#a5473a;text-decoration:underline}a:focus{outline:thin dotted #333;outline:5px auto -webkit-focus-ring-color;outline-offset:-2px}.center{text-align:center}html *{color-profile:sRGB;rendering-intent:auto}.cm-s-solarized-light{background-color:#f8f5ec;color:#637c84}.cm-s-solarized-light .emphasis{font-weight:bold}.cm-s-solarized-light .dotted{border-bottom:1px dotted #cb4b16}.cm-s-solarized-light .CodeMirror-gutter{background-color:#eee8d5;border-right:3px solid #eee8d5}.cm-s-solarized-light .CodeMirror-gutter .CodeMirror-gutter-text{color:#93a1a1}.cm-s-solarized-light .CodeMirror-cursor{border-left-color:#002b36 !important}.cm-s-solarized-light .CodeMirror-matchingbracket{color:#002b36;background-color:#eee8d5;box-shadow:0 0 10px #eee8d5;font-weight:bold}.cm-s-solarized-light .CodeMirror-nonmatchingbracket{color:#002b36;background-color:#eee8d5;box-shadow:0 0 10px #eee8d5;font-weight:bold;color:#dc322f;border-bottom:1px dotted #cb4b16}.cm-s-solarized-light span.cm-keyword{color:#268bd2}.cm-s-solarized-light span.cm-atom{color:#2aa198}.cm-s-solarized-light span.cm-number{color:#586e75}.cm-s-solarized-light span.cm-def{color:#637c84}.cm-s-solarized-light span.cm-variable{color:#637c84}.cm-s-solarized-light span.cm-variable-2{color:#b58900}.cm-s-solarized-light span.cm-variable-3{color:#cb4b16}.cm-s-solarized-light span.cm-comment{color:#93a1a1}.cm-s-solarized-light span.cm-property{color:#637c84}.cm-s-solarized-light span.cm-operator{color:#657b83}.cm-s-solarized-light span.cm-string{color:#36958e}.cm-s-solarized-light span.cm-error{font-weight:bold;border-bottom:1px dotted #cb4b16}.cm-s-solarized-light span.cm-bracket{color:#cb4b16}.cm-s-solarized-light span.cm-tag{color:#657b83}.cm-s-solarized-light span.cm-attribute{color:#586e75;font-weight:bold}.cm-s-solarized-light span.cm-meta{color:#268bd2}.cm-s-solarized-dark{background-color:#002b36;color:#839496}.cm-s-solarized-dark .emphasis{font-weight:bold}.cm-s-solarized-dark .dotted{border-bottom:1px dotted #cb4b16}.cm-s-solarized-dark .CodeMirror-gutter{background-color:#073642;border-right:3px solid #073642}.cm-s-solarized-dark .CodeMirror-gutter .CodeMirror-gutter-text{color:#586e75}.cm-s-solarized-dark .CodeMirror-cursor{border-left-color:#fdf6e3 !important}.cm-s-solarized-dark .CodeMirror-matchingbracket{color:#fdf6e3;background-color:#073642;box-shadow:0 0 10px #073642;font-weight:bold}.cm-s-solarized-dark .CodeMirror-nonmatchingbracket{color:#fdf6e3;background-color:#073642;box-shadow:0 0 10px #073642;font-weight:bold;color:#dc322f;border-bottom:1px dotted #cb4b16}.cm-s-solarized-dark span.cm-keyword{color:#839496;font-weight:bold}.cm-s-solarized-dark span.cm-atom{color:#2aa198}.cm-s-solarized-dark span.cm-number{color:#93a1a1}.cm-s-solarized-dark span.cm-def{color:#268bd2}.cm-s-solarized-dark span.cm-variable{color:#cb4b16}.cm-s-solarized-dark span.cm-variable-2{color:#cb4b16}.cm-s-solarized-dark span.cm-variable-3{color:#cb4b16}.cm-s-solarized-dark span.cm-comment{color:#586e75}.cm-s-solarized-dark span.cm-property{color:#b58900}.cm-s-solarized-dark span.cm-operator{color:#839496}.cm-s-solarized-dark span.cm-string{color:#6c71c4}.cm-s-solarized-dark span.cm-error{font-weight:bold;border-bottom:1px dotted #cb4b16}.cm-s-solarized-dark span.cm-bracket{color:#cb4b16}.cm-s-solarized-dark span.cm-tag{color:#839496}.cm-s-solarized-dark span.cm-attribute{color:#93a1a1;font-weight:bold}.cm-s-solarized-dark span.cm-meta{color:#268bd2}*{-webkit-box-sizing:border-box;-moz-box-sizing:border-box;box-sizing:border-box;border:none;margin:0;padding:0}html{background:#f9f9f9}.left{float:left}.right{float:right}.container{padding-top:50px;min-width:960px}.wrap{width:960px;margin-left:auto;margin-right:auto;padding-left:20px;padding-right:20px}.skinnyWrap{width:690px;margin-left:auto;margin-right:auto;padding-left:20px;padding-right:20px}hr{height:0;border-top:1px solid #ccc;border-bottom:1px solid #eee}ul,li{margin-left:20px}li+li{margin-top:10px}h1 .anchor,h2 .anchor,h3 .anchor,h4 .anchor,h5 .anchor,h6 .anchor{margin-top:-50px;position:absolute}h1:hover .hash-link,h2:hover .hash-link,h3:hover .hash-link,h4:hover .hash-link,h5:hover .hash-link,h6:hover .hash-link{display:inline}.hash-link{color:#aaa;display:none}.nav-main{background:#222;color:#fafafa;position:fixed;top:0;height:50px;box-shadow:0 0 5px rgba(0,0,0,0.5);width:100%;z-index:100}.nav-main:after{content:"";display:table;clear:both}.nav-main a{color:#e9e9e9;text-decoration:none}.nav-main .nav-site-internal{margin:0 0 0 20px}.nav-main .nav-site-external{float:right;margin:0}.nav-main .nav-site li{margin:0}.nav-main .nav-site a{box-sizing:content-box;padding:0 10px;line-height:50px;display:inline-block;height:50px;color:#ddd}.nav-main .nav-site a:hover{color:#fff}.nav-main .nav-site a.active{color:#fafafa;border-bottom:3px solid #cc7a6f;background:#333}.nav-main .nav-home{color:#00d8ff;font-size:24px;line-height:50px;height:50px;display:inline-block}.nav-main .nav-logo{vertical-align:middle;display:inline-block}.nav-main ul{display:inline-block;vertical-align:top}.nav-main li{display:inline}.hero{height:300px;background:#2d2d2d;padding-top:50px;color:#e9e9e9;font-weight:300}.hero .text{font-size:64px;text-align:center}.hero .minitext{font-size:16px;text-align:center;text-transform:uppercase}.hero strong{color:#61dafb;font-weight:400}.buttons-unit{margin-top:60px;text-align:center}.buttons-unit a{color:#61dafb}.buttons-unit .button{font-size:24px;background:#cc7a6f;color:#fafafa}.buttons-unit .button:active{background:#c5695c}.buttons-unit.downloads{margin:30px 0}.nav-docs{color:#2d2d2d;font-size:14px;float:left;width:210px}.nav-docs ul{list-style:none;margin:0}.nav-docs ul ul{margin:6px 0 0 20px}.nav-docs li{line-height:16px;margin:0 0 6px}.nav-docs h3{text-transform:uppercase;font-size:14px}.nav-docs a{color:#666;display:block}.nav-docs a:hover{text-decoration:none;color:#cc7a6f}.nav-docs a.active{color:#cc7a6f}.nav-docs .nav-docs-section{border-bottom:1px solid #ccc;border-top:1px solid #eee;padding:12px 0}.nav-docs .nav-docs-section:first-child{padding-top:0;border-top:0}.nav-docs .nav-docs-section:last-child{padding-bottom:0;border-bottom:0}.nav-blog li{margin-bottom:5px}.home-section{margin:50px 0}.home-divider{border-top-color:#bbb;margin:0 auto;width:400px}.skinny-row:after{content:"";display:table;clear:both}.skinny-col{float:left;margin-left:40px;width:305px}.skinny-col:first-child{margin-left:0}.marketing-row{margin:50px 0}.marketing-row:after{content:"";display:table;clear:both}.marketing-col{float:left;margin-left:40px;width:280px}.marketing-col h3{color:#2d2d2d;font-size:24px;font-weight:normal;text-transform:uppercase}.marketing-col p{font-size:16px}.marketing-col:first-child{margin-left:0}#examples h3,.home-presentation h3{color:#2d2d2d;font-size:24px;font-weight:normal;margin-bottom:5px}#examples p{margin:0 0 25px 0;max-width:600px}#examples .example{margin-top:60px}#examples #todoExample{font-size:14px}#examples #todoExample ul{list-style-type:square;margin:0 0 10px 0}#examples #todoExample input{border:1px solid #ccc;font:14px proxima-nova,"Helvetica Neue",Helvetica,Roboto,Arial,sans-serif;padding:3px;width:150px}#examples #todoExample button{font:14px proxima-nova,"Helvetica Neue",Helvetica,Roboto,Arial,sans-serif;margin-left:5px;padding:4px 10px}#examples #markdownExample textarea{border:1px solid #ccc;font:14px proxima-nova,"Helvetica Neue",Helvetica,Roboto,Arial,sans-serif;margin-bottom:10px;padding:5px}.home-bottom-section{margin-bottom:100px}.docs-nextprev:after{content:"";display:table;clear:both}.docs-prev{float:left}.docs-next{float:right}footer{font-size:13px;font-weight:600;margin-top:36px;margin-bottom:18px;overflow:auto}section.black content{padding-bottom:18px}.blogContent{padding-top:20px}.blogContent:after{content:"";display:table;clear:both}.blogContent blockquote{padding:5px 15px;margin:20px 0;background-color:#f8f5ec;border-left:5px solid #f7ebc6}.blogContent h2>code{font-size:inherit;line-height:inherit;color:#555;background-color:rgba(0,0,0,0.04)}.documentationContent{padding-top:20px}.documentationContent:after{content:"";display:table;clear:both}.documentationContent .subHeader{font-size:24px}.documentationContent h2{margin-top:30px}.documentationContent blockquote{padding:15px 30px 15px 15px;margin:20px 0;background-color:rgba(204,122,111,0.1);border-left:5px solid rgba(191,87,73,0.2)}.documentationContent blockquote h4{margin-top:0}.documentationContent blockquote p{margin-bottom:0}.documentationContent blockquote p:first-child{font-weight:bold;font-size:17.5px;line-height:20px;margin-top:0;text-rendering:optimizelegibility}.docs-prevnext{padding-top:40px;padding-bottom:40px}.jsxCompiler{margin:0 auto;padding-top:20px;width:1220px}.jsxCompiler label.compiler-option{display:block;margin-top:5px}.jsxCompiler #jsxCompiler{margin-top:20px}.jsxCompiler .playgroundPreview{padding:0;width:600px}.jsxCompiler .playgroundPreview pre{font-family:'source-code-pro', Menlo, Consolas, 'Courier New', monospace;font-size:13px;line-height:1.5}.jsxCompiler .playgroundError{padding:15px 20px}.button{background:-webkit-linear-gradient(#9a9a9a, #646464);background:linear-gradient(#9a9a9a, #646464);border-radius:4px;padding:8px 16px;font-size:18px;font-weight:400;margin:0 12px;display:inline-block;color:#fafafa;text-decoration:none;text-shadow:0 1px 3px rgba(0,0,0,0.3);box-shadow:0 1px 1px rgba(0,0,0,0.2);text-decoration:none}.button:hover{text-decoration:none}.button:active{box-shadow:none}.hero .button{box-shadow:1px 3px 3px rgba(0,0,0,0.3)}.button.blue{background:-webkit-linear-gradient(#77a3d2, #4783c2);background:linear-gradient(#77a3d2, #4783c2)}.row{padding-bottom:4px}.row .span4{width:33.33%;display:table-cell}.row .span8{width:66.66%;display:table-cell}.row .span6{width:50%;display:table-cell}p{margin:10px 0}.highlight{padding:10px;margin-bottom:20px}figure{text-align:center}.inner-content{float:right;width:650px}.nosidebar .inner-content{float:none;margin:0 auto}h1:after{content:"";display:table;clear:both}.edit-page-link{float:right;font-size:16px;font-weight:normal;line-height:20px;margin-top:17px}.post-list-item+.post-list-item{margin-top:60px}div.CodeMirror pre,div.CodeMirror-linenumber,code{font-family:'source-code-pro', Menlo, Consolas, 'Courier New', monospace;font-size:13px;line-height:1.5}div.CodeMirror-linenumber{text-align:right}.CodeMirror,div.CodeMirror-gutters,div.highlight{border:none}.CodeMirror-readonly div.CodeMirror-cursor{visibility:hidden}small code,li code,p code{color:#555;background-color:rgba(0,0,0,0.04);padding:1px 3px}.cm-s-default span.cm-string-2{color:inherit}.playground:after{content:"";display:table;clear:both}.playground-tab{border-bottom:none !important;border-radius:3px 3px 0 0;padding:6px 8px;font-size:12px;font-weight:bold;color:#c2c0bc;background-color:#f1ede4;display:inline-block;cursor:pointer}.playgroundCode,.playground-tab,.playgroundPreview{border:1px solid rgba(16,16,16,0.1)}.playground-tab-active{color:#222}.playgroundCode{border-radius:0 3px 3px 3px;float:left;overflow:hidden;width:600px}.playgroundPreview{background-color:white;border-radius:3px;float:right;padding:15px 20px;width:280px}.playgroundError{color:#c5695c;font-size:15px}.MarkdownEditor textarea{width:100%;height:100px}.MarkdownEditor .content{white-space:pre-wrap}.hll{background-color:#f7ebc6;border-left:5px solid #f7d87c;display:block;margin-left:-14px;margin-right:-14px;padding-left:9px}.highlight .javascript .err{background-color:transparent;color:inherit}.highlight{position:relative;margin-bottom:14px;padding:30px 14px 14px;border:none;border-radius:0;overflow:auto}.highlight pre{padding:0;margin-top:0;margin-bottom:0;background-color:transparent;border:0}.highlight pre code{display:block;background:none;padding:0}.highlight pre .lineno{display:inline-block;width:22px;padding-right:5px;margin-right:10px;color:#bebec5;text-align:right}.highlight:after{position:absolute;top:0;right:0;left:0;padding:3px 7px;font-size:12px;font-weight:bold;color:#c2c0bc;background-color:#f1ede4;content:"Code"}.downloadCenter{text-align:center;margin-top:20px;margin-bottom:25px}.downloadSection:hover{text-decoration:none !important}@media screen and (max-width: 960px){.nav-main{position:static}.container{padding-top:0}}.post{margin-bottom:30px}.pagination{margin-bottom:30px;width:100%;overflow:hidden}.pagination .next{float:right}div[data-twttr-id] iframe{margin:10px auto !important;width:100% !important}.three-column:after{content:"";display:table;clear:both}.three-column>ul{float:left;margin-left:30px;width:190px}.three-column>ul:first-child{margin-left:20px}
+html{font-family:"Helvetica Neue",Helvetica,Roboto,Arial,sans-serif;font-family:proxima-nova,"Helvetica Neue",Helvetica,Roboto,Arial,sans-serif;color:#484848;line-height:1.28}p{margin:0 0 10px}.subHeader{font-size:21px;font-weight:200;line-height:30px;margin-bottom:10px}em{font-style:italic}h1,h2,h3,h4,h5,h6{margin:10px 0;font-family:inherit;font-weight:bold;line-height:20px;color:inherit;text-rendering:optimizelegibility}h1 small,h2 small,h3 small,h4 small,h5 small,h6 small{font-weight:normal;color:#7b7b7b}h1,h2,h3{line-height:40px}h1{font-size:39px}h2{font-size:31px}h3{font-size:23px}h4{font-size:17px}h5{font-size:14px}h6{font-size:11px}h1 small{font-size:24px}h2 small{font-size:18px}h3 small{font-size:16px}h4 small{font-size:14px}ul,ol{margin:0 0 10px 25px;padding:0}ul ul,ul ol,ol ol,ol ul{margin-bottom:0}li{line-height:20px}a{color:#c05b4d;text-decoration:none}a:hover,a:focus{color:#a5473a;text-decoration:underline}a:focus{outline:thin dotted #333;outline:5px auto -webkit-focus-ring-color;outline-offset:-2px}.center{text-align:center}html *{color-profile:sRGB;rendering-intent:auto}.cm-s-solarized-light{background-color:#f8f5ec;color:#637c84}.cm-s-solarized-light .emphasis{font-weight:bold}.cm-s-solarized-light .dotted{border-bottom:1px dotted #cb4b16}.cm-s-solarized-light .CodeMirror-gutter{background-color:#eee8d5;border-right:3px solid #eee8d5}.cm-s-solarized-light .CodeMirror-gutter .CodeMirror-gutter-text{color:#93a1a1}.cm-s-solarized-light .CodeMirror-cursor{border-left-color:#002b36 !important}.cm-s-solarized-light .CodeMirror-matchingbracket{color:#002b36;background-color:#eee8d5;box-shadow:0 0 10px #eee8d5;font-weight:bold}.cm-s-solarized-light .CodeMirror-nonmatchingbracket{color:#002b36;background-color:#eee8d5;box-shadow:0 0 10px #eee8d5;font-weight:bold;color:#dc322f;border-bottom:1px dotted #cb4b16}.cm-s-solarized-light span.cm-keyword{color:#268bd2}.cm-s-solarized-light span.cm-atom{color:#2aa198}.cm-s-solarized-light span.cm-number{color:#586e75}.cm-s-solarized-light span.cm-def{color:#637c84}.cm-s-solarized-light span.cm-variable{color:#637c84}.cm-s-solarized-light span.cm-variable-2{color:#b58900}.cm-s-solarized-light span.cm-variable-3{color:#cb4b16}.cm-s-solarized-light span.cm-comment{color:#93a1a1}.cm-s-solarized-light span.cm-property{color:#637c84}.cm-s-solarized-light span.cm-operator{color:#657b83}.cm-s-solarized-light span.cm-string{color:#36958e}.cm-s-solarized-light span.cm-error{font-weight:bold;border-bottom:1px dotted #cb4b16}.cm-s-solarized-light span.cm-bracket{color:#cb4b16}.cm-s-solarized-light span.cm-tag{color:#657b83}.cm-s-solarized-light span.cm-attribute{color:#586e75;font-weight:bold}.cm-s-solarized-light span.cm-meta{color:#268bd2}.cm-s-solarized-dark{background-color:#002b36;color:#839496}.cm-s-solarized-dark .emphasis{font-weight:bold}.cm-s-solarized-dark .dotted{border-bottom:1px dotted #cb4b16}.cm-s-solarized-dark .CodeMirror-gutter{background-color:#073642;border-right:3px solid #073642}.cm-s-solarized-dark .CodeMirror-gutter .CodeMirror-gutter-text{color:#586e75}.cm-s-solarized-dark .CodeMirror-cursor{border-left-color:#fdf6e3 !important}.cm-s-solarized-dark .CodeMirror-matchingbracket{color:#fdf6e3;background-color:#073642;box-shadow:0 0 10px #073642;font-weight:bold}.cm-s-solarized-dark .CodeMirror-nonmatchingbracket{color:#fdf6e3;background-color:#073642;box-shadow:0 0 10px #073642;font-weight:bold;color:#dc322f;border-bottom:1px dotted #cb4b16}.cm-s-solarized-dark span.cm-keyword{color:#839496;font-weight:bold}.cm-s-solarized-dark span.cm-atom{color:#2aa198}.cm-s-solarized-dark span.cm-number{color:#93a1a1}.cm-s-solarized-dark span.cm-def{color:#268bd2}.cm-s-solarized-dark span.cm-variable{color:#cb4b16}.cm-s-solarized-dark span.cm-variable-2{color:#cb4b16}.cm-s-solarized-dark span.cm-variable-3{color:#cb4b16}.cm-s-solarized-dark span.cm-comment{color:#586e75}.cm-s-solarized-dark span.cm-property{color:#b58900}.cm-s-solarized-dark span.cm-operator{color:#839496}.cm-s-solarized-dark span.cm-string{color:#6c71c4}.cm-s-solarized-dark span.cm-error{font-weight:bold;border-bottom:1px dotted #cb4b16}.cm-s-solarized-dark span.cm-bracket{color:#cb4b16}.cm-s-solarized-dark span.cm-tag{color:#839496}.cm-s-solarized-dark span.cm-attribute{color:#93a1a1;font-weight:bold}.cm-s-solarized-dark span.cm-meta{color:#268bd2}*{-webkit-box-sizing:border-box;-moz-box-sizing:border-box;box-sizing:border-box;border:none;margin:0;padding:0}html{background:#f9f9f9}.left{float:left}.right{float:right}.container{padding-top:50px;min-width:960px}.wrap{width:960px;margin-left:auto;margin-right:auto;padding-left:20px;padding-right:20px}.skinnyWrap{width:690px;margin-left:auto;margin-right:auto;padding-left:20px;padding-right:20px}hr{height:0;border-top:1px solid #ccc;border-bottom:1px solid #eee}ul,li{margin-left:20px}li+li{margin-top:10px}h1 .anchor,h2 .anchor,h3 .anchor,h4 .anchor,h5 .anchor,h6 .anchor{margin-top:-50px;position:absolute}h1:hover .hash-link,h2:hover .hash-link,h3:hover .hash-link,h4:hover .hash-link,h5:hover .hash-link,h6:hover .hash-link{display:inline}.hash-link{color:#aaa;display:none}.nav-main{background:#222;color:#fafafa;position:fixed;top:0;height:50px;box-shadow:0 0 5px rgba(0,0,0,0.5);width:100%;z-index:100}.nav-main:after{content:"";display:table;clear:both}.nav-main a{color:#e9e9e9;text-decoration:none}.nav-main .nav-site-internal{margin:0 0 0 20px}.nav-main .nav-site-external{float:right;margin:0}.nav-main .nav-site li{margin:0}.nav-main .nav-site a{box-sizing:content-box;padding:0 10px;line-height:50px;display:inline-block;height:50px;color:#ddd}.nav-main .nav-site a:hover{color:#fff}.nav-main .nav-site a.active{color:#fafafa;border-bottom:3px solid #cc7a6f;background:#333}.nav-main .nav-home{color:#00d8ff;font-size:24px;line-height:50px;height:50px;display:inline-block}.nav-main .nav-logo{vertical-align:middle;display:inline-block}.nav-main ul{display:inline-block;vertical-align:top}.nav-main li{display:inline}.hero{height:300px;background:#2d2d2d;padding-top:50px;color:#e9e9e9;font-weight:300}.hero .text{font-size:64px;text-align:center}.hero .minitext{font-size:16px;text-align:center;text-transform:uppercase}.hero strong{color:#61dafb;font-weight:400}.buttons-unit{margin-top:60px;text-align:center}.buttons-unit a{color:#61dafb}.buttons-unit .button{font-size:24px;background:#cc7a6f;color:#fafafa}.buttons-unit .button:active{background:#c5695c}.buttons-unit.downloads{margin:30px 0}.nav-docs{color:#2d2d2d;font-size:14px;float:left;width:210px}.nav-docs ul{list-style:none;margin:0}.nav-docs ul ul{margin:6px 0 0 20px}.nav-docs li{line-height:16px;margin:0 0 6px}.nav-docs h3{text-transform:uppercase;font-size:14px}.nav-docs a{color:#666;display:block}.nav-docs a:hover{text-decoration:none;color:#cc7a6f}.nav-docs a.active{color:#cc7a6f}.nav-docs .nav-docs-section{border-bottom:1px solid #ccc;border-top:1px solid #eee;padding:12px 0}.nav-docs .nav-docs-section:first-child{padding-top:0;border-top:0}.nav-docs .nav-docs-section:last-child{padding-bottom:0;border-bottom:0}.nav-blog li{margin-bottom:5px}.home-section{margin:50px 0}.home-divider{border-top-color:#bbb;margin:0 auto;width:400px}.skinny-row:after{content:"";display:table;clear:both}.skinny-col{float:left;margin-left:40px;width:305px}.skinny-col:first-child{margin-left:0}.marketing-row{margin:50px 0}.marketing-row:after{content:"";display:table;clear:both}.marketing-col{float:left;margin-left:40px;width:280px}.marketing-col h3{color:#2d2d2d;font-size:24px;font-weight:normal;text-transform:uppercase}.marketing-col p{font-size:16px}.marketing-col:first-child{margin-left:0}#examples h3,.home-presentation h3{color:#2d2d2d;font-size:24px;font-weight:normal;margin-bottom:5px}#examples p{margin:0 0 25px 0;max-width:600px}#examples .example{margin-top:60px}#examples #todoExample{font-size:14px}#examples #todoExample ul{list-style-type:square;margin:0 0 10px 0}#examples #todoExample input{border:1px solid #ccc;font:14px proxima-nova,"Helvetica Neue",Helvetica,Roboto,Arial,sans-serif;padding:3px;width:150px}#examples #todoExample button{font:14px proxima-nova,"Helvetica Neue",Helvetica,Roboto,Arial,sans-serif;margin-left:5px;padding:4px 10px}#examples #markdownExample textarea{border:1px solid #ccc;font:14px proxima-nova,"Helvetica Neue",Helvetica,Roboto,Arial,sans-serif;margin-bottom:10px;padding:5px}.home-bottom-section{margin-bottom:100px}.docs-nextprev:after{content:"";display:table;clear:both}.docs-prev{float:left}.docs-next{float:right}footer{font-size:13px;font-weight:600;margin-top:36px;margin-bottom:18px;overflow:auto}section.black content{padding-bottom:18px}.blogContent{padding-top:20px}.blogContent:after{content:"";display:table;clear:both}.blogContent blockquote{padding:5px 15px;margin:20px 0;background-color:#f8f5ec;border-left:5px solid #f7ebc6}.blogContent h2>code{font-size:inherit;line-height:inherit;color:#555;background-color:rgba(0,0,0,0.04)}.documentationContent{padding-top:20px}.documentationContent:after{content:"";display:table;clear:both}.documentationContent .subHeader{font-size:24px}.documentationContent h2{margin-top:30px}.documentationContent blockquote{padding:15px 30px 15px 15px;margin:20px 0;background-color:rgba(204,122,111,0.1);border-left:5px solid rgba(191,87,73,0.2)}.documentationContent blockquote h4{margin-top:0}.documentationContent blockquote p{margin-bottom:0}.documentationContent blockquote p:first-child{font-weight:bold;font-size:17.5px;line-height:20px;margin-top:0;text-rendering:optimizelegibility}.docs-prevnext{padding-top:40px;padding-bottom:40px}.jsxCompiler{margin:0 auto;padding-top:20px;width:1220px}.jsxCompiler label.compiler-option{display:block;margin-top:5px}.jsxCompiler #jsxCompiler{margin-top:20px}.jsxCompiler .playgroundPreview{padding:0;width:600px}.jsxCompiler .playgroundPreview pre{font-family:'source-code-pro', Menlo, Consolas, 'Courier New', monospace;font-size:13px;line-height:1.5}.jsxCompiler .playgroundError{padding:15px 20px}.button{background:-webkit-linear-gradient(#9a9a9a, #646464);background:linear-gradient(#9a9a9a, #646464);border-radius:4px;padding:8px 16px;font-size:18px;font-weight:400;margin:0 12px;display:inline-block;color:#fafafa;text-decoration:none;text-shadow:0 1px 3px rgba(0,0,0,0.3);box-shadow:0 1px 1px rgba(0,0,0,0.2);text-decoration:none}.button:hover{text-decoration:none}.button:active{box-shadow:none}.hero .button{box-shadow:1px 3px 3px rgba(0,0,0,0.3)}.button.blue{background:-webkit-linear-gradient(#77a3d2, #4783c2);background:linear-gradient(#77a3d2, #4783c2)}.row{padding-bottom:4px}.row .span4{width:33.33%;display:table-cell}.row .span8{width:66.66%;display:table-cell}.row .span6{width:50%;display:table-cell}p{margin:10px 0}.highlight{padding:10px;margin-bottom:20px}figure{text-align:center}.inner-content{float:right;width:650px}.nosidebar .inner-content{float:none;margin:0 auto}h1:after{content:"";display:table;clear:both}.edit-page-link{float:right;font-size:16px;font-weight:normal;line-height:20px;margin-top:17px}.post-list-item+.post-list-item{margin-top:60px}div.CodeMirror pre,div.CodeMirror-linenumber,code{font-family:'source-code-pro', Menlo, Consolas, 'Courier New', monospace;font-size:13px;line-height:1.5}div.CodeMirror-linenumber{text-align:right}.CodeMirror,div.CodeMirror-gutters,div.highlight{border:none}.CodeMirror-readonly div.CodeMirror-cursor{visibility:hidden}small code,li code,p code{color:#555;background-color:rgba(0,0,0,0.04);padding:1px 3px}.cm-s-default span.cm-string-2{color:inherit}.playground:after{content:"";display:table;clear:both}.playground-tab{border-bottom:none !important;border-radius:3px 3px 0 0;padding:6px 8px;font-size:12px;font-weight:bold;color:#c2c0bc;background-color:#f1ede4;display:inline-block;cursor:pointer}.playgroundCode,.playground-tab,.playgroundPreview{border:1px solid rgba(16,16,16,0.1)}.playground-tab-active{color:#222}.playgroundCode{border-radius:0 3px 3px 3px;float:left;overflow:hidden;width:600px}.playgroundPreview{background-color:white;border-radius:3px;float:right;padding:15px 20px;width:280px}.playgroundError{color:#c5695c;font-size:15px}.MarkdownEditor textarea{width:100%;height:100px}.MarkdownEditor .content{white-space:pre-wrap}.hll{background-color:#f7ebc6;border-left:5px solid #f7d87c;display:block;margin-left:-14px;margin-right:-14px;padding-left:9px}.highlight .javascript .err{background-color:transparent;color:inherit}.highlight{position:relative;margin-bottom:14px;padding:30px 14px 14px;border:none;border-radius:0;overflow:auto}.highlight pre{padding:0;margin-top:0;margin-bottom:0;background-color:transparent;border:0}.highlight pre code{display:block;background:none;padding:0}.highlight pre .lineno{display:inline-block;width:22px;padding-right:5px;margin-right:10px;color:#bebec5;text-align:right}.highlight:after{position:absolute;top:0;right:0;left:0;padding:3px 7px;font-size:12px;font-weight:bold;color:#c2c0bc;background-color:#f1ede4;content:"Code"}.downloadCenter{text-align:center;margin-top:20px;margin-bottom:25px}.downloadSection:hover{text-decoration:none !important}@media screen and (max-width: 960px){.nav-main{position:static}.container{padding-top:0}}.post{margin-bottom:30px}.post img{max-width:100%}.pagination{margin-bottom:30px;width:100%;overflow:hidden}.pagination .next{float:right}div[data-twttr-id] iframe{margin:10px auto !important;width:100% !important}.three-column:after{content:"";display:table;clear:both}.three-column>ul{float:left;margin-left:30px;width:190px}.three-column>ul:first-child{margin-left:20px}
diff --git a/feed.xml b/feed.xml
index cb5fef1f75..8fa7df8f20 100644
--- a/feed.xml
+++ b/feed.xml
@@ -6,6 +6,84 @@
https://facebook.github.io/react
+
+ New React Devtools Beta
+ <p>We've made an entirely new version of the devtools, and we want you to try it
+out!</p>
+
+<p><img src="/react/img/blog/devtools-full.gif" alt="The full devtools gif"></p>
+<h2><a class="anchor" name="why-entirely-new"></a>Why entirely new? <a class="hash-link" href="#why-entirely-new">#</a></h2>
+<p>Perhaps the biggest reason was to create a defined API for dealing with
+internals, so that other tools could benefit as well and not have to depend on
+implementation details. This gives us more freedom to refactor things
+internally without worrying about breaking tooling.</p>
+
+<p>The current version of the devtools is a fork of Blink's "Elements" pane, and
+is imperative, mutation-driven, and tightly integrated with Chrome-specific
+APIs. The new devtools are much less coupled to Chrome, and easier to reason
+about thanks to React.</p>
+<h2><a class="anchor" name="what-are-the-benefits"></a>What are the benefits? <a class="hash-link" href="#what-are-the-benefits">#</a></h2>
+<ul>
+<li>100% React</li>
+<li>Firefox compatible</li>
+<li>React Native compatible</li>
+<li>more extensible & hackable</li>
+</ul>
+<h2><a class="anchor" name="are-there-any-new-features"></a>Are there any new features? <a class="hash-link" href="#are-there-any-new-features">#</a></h2>
+<p>Yeah!</p>
+<h3><a class="anchor" name="the-tree-view"></a>The Tree View <a class="hash-link" href="#the-tree-view">#</a></h3>
+<p><img src="/react/img/blog/devtools-tree-view.png" alt="The new tree view of the devtools"></p>
+
+<ul>
+<li>Much richer view of your props, including the contents of objects and arrays</li>
+<li>Custom components are emphasized, native components are de-emphasized</li>
+<li>Stateful components have a red collapser</li>
+<li>Improved keyboard navigation (hjkl or arrow keys)</li>
+<li>Selected component is available in the console as <code>$r</code></li>
+<li>Props that change highlight in green</li>
+<li><p>Right-click menu</p>
+
+<ul>
+<li>Scroll node into view</li>
+<li>Show the source for a component in the "Sources" pane</li>
+<li>Show the element in the "Elements" pane</li>
+</ul></li>
+</ul>
+<h3><a class="anchor" name="searching"></a>Searching <a class="hash-link" href="#searching">#</a></h3>
+<p>Select the search bar (or press "/"), and start searching for a component by
+name.</p>
+
+<p><img src="/react/img/blog/devtools-search.gif" alt=""></p>
+<h3><a class="anchor" name="the-side-pane"></a>The Side Pane <a class="hash-link" href="#the-side-pane">#</a></h3>
+<ul>
+<li>Now shows the <code>context</code> for a component</li>
+<li>Right-click to store a prop/state value as a global variable</li>
+</ul>
+
+<p><img src="/react/img/blog/devtools-side-pane.gif" alt=""></p>
+<h2><a class="anchor" name="how-do-i-install-it"></a>How do I install it? <a class="hash-link" href="#how-do-i-install-it">#</a></h2>
+<p>First, disable the Chrome web store version, or it will break things. Then
+<a href="https://github.com/facebook/react-devtools/releases">download the .crx</a> and
+drag it into your <code>chrome://extensions</code> page. If it's not working to drag it
+from the downloads bar, try opening your downloads folder and drag it from
+there.</p>
+
+<p>Once we've determined that there aren't any major regressions, we'll update
+the official web store version, and everyone will be automatically upgraded.</p>
+<h3><a class="anchor" name="also-firefox"></a>Also Firefox! <a class="hash-link" href="#also-firefox">#</a></h3>
+<p>We also have an initial version of the devtools for Firefox, which you can
+download from the same <a href="https://github.com/facebook/react-devtools/releases">release page</a>.</p>
+<h2><a class="anchor" name="feedback-welcome"></a>Feedback welcome <a class="hash-link" href="#feedback-welcome">#</a></h2>
+<p>Let us know what issues you run into
+<a href="https://github.com/facebook/react-devtools/issues">on GitHub</a>, and check out
+<a href="https://github.com/facebook/react-devtools/tree/devtools-next">the README</a>
+for more info.</p>
+
+ 2015-08-03T00:00:00-07:00
+ https://facebook.github.io/react/blog/2015/08/03/new-react-devtools-beta.html
+ https://facebook.github.io/react/blog/2015/08/03/new-react-devtools-beta.html
+
+
React v0.14 Beta 1<p>This week, many people in the React community are at <a href="https://www.react-europe.org/">ReactEurope</a> in the beautiful (and very warm) city of Paris, the second React conference that's been held to date. At our last conference, we released the first beta of React 0.13, and we figured we'd do the same today with our first beta of React 0.14, giving you something to play with if you're not at the conference or you're looking for something to do on the way home.</p>
@@ -422,197 +500,5 @@ Minified build for production: <a href="https://fb.me/react-with-addons-
https://facebook.github.io/react/blog/2015/03/26/introducing-react-native.html
-
- Building The Facebook News Feed With Relay
- <p>At React.js Conf in January we gave a preview of Relay, a new framework for building data-driven applications in React. In this post, we'll describe the process of creating a Relay application. This post assumes some familiarity with the concepts of Relay and GraphQL, so if you haven't already we recommend reading <a href="/react/blog/2015/02/20/introducing-relay-and-graphql.html">our introductory blog post</a> or watching <a href="https://www.youtube-nocookie.com/watch?v=9sc8Pyc51uU">the conference talk</a>.</p>
-
-<p>We're working hard to prepare GraphQL and Relay for public release. In the meantime, we'll continue to provide information about what you can expect.</p>
-
-<p><br/></p>
-<h2><a class="anchor" name="the-relay-architecture"></a>The Relay Architecture <a class="hash-link" href="#the-relay-architecture">#</a></h2>
-<p>The diagram below shows the main parts of the Relay architecture on the client and the server:</p>
-
-<p><img src="/react/img/blog/relay-components/relay-architecture.png" alt="Relay Architecture" width="650" /></p>
-
-<p>The main pieces are as follows:</p>
-
-<ul>
-<li>Relay Components: React components annotated with declarative data descriptions.</li>
-<li>Actions: Descriptions of how data should change in response to user actions.</li>
-<li>Relay Store: A client-side data store that is fully managed by the framework.</li>
-<li>Server: An HTTP server with GraphQL endpoints (one for reads, one for writes) that respond to GraphQL queries.</li>
-</ul>
-
-<p>This post will focus on <strong>Relay components</strong> that describe encapsulated units of UI and their data dependencies. These components form the majority of a Relay application.</p>
-
-<p><br/></p>
-<h2><a class="anchor" name="a-relay-application"></a>A Relay Application <a class="hash-link" href="#a-relay-application">#</a></h2>
-<p>To see how components work and can be composed, let's implement a basic version of the Facebook News Feed in Relay. Our application will have two components: a <code><NewsFeed></code> that renders a list of <code><Story></code> items. We'll introduce the plain React version of each component first and then convert it to a Relay component. The goal is something like the following:</p>
-
-<p><img src="/react/img/blog/relay-components/sample-newsfeed.png" alt="Sample News Feed" width="360" /></p>
-
-<p><br/></p>
-<h2><a class="anchor" name="the-ltstorygt-begins"></a>The <code><Story></code> Begins <a class="hash-link" href="#the-ltstorygt-begins">#</a></h2>
-<p>The first step is a React <code><Story></code> component that accepts a <code>story</code> prop with the story's text and author information. Note that all examples uses ES6 syntax and elide presentation details to focus on the pattern of data access.</p>
-<div class="highlight"><pre><code class="language-javascript" data-lang="javascript"><span class="c1">// Story.react.js</span>
-<span class="kr">class</span> <span class="nx">Story</span> <span class="kr">extends</span> <span class="nx">React</span><span class="p">.</span><span class="nx">Component</span> <span class="p">{</span>
- <span class="nx">render</span><span class="p">()</span> <span class="p">{</span>
- <span class="kd">var</span> <span class="nx">story</span> <span class="o">=</span> <span class="k">this</span><span class="p">.</span><span class="nx">props</span><span class="p">.</span><span class="nx">story</span><span class="p">;</span>
- <span class="k">return</span> <span class="p">(</span>
- <span class="o"><</span><span class="nx">View</span><span class="o">></span>
- <span class="o"><</span><span class="nx">Image</span> <span class="nx">uri</span><span class="o">=</span><span class="p">{</span><span class="nx">story</span><span class="p">.</span><span class="nx">author</span><span class="p">.</span><span class="nx">profile_picture</span><span class="p">.</span><span class="nx">uri</span><span class="p">}</span> <span class="o">/></span>
- <span class="o"><</span><span class="nx">Text</span><span class="o">></span><span class="p">{</span><span class="nx">story</span><span class="p">.</span><span class="nx">author</span><span class="p">.</span><span class="nx">name</span><span class="p">}</span><span class="o"><</span><span class="err">/Text></span>
- <span class="o"><</span><span class="nx">Text</span><span class="o">></span><span class="p">{</span><span class="nx">story</span><span class="p">.</span><span class="nx">text</span><span class="p">}</span><span class="o"><</span><span class="err">/Text></span>
- <span class="o"><</span><span class="err">/View></span>
- <span class="p">);</span>
- <span class="p">}</span>
-<span class="p">}</span>
-
-<span class="nx">module</span><span class="p">.</span><span class="nx">exports</span> <span class="o">=</span> <span class="nx">Story</span><span class="p">;</span>
-</code></pre></div>
-<p><br/></p>
-<h2><a class="anchor" name="whats-the-ltstorygt"></a>What's the <code><Story></code>? <a class="hash-link" href="#whats-the-ltstorygt">#</a></h2>
-<p>Relay automates the process of fetching data for components by wrapping existing React components in Relay containers (themselves React components):</p>
-<div class="highlight"><pre><code class="language-javascript" data-lang="javascript"><span class="c1">// Story.react.js</span>
-<span class="kr">class</span> <span class="nx">Story</span> <span class="kr">extends</span> <span class="nx">React</span><span class="p">.</span><span class="nx">Component</span> <span class="p">{</span> <span class="p">...</span> <span class="p">}</span>
-
-<span class="nx">module</span><span class="p">.</span><span class="nx">exports</span> <span class="o">=</span> <span class="nx">Relay</span><span class="p">.</span><span class="nx">createContainer</span><span class="p">(</span><span class="nx">Story</span><span class="p">,</span> <span class="p">{</span>
- <span class="nx">queries</span><span class="o">:</span> <span class="p">{</span>
- <span class="nx">story</span><span class="o">:</span> <span class="cm">/* TODO */</span>
- <span class="p">}</span>
-<span class="p">});</span>
-</code></pre></div>
-<p>Before adding the GraphQL query, let's look at the component hierarchy this creates:</p>
-
-<p><img src="/react/img/blog/relay-components/relay-containers.png" width="397" alt="React Container Data Flow" /></p>
-
-<p>Most props will be passed through from the container to the original component. However, Relay will return the query results for a prop whenever a query is defined. In this case we'll add a GraphQL query for <code>story</code>:</p>
-<div class="highlight"><pre><code class="language-javascript" data-lang="javascript"><span class="c1">// Story.react.js</span>
-<span class="kr">class</span> <span class="nx">Story</span> <span class="kr">extends</span> <span class="nx">React</span><span class="p">.</span><span class="nx">Component</span> <span class="p">{</span> <span class="p">...</span> <span class="p">}</span>
-
-<span class="nx">module</span><span class="p">.</span><span class="nx">exports</span> <span class="o">=</span> <span class="nx">Relay</span><span class="p">.</span><span class="nx">createContainer</span><span class="p">(</span><span class="nx">Story</span><span class="p">,</span> <span class="p">{</span>
- <span class="nx">queries</span><span class="o">:</span> <span class="p">{</span>
- <span class="nx">story</span><span class="o">:</span> <span class="nx">graphql</span><span class="err">`</span>
- <span class="nx">Story</span> <span class="p">{</span>
- <span class="nx">author</span> <span class="p">{</span>
- <span class="nx">name</span><span class="p">,</span>
- <span class="nx">profile_picture</span> <span class="p">{</span>
- <span class="nx">uri</span>
- <span class="p">}</span>
- <span class="p">},</span>
- <span class="nx">text</span>
- <span class="p">}</span>
- <span class="err">`</span>
- <span class="p">}</span>
-<span class="p">});</span>
-</code></pre></div>
-<p>Queries use ES6 template literals tagged with the <code>graphql</code> function. Similar to how JSX transpiles to plain JavaScript objects and function calls, these template literals transpile to plain objects that describe queries. Note that the query's structure closely matches the object structure that we expected in <code><Story></code>'s render function.</p>
-
-<p><br/></p>
-<h2><a class="anchor" name="ltstorygts-on-demand"></a><code><Story></code>s on Demand <a class="hash-link" href="#ltstorygts-on-demand">#</a></h2>
-<p>We can render a Relay component by providing Relay with the component (<code><Story></code>) and the ID of the data (a story ID). Given this information, Relay will first fetch the results of the query and then <code>render()</code> the component. The value of <code>props.story</code> will be a plain JavaScript object such as the following:</p>
-<div class="highlight"><pre><code class="language-javascript" data-lang="javascript"><span class="p">{</span>
- <span class="nx">author</span><span class="o">:</span> <span class="p">{</span>
- <span class="nx">name</span><span class="o">:</span> <span class="s2">"Greg"</span><span class="p">,</span>
- <span class="nx">profile_picture</span><span class="o">:</span> <span class="p">{</span>
- <span class="nx">uri</span><span class="o">:</span> <span class="s2">"https://…"</span>
- <span class="p">}</span>
- <span class="p">},</span>
- <span class="nx">text</span><span class="o">:</span> <span class="s2">"The first Relay blog post is up…"</span>
-<span class="p">}</span>
-</code></pre></div>
-<p>Relay guarantees that all data required to render a component will be available before it is rendered. This means that <code><Story></code> does not need to handle a loading state; the <code>story</code> is <em>guaranteed</em> to be available before <code>render()</code> is called. We have found that this invariant simplifies our application code <em>and</em> improves the user experience. Of course, Relay also has options to delay the fetching of some parts of our queries.</p>
-
-<p>The diagram below shows how Relay containers make data available to our React components:</p>
-
-<p><img src="/react/img/blog/relay-components/relay-containers-data-flow.png" width="650" alt="Relay Container Data Flow" /></p>
-
-<p><br/></p>
-<h2><a class="anchor" name="ltnewsfeedgt-worthy"></a><code><NewsFeed></code> Worthy <a class="hash-link" href="#ltnewsfeedgt-worthy">#</a></h2>
-<p>Now that the <code><Story></code> is over we can continue with the <code><NewsFeed></code> component. Again, we'll start with a React version:</p>
-<div class="highlight"><pre><code class="language-javascript" data-lang="javascript"><span class="c1">// NewsFeed.react.js</span>
-<span class="kr">class</span> <span class="nx">NewsFeed</span> <span class="kr">extends</span> <span class="nx">React</span><span class="p">.</span><span class="nx">Component</span> <span class="p">{</span>
- <span class="nx">render</span><span class="p">()</span> <span class="p">{</span>
- <span class="kd">var</span> <span class="nx">stories</span> <span class="o">=</span> <span class="k">this</span><span class="p">.</span><span class="nx">props</span><span class="p">.</span><span class="nx">viewer</span><span class="p">.</span><span class="nx">stories</span><span class="p">;</span> <span class="c1">// `viewer` is the active user</span>
- <span class="k">return</span> <span class="p">(</span>
- <span class="o"><</span><span class="nx">View</span><span class="o">></span>
- <span class="p">{</span><span class="nx">stories</span><span class="p">.</span><span class="nx">map</span><span class="p">(</span><span class="nx">story</span> <span class="o">=></span> <span class="o"><</span><span class="nx">Story</span> <span class="nx">story</span><span class="o">=</span><span class="p">{</span><span class="nx">story</span><span class="p">}</span> <span class="o">/></span><span class="p">)}</span>
- <span class="o"><</span><span class="nx">Button</span> <span class="nx">onClick</span><span class="o">=</span><span class="p">{()</span> <span class="o">=></span> <span class="k">this</span><span class="p">.</span><span class="nx">loadMore</span><span class="p">()}</span><span class="o">></span><span class="nx">Load</span> <span class="nx">More</span><span class="o"><</span><span class="err">/Button></span>
- <span class="o"><</span><span class="err">/View></span>
- <span class="p">);</span>
- <span class="p">}</span>
-
- <span class="nx">loadMore</span><span class="p">()</span> <span class="p">{</span>
- <span class="c1">// TODO: fetch more stories</span>
- <span class="p">}</span>
-<span class="p">}</span>
-
-<span class="nx">module</span><span class="p">.</span><span class="nx">exports</span> <span class="o">=</span> <span class="nx">NewsFeed</span><span class="p">;</span>
-</code></pre></div>
-<p><br/></p>
-<h2><a class="anchor" name="all-the-news-fit-to-be-relayed"></a>All the News Fit to be Relayed <a class="hash-link" href="#all-the-news-fit-to-be-relayed">#</a></h2>
-<p><code><NewsFeed></code> has two new requirements: it composes <code><Story></code> and requests more data at runtime.</p>
-
-<p>Just as React views can be nested, Relay queries can compose queries from child components. Composition in GraphQL uses ES6 template literal substitution: <code>${Component.getQuery('prop')}</code>. Pagination can be accomplished with a query parameter, specified with <code><param></code> (as in <code>stories(first: <count>)</code>):</p>
-<div class="highlight"><pre><code class="language-javascript" data-lang="javascript"><span class="c1">// NewsFeed.react.js</span>
-<span class="kr">class</span> <span class="nx">NewsFeed</span> <span class="kr">extends</span> <span class="nx">React</span><span class="p">.</span><span class="nx">Component</span> <span class="p">{</span> <span class="p">...</span> <span class="p">}</span>
-
-<span class="nx">module</span><span class="p">.</span><span class="nx">exports</span> <span class="o">=</span> <span class="nx">Relay</span><span class="p">.</span><span class="nx">createContainer</span><span class="p">(</span><span class="nx">NewsFeed</span><span class="p">,</span> <span class="p">{</span>
- <span class="nx">queryParams</span><span class="o">:</span> <span class="p">{</span>
- <span class="nx">count</span><span class="o">:</span> <span class="mi">3</span> <span class="cm">/* default to 3 stories */</span>
- <span class="p">},</span>
- <span class="nx">queries</span><span class="o">:</span> <span class="p">{</span>
- <span class="nx">viewer</span><span class="o">:</span> <span class="nx">graphql</span><span class="err">`</span>
- <span class="nx">Viewer</span> <span class="p">{</span>
- <span class="nx">stories</span><span class="p">(</span><span class="nx">first</span><span class="o">:</span> <span class="o"><</span><span class="nx">count</span><span class="o">></span><span class="p">)</span> <span class="p">{</span> <span class="cm">/* fetch viewer's stories */</span>
- <span class="nx">edges</span> <span class="p">{</span> <span class="cm">/* traverse the graph */</span>
- <span class="nx">node</span> <span class="p">{</span>
- <span class="nx">$</span><span class="p">{</span><span class="nx">Story</span><span class="p">.</span><span class="nx">getQuery</span><span class="p">(</span><span class="s1">'story'</span><span class="p">)}</span> <span class="cm">/* compose child query */</span>
- <span class="p">}</span>
- <span class="p">}</span>
- <span class="p">}</span>
- <span class="p">}</span>
- <span class="err">`</span>
- <span class="p">}</span>
-<span class="p">});</span>
-</code></pre></div>
-<p>Whenever <code><NewsFeed></code> is rendered, Relay will recursively expand all the composed queries and fetch them in a single trip to the server. In this case, the <code>text</code> and <code>author</code> data will be fetched for each of the 3 story nodes.</p>
-
-<p>Query parameters are available to components as <code>props.queryParams</code> and can be modified with <code>props.setQueryParams(nextParams)</code>. We can use these to implement pagination:</p>
-<div class="highlight"><pre><code class="language-javascript" data-lang="javascript"><span class="c1">// NewsFeed.react.js</span>
-<span class="kr">class</span> <span class="nx">NewsFeed</span> <span class="kr">extends</span> <span class="nx">React</span><span class="p">.</span><span class="nx">Component</span> <span class="p">{</span>
- <span class="nx">render</span><span class="p">()</span> <span class="p">{</span> <span class="p">...</span> <span class="p">}</span>
-
- <span class="nx">loadMore</span><span class="p">()</span> <span class="p">{</span>
- <span class="c1">// read current params</span>
- <span class="kd">var</span> <span class="nx">count</span> <span class="o">=</span> <span class="k">this</span><span class="p">.</span><span class="nx">props</span><span class="p">.</span><span class="nx">queryParams</span><span class="p">.</span><span class="nx">count</span><span class="p">;</span>
- <span class="c1">// update params</span>
- <span class="k">this</span><span class="p">.</span><span class="nx">props</span><span class="p">.</span><span class="nx">setQueryParams</span><span class="p">({</span>
- <span class="nx">count</span><span class="o">:</span> <span class="nx">count</span> <span class="o">+</span> <span class="mi">5</span>
- <span class="p">});</span>
- <span class="p">}</span>
-<span class="p">}</span>
-</code></pre></div>
-<p>Now when <code>loadMore()</code> is called, Relay will send a GraphQL request for the additional five stories. When these stories are fetched, the component will re-render with the new stories available in <code>props.viewer.stories</code> and the updated count reflected in <code>props.queryParams.count</code>.</p>
-
-<p><br/></p>
-<h2><a class="anchor" name="in-conclusion"></a>In Conclusion <a class="hash-link" href="#in-conclusion">#</a></h2>
-<p>These two components form a solid core for our application. With the use of Relay containers and GraphQL queries, we've enabled the following benefits:</p>
-
-<ul>
-<li>Automatic and efficient pre-fetching of data for an entire view hierarchy in a single network request.</li>
-<li>Trivial pagination with automatic optimizations to fetch only the additional items.</li>
-<li>View composition and reusability, so that <code><Story></code> can be used on its own or within <code><NewsFeed></code>, without any changes to either component.</li>
-<li>Automatic subscriptions, so that components will re-render if their data changes. Unaffected components will not re-render unnecessarily.</li>
-<li>Exactly <em>zero</em> lines of imperative data fetching logic. Relay takes full advantage of React's declarative component model.</li>
-</ul>
-
-<p>But Relay has many more tricks up its sleeve. For example, it's built from the start to handle reads and writes, allowing for features like optimistic client updates with transactional rollback. Relay can also defer fetching select parts of queries, and it uses a local data store to avoid fetching the same data twice. These are all powerful features that we hope to explore in future posts.</p>
-
- 2015-03-19T00:00:00-07:00
- https://facebook.github.io/react/blog/2015/03/19/building-the-facebook-news-feed-with-relay.html
- https://facebook.github.io/react/blog/2015/03/19/building-the-facebook-news-feed-with-relay.html
-
-
diff --git a/img/blog/devtools-full.gif b/img/blog/devtools-full.gif
new file mode 100644
index 0000000000..fd7ed94938
Binary files /dev/null and b/img/blog/devtools-full.gif differ
diff --git a/img/blog/devtools-search.gif b/img/blog/devtools-search.gif
new file mode 100644
index 0000000000..22d80051df
Binary files /dev/null and b/img/blog/devtools-search.gif differ
diff --git a/img/blog/devtools-side-pane.gif b/img/blog/devtools-side-pane.gif
new file mode 100644
index 0000000000..381e3554ee
Binary files /dev/null and b/img/blog/devtools-side-pane.gif differ
diff --git a/img/blog/devtools-tree-view.png b/img/blog/devtools-tree-view.png
new file mode 100644
index 0000000000..a8add55861
Binary files /dev/null and b/img/blog/devtools-tree-view.png differ
+ React
+ 
