In the weeks following the open-source release of the Relay technical preview, the community has been abuzz with activity. We are honored to have been able to enjoy a steady stream of ideas and contributions from such a talented group of individuals. Let's take a look at some of the things we've achieved, together!
Every great Relay app starts by finding a GraphQL server to talk to. The community has spent the past few weeks teaching GraphQL to a few backend systems.
+
+
Bryan Goldstein (brysgo) has built a tool to help you define a GraphQL schema that wraps a set of Bookshelf.JS models. Check out graphql-bookshelf.
+
+
RisingStack (risingstack) created a GraphQL ORM called graffiti that you can plug into mongoose and serve using Express, Hapi, or Koa.
+
+
David Mongeau-Petitpas (dmongeau) is working on a way to vend your Laravel models through a GraphQL endpoint, laravel-graphql.
+
+
Gerald Monaco (devknoll) created graphql-schema to allow the creation of JavaScript GraphQL schemas using a fluent/chainable interface.
+
+
Jason Dusek (solidsnack) dove deep into PostgreSQL to teach it how to respond to GraphQL query strings as though they were SQL queries. Check out GraphpostgresQL.
+
+
Espen Hovlandsdal (rexxars) built a sql-to-graphql tool that can perform introspection on the tables of a MySQL or PostgreSQL database, and produce a queryable HTTP GraphQL endpoint out of it.
Sam has already launched a product that leverages Relay's data-fetching, optimistic responses, pagination, and mutations – all atop a Ruby GraphQL server: new.comique.co
I (steveluscher) whipped up a prototyping tool that you can use to hack on a schema and a React/Relay app, from the comfort of your browser. Thanks to Jimmy Jia (taion) for supplying the local-only network layer, relay-local-schema.
Jimmy Jia (taion) and Gerald Monaco (devknoll) have been helping lost URLs find their way to Relay apps through their work on react-router-relay. Check out Christoph Pojer's (cpojer) blog post on the topic. Jimmy completed the Relay TodoMVC example with routing, which you can check out at taion/relay-todomvc.
+
+
Chen Hung-Tu (transedward) built a chat app atop the above mentioned router, with threaded conversations and pagination. Check it out at transedward/relay-chat.
In the weeks following the open-source release of the Relay technical preview, the community has been abuzz with activity. We are honored to have been able to enjoy a steady stream of ideas and contributions from such a talented group of individuals. Let's take a look at some of the things we've achieved, together!
Every great Relay app starts by finding a GraphQL server to talk to. The community has spent the past few weeks teaching GraphQL to a few backend systems.
+
+
Bryan Goldstein (brysgo) has built a tool to help you define a GraphQL schema that wraps a set of Bookshelf.JS models. Check out graphql-bookshelf.
+
+
RisingStack (risingstack) created a GraphQL ORM called graffiti that you can plug into mongoose and serve using Express, Hapi, or Koa.
+
+
David Mongeau-Petitpas (dmongeau) is working on a way to vend your Laravel models through a GraphQL endpoint, laravel-graphql.
+
+
Gerald Monaco (devknoll) created graphql-schema to allow the creation of JavaScript GraphQL schemas using a fluent/chainable interface.
+
+
Jason Dusek (solidsnack) dove deep into PostgreSQL to teach it how to respond to GraphQL query strings as though they were SQL queries. Check out GraphpostgresQL.
+
+
Espen Hovlandsdal (rexxars) built a sql-to-graphql tool that can perform introspection on the tables of a MySQL or PostgreSQL database, and produce a queryable HTTP GraphQL endpoint out of it.
Sam has already launched a product that leverages Relay's data-fetching, optimistic responses, pagination, and mutations – all atop a Ruby GraphQL server: new.comique.co
I (steveluscher) whipped up a prototyping tool that you can use to hack on a schema and a React/Relay app, from the comfort of your browser. Thanks to Jimmy Jia (taion) for supplying the local-only network layer, relay-local-schema.
Jimmy Jia (taion) and Gerald Monaco (devknoll) have been helping lost URLs find their way to Relay apps through their work on react-router-relay. Check out Christoph Pojer's (cpojer) blog post on the topic. Jimmy completed the Relay TodoMVC example with routing, which you can check out at taion/relay-todomvc.
+
+
Chen Hung-Tu (transedward) built a chat app atop the above mentioned router, with threaded conversations and pagination. Check it out at transedward/relay-chat.
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.
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.
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 7181b98bb0..7272ea81eb 100644
--- a/blog/page2/index.html
+++ b/blog/page2/index.html
@@ -66,6 +66,8 @@
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, 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 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, 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”.
-
-
Here’s to another year!
-
-
-
-
-
diff --git a/feed.xml b/feed.xml
index c02c199391..d6db6edb13 100644
--- a/feed.xml
+++ b/feed.xml
@@ -6,6 +6,78 @@
https://facebook.github.io/react
+
+ Community Round-up #27 – Relay Edition
+ <p>In the weeks following the <a href="/react/blog/2015/08/11/relay-technical-preview.html">open-source release</a> of the Relay technical preview, the community has been abuzz with activity. We are honored to have been able to enjoy a steady stream of ideas and contributions from such a talented group of individuals. Let's take a look at some of the things we've achieved, together!</p>
+<h2><a class="anchor" name="teaching-servers-to-speak-graphql"></a>Teaching servers to speak GraphQL <a class="hash-link" href="#teaching-servers-to-speak-graphql">#</a></h2>
+<p>Every great Relay app starts by finding a GraphQL server to talk to. The community has spent the past few weeks teaching GraphQL to a few backend systems.</p>
+
+<p>Bryan Goldstein (<a href="https://github.com/brysgo">brysgo</a>) has built a tool to help you define a GraphQL schema that wraps a set of <a href="http://bookshelfjs.org/">Bookshelf.JS</a> models. Check out <a href="https://github.com/brysgo/graphql-bookshelf">graphql-bookshelf</a>.</p>
+
+<p>RisingStack (<a href="https://github.com/risingstack">risingstack</a>) created a GraphQL ORM called <a href="https://github.com/RisingStack/graffiti">graffiti</a> that you can plug into <a href="http://mongoosejs.com/">mongoose</a> and serve using Express, Hapi, or Koa.</p>
+
+<p>David Mongeau-Petitpas (<a href="https://github.com/dmongeau">dmongeau</a>) is working on a way to vend your Laravel models through a GraphQL endpoint, <a href="https://github.com/Folkloreatelier/laravel-graphql">laravel-graphql</a>.</p>
+
+<p>Gerald Monaco (<a href="https://github.com/devknoll">devknoll</a>) created <a href="https://github.com/devknoll/graphql-schema">graphql-schema</a> to allow the creation of JavaScript GraphQL schemas using a fluent/chainable interface.</p>
+
+<p>Jason Dusek (<a href="https://github.com/solidsnack">solidsnack</a>) dove deep into PostgreSQL to teach it how to respond to GraphQL query strings as though they were SQL queries. Check out <a href="https://github.com/solidsnack/GraphpostgresQL">GraphpostgresQL</a>.</p>
+
+<p>Espen Hovlandsdal (<a href="https://github.com/rexxars">rexxars</a>) built a <a href="https://github.com/vaffel/sql-to-graphql">sql-to-graphql</a> tool that can perform introspection on the tables of a MySQL or PostgreSQL database, and produce a queryable HTTP GraphQL endpoint out of it.</p>
+
+<p>Mick Hansen (<a href="https://github.com/mickhansen">mickhansen</a>) offers a set of <a href="https://github.com/mickhansen/graphql-sequelize">schema-building helpers</a> for use with the <a href="http://docs.sequelizejs.com/en/latest/">Sequelize ORM</a> for MySQL, PostgreSQL, SQLite, and MSSQL.</p>
+<h2><a class="anchor" name="graphql-beyond-javascript"></a>GraphQL beyond JavaScript <a class="hash-link" href="#graphql-beyond-javascript">#</a></h2>
+<p>Robert Mosolgo (<a href="https://github.com/rmosolgo">rmosolgo</a>) brought the full set of schema-building and query execution tools to Ruby, in the form of <a href="https://github.com/rmosolgo/graphql-ruby">graphql-ruby</a> and <a href="https://github.com/rmosolgo/graphql-relay-ruby">graphql-relay-ruby</a>. Check out his <a href="https://github.com/rmosolgo/graphql-ruby-demo">Rails-based demo</a>.</p>
+
+<p>Andreas Marek (<a href="https://github.com/andimarek">andimarek</a>) has brewed up a Java implementation of GraphQL, <a href="https://github.com/andimarek/graphql-java">graphql-java</a>.</p>
+
+<p><a href="https://github.com/vladar">vladar</a> is hard at work on a PHP port of the GraphQL reference implementation, <a href="https://github.com/webonyx/graphql-php">graphql-php</a>.</p>
+
+<p>Taeho Kim (<a href="https://github.com/dittos">dittos</a>) is bringing GraphQL to Python, with <a href="https://github.com/dittos/graphql-py">graphql-py</a>.</p>
+
+<p>Oleg Ilyenko (<a href="https://github.com/OlegIlyenko">OlegIlyenko</a>) made a beautiful and <a href="http://sangria-graphql.org/">delicious-looking website</a> for a Scala implementation of GraphQL, <a href="https://github.com/sangria-graphql/sangria">sangria</a>.</p>
+
+<p>Joe McBride (<a href="https://github.com/joemcbride">joemcbride</a>) has an up-and-running example of GraphQL for .NET, <a href="https://github.com/joemcbride/graphql-dotnet">graphql-dotnet</a>.</p>
+<h2><a class="anchor" name="show-me-dont-tell-me"></a>Show me, don't tell me <a class="hash-link" href="#show-me-dont-tell-me">#</a></h2>
+<p>Interact with this <a href="http://sgwilym.github.io/relay-visual-learners/">visual tour of Relay's architecture</a> by Sam Gwilym (<a href="https://github.com/sgwilym">sgwilym</a>).</p>
+
+<p><a href="http://sgwilym.github.io/relay-visual-learners/">
+ <img src="/react/img/blog/relay-visual-architecture-tour.png" alt="Relay for visual learners" style="max-width:100%">
+</a></p>
+
+<p>Sam has already launched a product that leverages Relay's data-fetching, optimistic responses, pagination, and mutations – all atop a Ruby GraphQL server: <a href="http://new.comique.co/">new.comique.co</a></p>
+<h2><a class="anchor" name="prototyping-in-the-browser"></a>Prototyping in the browser <a class="hash-link" href="#prototyping-in-the-browser">#</a></h2>
+<p>I (<a href="https://github.com/steveluscher">steveluscher</a>) whipped up <a href="https://facebook.github.io/relay/prototyping/playground.html">a prototyping tool</a> that you can use to hack on a schema and a React/Relay app, from the comfort of your browser. Thanks to Jimmy Jia (<a href="https://github.com/taion">taion</a>) for supplying the local-only network layer, <a href="https://github.com/relay-tools/relay-local-schema">relay-local-schema</a>.</p>
+<h2><a class="anchor" name="skeletons-in-the-closet"></a>Skeletons in the closet <a class="hash-link" href="#skeletons-in-the-closet">#</a></h2>
+<p>Joseph Rollins (<a href="https://github.com/fortruce">fortruce</a>) created a hot-reloading, auto schema-regenerating, <a href="https://github.com/fortruce/relay-skeleton">Relay skeleton</a> that you can use to get up and running quickly.</p>
+
+<p>Michael Hart (<a href="https://mhart">mhart</a>) built a <a href="https://github.com/mhart/simple-relay-starter">simple-relay-starter</a> kit using Browserify.</p>
+<h2><a class="anchor" name="routing-around"></a>Routing around <a class="hash-link" href="#routing-around">#</a></h2>
+<p>Jimmy Jia (<a href="https://github.com/taion">taion</a>) and Gerald Monaco (<a href="https://github.com/devknoll">devknoll</a>) have been helping lost URLs find their way to Relay apps through their work on <a href="https://github.com/relay-tools/react-router-relay">react-router-relay</a>. Check out Christoph Pojer's (<a href="https://github.com/cpojer">cpojer</a>) <a href="https://medium.com/@cpojer/relay-and-routing-36b5439bad9">blog post</a> on the topic. Jimmy completed the Relay TodoMVC example with routing, which you can check out at <a href="https://github.com/taion/relay-todomvc">taion/relay-todomvc</a>.</p>
+
+<p>Chen Hung-Tu (<a href="https://github.com/transedward">transedward</a>) built a chat app atop the above mentioned router, with threaded conversations and pagination. Check it out at <a href="https://github.com/transedward/relay-chat">transedward/relay-chat</a>.</p>
+<h2><a class="anchor" name="in-your-words"></a>In your words <a class="hash-link" href="#in-your-words">#</a></h2>
+<div class="skinny-row">
+ <div class="skinny-col">
+ <blockquote class="twitter-tweet" lang="en"><p lang="en" dir="ltr">Relay making good on its promise to be the "React.js of data fetching". Rebuilding small app with it. Spectacular how fast/easy building is.</p>— Kyle Mathews (@kylemathews) <a href="https://twitter.com/kylemathews/status/640289107122368513">September 5, 2015</a></blockquote>
+
+ <blockquote class="twitter-tweet" lang="en"><p lang="en" dir="ltr"><a href="https://twitter.com/hashtag/RainySundayHackathon?src=hash">#RainySundayHackathon</a> exploring <a href="https://twitter.com/hashtag/GraphQL?src=hash">#GraphQL</a> <a href="https://twitter.com/hashtag/RelayJS?src=hash">#RelayJS</a> <a href="http://t.co/Mm3HlqMejJ">pic.twitter.com/Mm3HlqMejJ</a></p>— Bastian Kistner (@passionkind) <a href="https://twitter.com/passionkind/status/632846601447411712">August 16, 2015</a></blockquote>
+
+ <blockquote class="twitter-tweet" lang="en"><p lang="en" dir="ltr">Friday. Time to GraphQL a MySQL database. <a href="https://twitter.com/hashtag/graphql?src=hash">#graphql</a> <a href="https://twitter.com/hashtag/relayjs?src=hash">#relayjs</a> <a href="https://twitter.com/hashtag/reactjs?src=hash">#reactjs</a> <a href="https://twitter.com/hashtag/webapp?src=hash">#webapp</a></p>— xador (@xadorfr) <a href="https://twitter.com/xadorfr/status/632108552765751296">August 14, 2015</a></blockquote>
+ </div>
+ <div class="skinny-col">
+ <blockquote class="twitter-tweet" lang="en"><p lang="en" dir="ltr">Started a new <a href="https://twitter.com/hashtag/RelayJS?src=hash">#RelayJS</a> and <a href="https://twitter.com/hashtag/GraphQL?src=hash">#GraphQL</a> meet up group! <a href="http://t.co/Vt6Cv4nNH4">http://t.co/Vt6Cv4nNH4</a> If you're in the Bay Area, I'd love to have you join! <a href="https://twitter.com/hashtag/ReactJS?src=hash">#ReactJS</a></p>— Gerald Monaco (@devknoll) <a href="https://twitter.com/devknoll/status/636723716123000832">August 27, 2015</a></blockquote>
+
+ <blockquote class="twitter-tweet" lang="en"><p lang="en" dir="ltr">.<a href="https://twitter.com/reactjs">@reactjs</a> <a href="https://twitter.com/laneykuenzel">@laneykuenzel</a> <a href="https://twitter.com/BhuwanKhattar">@BhuwanKhattar</a> these <a href="https://twitter.com/hashtag/relayjs?src=hash">#relayjs</a> mutations. they're mind-blowingly awesome. they make so much damn sense. thank you!</p>— Jimmy Jia (@jimmy_jia) <a href="https://twitter.com/jimmy_jia/status/634204563709526016">August 20, 2015</a></blockquote>
+
+ <blockquote class="twitter-tweet" lang="en"><p lang="en" dir="ltr">REST is dead, long live REST! <a href="https://twitter.com/hashtag/graphql?src=hash">#graphql</a> <a href="https://twitter.com/hashtag/relayjs?src=hash">#relayjs</a></p>— Syrus Akbary (@syrusakbary) <a href="https://twitter.com/syrusakbary/status/631531666113060864">August 12, 2015</a></blockquote>
+ </div>
+</div>
+
+ 2015-09-14T00:00:00-07:00
+ https://facebook.github.io/react/blog/2015/09/14/community-roundup-27.html
+ https://facebook.github.io/react/blog/2015/09/14/community-roundup-27.html
+
+
React v0.14 Release Candidate<p>We’re happy to announce our first release candidate for React 0.14! We gave you a <a href="/react/blog/2015/07/03/react-v0.14-beta-1.html">sneak peek in July</a> at the upcoming changes but we’ve now stabilized the release more and we’d love for you to try it out before we release the final version.</p>
@@ -542,99 +614,5 @@ Minified build for production: <a href="https://fb.me/react-with-addons-
https://facebook.github.io/react/blog/2015/05/08/react-v0.13.3.html
-
- GraphQL Introduction
- <p>At the React.js conference in late January 2015, we revealed our next major technology in the React family: <a href="http://facebook.github.io/react/blog/2015/02/20/introducing-relay-and-graphql.html">Relay</a>. </p>
-
-<p>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 <em>declarative</em> data-fetching specification alongside the React component. The language of this declarative specification is GraphQL.</p>
-
-<p>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.</p>
-
-<p>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.</p>
-<h2><a class="anchor" name="what-is-graphql"></a>What is GraphQL? <a class="hash-link" href="#what-is-graphql">#</a></h2>
-<p>A GraphQL query is a string interpreted by a server that returns data in a specified format. Here is an example query: </p>
-<div class="highlight"><pre><code class="language-js" data-lang="js"><span class="p">{</span>
- <span class="nx">user</span><span class="p">(</span><span class="nx">id</span><span class="o">:</span> <span class="mi">3500401</span><span class="p">)</span> <span class="p">{</span>
- <span class="nx">id</span><span class="p">,</span>
- <span class="nx">name</span><span class="p">,</span>
- <span class="nx">isViewerFriend</span><span class="p">,</span>
- <span class="nx">profilePicture</span><span class="p">(</span><span class="nx">size</span><span class="o">:</span> <span class="mi">50</span><span class="p">)</span> <span class="p">{</span>
- <span class="nx">uri</span><span class="p">,</span>
- <span class="nx">width</span><span class="p">,</span>
- <span class="nx">height</span>
- <span class="p">}</span>
- <span class="p">}</span>
-<span class="p">}</span>
-</code></pre></div>
-<p>(Note: this syntax is slightly different from previous GraphQL examples. We've recently been making improvements to the language.)</p>
-
-<p>And here is the response to that query.</p>
-<div class="highlight"><pre><code class="language-json" data-lang="json"><span class="p">{</span>
- <span class="nt">"user"</span> <span class="p">:</span> <span class="p">{</span>
- <span class="nt">"id"</span><span class="p">:</span> <span class="mi">3500401</span><span class="p">,</span>
- <span class="nt">"name"</span><span class="p">:</span> <span class="s2">"Jing Chen"</span><span class="p">,</span>
- <span class="nt">"isViewerFriend"</span><span class="p">:</span> <span class="kc">true</span><span class="p">,</span>
- <span class="nt">"profilePicture"</span><span class="p">:</span> <span class="p">{</span>
- <span class="nt">"uri"</span><span class="p">:</span> <span class="s2">"http://someurl.cdn/pic.jpg"</span><span class="p">,</span>
- <span class="nt">"width"</span><span class="p">:</span> <span class="mi">50</span><span class="p">,</span>
- <span class="nt">"height"</span><span class="p">:</span> <span class="mi">50</span>
- <span class="p">}</span>
- <span class="p">}</span>
-<span class="p">}</span>
-</code></pre></div>
-<p>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:</p>
-
-<ul>
-<li><strong>Hierarchical:</strong> 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.</li>
-<li><strong>Product-centric:</strong> 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.</li>
-<li><strong>Client-specified queries:</strong> In GraphQL, the specification for queries are encoded in the <em>client</em> rather than the <em>server</em>. 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.</li>
-<li><strong>Backwards Compatible:</strong> 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 <em>at least</em> two years. This means there are at a <em>minimum</em> 52 versions of our clients per platform querying our servers at any given time. Client-specified queries simplifies managing our backwards compatibility guarantees.</li>
-<li><strong>Structured, Arbitrary Code:</strong> 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 <em>arbitrary code</em>. This allows for both server-side flexibility and a uniform, powerful API across the entire surface area of an application.</li>
-<li><strong>Application-Layer Protocol:</strong> 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.</li>
-<li><strong>Strongly-typed:</strong> 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.</li>
-<li><strong>Introspective:</strong> 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.</li>
-</ul>
-<h2><a class="anchor" name="why-invent-something-new"></a>Why invent something new? <a class="hash-link" href="#why-invent-something-new">#</a></h2>
-<p>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 <em>ad hoc</em> endpoints. </p>
-<h3><a class="anchor" name="rest"></a>REST <a class="hash-link" href="#rest">#</a></h3>
-<p>REST, an acronym for Representational State Transfer, 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 <em>self-identify</em> as REST, rather than systems which are formally REST.</p>
-
-<p>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.</p>
-
-<p>We believe there are a number of weakness in typical REST systems, ones that are particularly problematic in mobile applications:</p>
-
-<ul>
-<li>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.</li>
-<li>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.</li>
-<li>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.</li>
-<li>Many of these attributes are linked to the fact that “REST is intended for long-lived network-based applications that span multiple organizations” <a href="http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven">according to its inventor</a>. This is not a requirement for APIs that serve a client app built within the same organization.</li>
-</ul>
-
-<p>Nearly all externally facing REST APIs we know of trend or end up in these non-ideal states, as well as nearly all <em>internal</em> 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.</p>
-
-<p>Because of multiple round-trips and over-fetching, applications built in the REST style inevitably end up building <em>ad hoc</em> 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 <em>ad hoc</em> endpoints.</p>
-<h3><a class="anchor" name="ad-hoc-endpoints"></a>Ad Hoc Endpoints <a class="hash-link" href="#ad-hoc-endpoints">#</a></h3>
-<p>Many applications have no formalized client-server contract. Product developers access server capabilities through <em>ad hoc</em> 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.</p>
-
-<ul>
-<li>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.</li>
-<li>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.</li>
-<li>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.</li>
-<li>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 <em>ad hoc</em> endpoints remain.</li>
-</ul>
-
-<p>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.</p>
-
-<p>This is a liberating platform for product developers. With GraphQL, no more contending with <em>ad hoc</em> 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 <em>ad hoc</em> endpoints into business objects; instead a powerful, introspective type system that serves as a platform for tool building.</p>
-
-<p>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. </p>
-<h2><a class="anchor" name="whats-next"></a>What's next? <a class="hash-link" href="#whats-next">#</a></h2>
-<p>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.</p>
-
- 2015-05-01T00:00:00-07:00
- https://facebook.github.io/react/blog/2015/05/01/graphql-introduction.html
- https://facebook.github.io/react/blog/2015/05/01/graphql-introduction.html
-
-
diff --git a/img/blog/relay-visual-architecture-tour.png b/img/blog/relay-visual-architecture-tour.png
new file mode 100644
index 0000000000..216c7aa79d
Binary files /dev/null and b/img/blog/relay-visual-architecture-tour.png differ
+ React
+ 
+
