We've seen a lot of people comparing React with various frameworks. Ricardo Tomasi decided to re-implement the tutorial without any framework, just plain Javascript.
Stoyan Stefanov gave a talk at BrazilJS about React and wrote an article with the content of the presentation. He goes through the difficulties of writing active apps using the DOM API and shows how React handles it.
Ben Alpert converted marked, a Markdown Javascript implementation, in React: marked-react. Even without using JSX, the HTML generation is now a lot cleaner. It is also safer as forgetting a call to escape will not introduce an XSS vulnerability.
Vjeux re-implemented the display part of the IRC logger in React. Just 130 lines are needed for a performant infinite scroll with timestamps and color-coded author names.
Eric Clemmons is working on a "Modern, opinionated, full-stack starter kit for rapid, streamlined application development". The version 0.4.0 has just been released and has first-class support for React.
@@ -251,6 +269,7 @@ Is this some sort of template language? Specifically no. This might have been th
+
@@ -109,7 +111,9 @@
James Pearce (jamesgpearce) carried Big-Coffee all the way to Raleigh, NC. At the All Things Open conference, he spoke about some of the design decisions that went into React, particularly those that lend themselves to simpler, more reliable code.
Michael Ridgway (mridgway) shows us how Yahoo! (who recently moved Yahoo! Mail to React) renders their React+Flux application, server-side.
@@ -117,9 +121,13 @@
Péter Márton (hekike) helps us brew a cold one (literally) using an application that's server-client isomorphic and indexable. Demo and sample code included – cold ones sold separately.
Ryan Florence (rpflorence) and Michael Jackson (mjackson) unveiled a new API for React Router that solves some of its user's problems by eliminating the problems themselves. Read all about what React Router learned from its community of users, and how they've rolled your ideas into their latest release.
Jonathan Beebe (somethingkindawierd) spoke about how he uses React to build tools that deliver hope to those trying to make the best of a bad situation. Watch his talk from this year's Nodevember conference in Nashville
@@ -127,25 +135,39 @@
If you take a peek under the covers, you'll find that React powers Carousel, Dropbox's new photo and video gallery app.
We enjoyed a cinematic/narrative experience with this React-powered, interactive story by British author William Boyd. Dive into “The Vanishing Game” and see for yourself.
Spend the next 60 seconds watching Daniel Woelfel (dwwoelfel) serialize a React app's state as a string, then deserialize it to produce a working UI. Read about how he uses this technique to reproduce bugs reported to him by his users.
Tom Chen (tomchentw) brings us a react-google-maps component, and a way to syntax highlight source code using Prism and the react-prism component, for good measure.
Jed Watson (jedwatson) helps you manage touch, tap, and press events using the react-tappable component.
To find these, and more community-built components, consult the React Components and React Rocks component directories. React Rocks recently exceeded one-hundred listed components and counting. See one missing? Add the keyword react-component to your package.json to get listed on React Components, and submit a link to React Rocks.
The internet is abuzz with talk of styling React components using JavaScript instead of CSS. Christopher Chedeau (vjeux) talks about some of the fundamental style management challenges we grapple with, at Facebook scale. A number of implementations of JavaScript centric style management solutions have appeared in the wild, including the React-focused react-style.
Facebook Open Source released Flow this month – a static type checker for JavaScript. Naturally, Flow supports JSX, and you can use it to type check React applications. There's never been a better reason to start making use of propTypes in your component specifications!
We're counting down the days until React.js Conf at Facebook's headquarters in Menlo Park, California, on January 28th & 29th, 2015. Thank you, to everyone who responded to the Call for Presenters. Mark the dates; tickets go on sale in three waves: at noon PST on November 28th, December 5th, and December 12th, 2014.
Relay is a new framework from Facebook that provides data-fetching functionality for React applications. It was announced at React.js Conf (January 2015).
Each component specifies its own data dependencies declaratively using a query language called GraphQL. The data is made available to the component via properties on this.props.
Developers compose these React components naturally, and Relay takes care of composing the data queries into efficient batches, providing each component with exactly the data that it requested (and no more), updating those components when the data changes, and maintaining a client-side store (cache) of all data.
GraphQL is a data querying language designed to describe the complex, nested data dependencies of modern applications. It's been in production use in Facebook's native apps for several years.
On the server, we configure the GraphQL system to map queries to underlying data-fetching code. This configuration layer allows GraphQL to work with arbitrary underlying storage mechanisms. Relay uses GraphQL as its query language, but it is not tied to a specific implementation of GraphQL.
Relay was born out of our experiences building large applications at Facebook. Our overarching goal is to enable developers to create correct, high-performance applications in a straightforward and obvious way. The design enables even large teams to make changes with a high degree of isolation and confidence. Fetching data is hard, dealing with ever-changing data is hard, and performance is hard. Relay aims to reduce these problems to simple ones, moving the tricky bits into the framework and freeing you to concentrate on building your application.
By co-locating the queries with the view code, the developer can reason about what a component is doing by looking at it in isolation; it's not necessary to consider the context where the component was rendered in order to understand it. Components can be moved anywhere in a render hierarchy without having to apply a cascade of modifications to parent components or to the server code which prepares the data payload.
@@ -133,11 +141,15 @@
Simplified server implementation: Rather than having a proliferation of end-points (per action, per route), a single GraphQL endpoint can serve as a facade for any number of underlying resources.
Uniform mutations: There is one consistent pattern for performing mutations (writes), and it is conceptually baked into the data querying model itself. You can think of a mutation as a query with side-effects: you provide some parameters that describe the change to be made (eg. attaching a comment to a record) and a query that specifies the data you'll need to update your view of the world after the mutation completes (eg. the comment count on the record), and the data flows through the system using the normal flow. We can do an immediate "optimistic" update on the client (ie. update the view under the assumption that the write will succeed), and finally commit it, retry it or roll it back in the event of an error when the server payload comes back.
In some ways Relay is inspired by Flux, but the mental model is much simpler. Instead of multiple stores, there is one central store that caches all GraphQL data. Instead of explicit subscriptions, the framework itself can track which data each component requests, and which components should be updated whenever the data change. Instead of actions, modifications take the form of mutations.
At Facebook, we have apps built entirely using Flux, entirely using Relay, or with both. One pattern we see emerging is letting Relay manage the bulk of the data flow for an application, but using Flux stores on the side to handle a subset of application state.
We're working very hard right now on getting both GraphQL (a spec, and a reference implementation) and Relay ready for public release (no specific dates yet, but we are super excited about getting these out there).
In the meantime, we'll be providing more and more information in the form of blog posts (and in other channels). As we get closer to the open source release, you can expect more concrete details, syntax and API descriptions and more.
Relay is a new framework from Facebook that provides data-fetching functionality for React applications. It was announced at React.js Conf (January 2015).
Each component specifies its own data dependencies declaratively using a query language called GraphQL. The data is made available to the component via properties on this.props.
Developers compose these React components naturally, and Relay takes care of composing the data queries into efficient batches, providing each component with exactly the data that it requested (and no more), updating those components when the data changes, and maintaining a client-side store (cache) of all data.
GraphQL is a data querying language designed to describe the complex, nested data dependencies of modern applications. It's been in production use in Facebook's native apps for several years.
On the server, we configure the GraphQL system to map queries to underlying data-fetching code. This configuration layer allows GraphQL to work with arbitrary underlying storage mechanisms. Relay uses GraphQL as its query language, but it is not tied to a specific implementation of GraphQL.
Relay was born out of our experiences building large applications at Facebook. Our overarching goal is to enable developers to create correct, high-performance applications in a straightforward and obvious way. The design enables even large teams to make changes with a high degree of isolation and confidence. Fetching data is hard, dealing with ever-changing data is hard, and performance is hard. Relay aims to reduce these problems to simple ones, moving the tricky bits into the framework and freeing you to concentrate on building your application.
By co-locating the queries with the view code, the developer can reason about what a component is doing by looking at it in isolation; it's not necessary to consider the context where the component was rendered in order to understand it. Components can be moved anywhere in a render hierarchy without having to apply a cascade of modifications to parent components or to the server code which prepares the data payload.
@@ -341,11 +388,15 @@
Simplified server implementation: Rather than having a proliferation of end-points (per action, per route), a single GraphQL endpoint can serve as a facade for any number of underlying resources.
Uniform mutations: There is one consistent pattern for performing mutations (writes), and it is conceptually baked into the data querying model itself. You can think of a mutation as a query with side-effects: you provide some parameters that describe the change to be made (eg. attaching a comment to a record) and a query that specifies the data you'll need to update your view of the world after the mutation completes (eg. the comment count on the record), and the data flows through the system using the normal flow. We can do an immediate "optimistic" update on the client (ie. update the view under the assumption that the write will succeed), and finally commit it, retry it or roll it back in the event of an error when the server payload comes back.
In some ways Relay is inspired by Flux, but the mental model is much simpler. Instead of multiple stores, there is one central store that caches all GraphQL data. Instead of explicit subscriptions, the framework itself can track which data each component requests, and which components should be updated whenever the data change. Instead of actions, modifications take the form of mutations.
At Facebook, we have apps built entirely using Flux, entirely using Relay, or with both. One pattern we see emerging is letting Relay manage the bulk of the data flow for an application, but using Flux stores on the side to handle a subset of application state.
We're working very hard right now on getting both GraphQL (a spec, and a reference implementation) and Relay ready for public release (no specific dates yet, but we are super excited about getting these out there).
In the meantime, we'll be providing more and more information in the form of blog posts (and in other channels). As we get closer to the open source release, you can expect more concrete details, syntax and API descriptions and more.
@@ -382,7 +433,9 @@
It was a privilege to welcome the React community to Facebook HQ on January 28–29 for the first-ever React.js Conf, and a pleasure to be able to unveil three new technologies that we've been using internally at Facebook for some time: GraphQL, Relay, and React Native.
We just published a beta version of React v0.13.0 to npm! You can install it with npm install react@0.13.0-beta.1. Since this is a pre-release, we don't have proper release notes ready.
So what is that one feature I'm so excited about that I just couldn't wait to share?
JavaScript originally didn't have a built-in class system. Every popular framework built their own, and so did we. This means that you have a learn slightly different semantics for each framework.
We figured that we're not in the business of designing a class system. We just want to use whatever is the idiomatic JavaScript way of creating classes.
In React 0.13.0 you no longer need to use React.createClass to create React components. If you have a transpiler you can use ES6 classes today. You can use the transpiler we ship with react-tools by making use of the harmony option: jsx --harmony.
Wait, assigning to properties seems like a very imperative way of defining classes! You're right, however, we designed it this way because it's idiomatic. We fully expect a more declarative syntax for property initialization to arrive in future version of JavaScript. It might look something like this:
React.createClass has a built-in magic feature that bound all methods to this automatically for you. This can be a little confusing for JavaScript developers that are not used to this feature in other classes, or it can be confusing when they move from React to other classes.
Therefore we decided not to have this built-in into React's class model. You can still explicitly prebind methods in your constructor if you want.
Unfortunately, we will not launch any mixin support for ES6 classes in React. That would defeat the purpose of only using idiomatic JavaScript concepts.
There is no standard and universal way to define mixins in JavaScript. In fact, several features to support mixins were dropped from ES6 today. There are a lot of libraries with different semantics. We think that there should be one way of defining mixins that you can use for any JavaScript class. React just making another doesn't help that effort.
@@ -767,7 +832,9 @@
The classic React.createClass style of creating classes will continue to work just fine.
Since these classes are just plain old JavaScript classes, you can use other languages that compile to JavaScript classes, such as TypeScript.
You can also use CoffeeScript classes:
@@ -842,19 +909,25 @@
Facebook will make determinations on scholarship recipients in its sole discretion. Facebook complies with all equal opportunity laws.
Must currently be studying or working in Computer Science or a related field
International applicants are welcome, but you will be responsible for securing your own visa to attend the conference
@@ -929,6 +1002,7 @@ Facebook will make determinations on scholarship recipients in its sole discreti
+
@@ -201,7 +208,9 @@ Minified build for production: jamesgpearce) carried Big-Coffee all the way to Raleigh, NC. At the All Things Open conference, he spoke about some of the design decisions that went into React, particularly those that lend themselves to simpler, more reliable code.
-
Michael Ridgway (mridgway) shows us how Yahoo! (who recently moved Yahoo! Mail to React) renders their React+Flux application, server-side.
@@ -209,9 +218,13 @@ Minified build for production: hekike) helps us brew a cold one (literally) using an application that's server-client isomorphic and indexable. Demo and sample code included – cold ones sold separately.
Ryan Florence (rpflorence) and Michael Jackson (mjackson) unveiled a new API for React Router that solves some of its user's problems by eliminating the problems themselves. Read all about what React Router learned from its community of users, and how they've rolled your ideas into their latest release.
Jonathan Beebe (somethingkindawierd) spoke about how he uses React to build tools that deliver hope to those trying to make the best of a bad situation. Watch his talk from this year's Nodevember conference in Nashville
@@ -219,25 +232,39 @@ Minified build for production: Carousel, Dropbox's new photo and video gallery app.
We enjoyed a cinematic/narrative experience with this React-powered, interactive story by British author William Boyd. Dive into “The Vanishing Game” and see for yourself.
Spend the next 60 seconds watching Daniel Woelfel (dwwoelfel) serialize a React app's state as a string, then deserialize it to produce a working UI. Read about how he uses this technique to reproduce bugs reported to him by his users.
Tom Chen (tomchentw) brings us a react-google-maps component, and a way to syntax highlight source code using Prism and the react-prism component, for good measure.
Jed Watson (jedwatson) helps you manage touch, tap, and press events using the react-tappable component.
To find these, and more community-built components, consult the React Components and React Rocks component directories. React Rocks recently exceeded one-hundred listed components and counting. See one missing? Add the keyword react-component to your package.json to get listed on React Components, and submit a link to React Rocks.
The internet is abuzz with talk of styling React components using JavaScript instead of CSS. Christopher Chedeau (vjeux) talks about some of the fundamental style management challenges we grapple with, at Facebook scale. A number of implementations of JavaScript centric style management solutions have appeared in the wild, including the React-focused react-style.
Facebook Open Source released Flow this month – a static type checker for JavaScript. Naturally, Flow supports JSX, and you can use it to type check React applications. There's never been a better reason to start making use of propTypes in your component specifications!
We're counting down the days until React.js Conf at Facebook's headquarters in Menlo Park, California, on January 28th & 29th, 2015. Thank you, to everyone who responded to the Call for Presenters. Mark the dates; tickets go on sale in three waves: at noon PST on November 28th, December 5th, and December 12th, 2014.
@@ -373,13 +400,17 @@ Minified build for production: New Terminology & Updated APIs #
+
+
New Terminology & Updated APIs
+
v0.12 is bringing about some new terminology. We introduced this 2 weeks ago and we've also documented it in a new section of the documentation. As a part of this, we also corrected many of our top-level APIs to align with the terminology. Component has been removed from all of our React.render* methods. While at one point the argument you passed to these functions was called a Component, it no longer is. You are passing ReactElements. To align with render methods in your component classes, we decided to keep the top-level functions short and sweet. React.renderComponent is now React.render.
We also corrected some other misnomers. React.isValidComponent actually determines if the argument is a ReactElement, so it has been renamed to React.isValidElement. In the same vein, React.PropTypes.component is now React.PropTypes.element and React.PropTypes.renderable is now React.PropTypes.node.
The old methods will still work but will warn upon first use. They will be removed in v0.13.
@@ -388,17 +419,27 @@ Minified build for production: DevTools Improvements, No More __internals#
+
+
DevTools Improvements, No More __internals
+
For months we've gotten complaints about the React DevTools message. It shouldn't have logged the up-sell message when you were already using the DevTools. Unfortunately this was because the way we implemented these tools resulted in the DevTools knowing about React, but not the reverse. We finally gave this some attention and enabled React to know if the DevTools are installed. We released an update to the devtools several weeks ago making this possible. Extensions in Chrome should auto-update so you probably already have the update installed!
As a result of this update, we no longer need to expose several internal modules to the world. If you were taking advantage of this implementation detail, your code will break. React.__internals is no more.
We updated the license on React to the BSD 3-Clause license with an explicit patent grant. Previously we used the Apache 2 license. These licenses are very similar and our extra patent grant is equivalent to the grant provided in the Apache license. You can still use React with the confidence that we have granted the use of any patents covering it. This brings us in line with the same licensing we use across the majority of our open source projects at Facebook.
You can read the full text of the LICENSE and PATENTS files on GitHub.
React.addons.update uses assign instead of copyProperties which does hasOwnProperty checks. Properties on prototypes will no longer be updated correctly.
Eric Clemmons is working on a "Modern, opinionated, full-stack starter kit for rapid, streamlined application development". The version 0.4.0 has just been released and has first-class support for React.
@@ -340,7 +368,9 @@ Is this some sort of template language? Specifically no. This might have been th
This is the 10th round-up already and React has come quite far since it was open sourced. Almost all new web projects at Khan Academy, Facebook, and Instagram are being developed using React. React has been deployed in a variety of contexts: a Chrome extension, a Windows 8 application, mobile websites, and desktop websites supporting Internet Explorer 8! Language-wise, React is not only being used within JavaScript but also CoffeeScript and ClojureScript.
The best part is that no drastic changes have been required to support all those use cases. Most of the efforts were targeted at polishing edge cases, performance improvements, and documentation.
Webkit has a TodoMVC Benchmark that compares different frameworks. They recently included React and here are the results (average of 10 runs in Chrome 30):
@@ -416,10 +452,14 @@ Is this some sort of template language? Specifically no. This might have been th
By default, React "re-renders" all the components when anything changes. This is usually fast enough that you don't need to care. However, you can provide a function that can tell whether there will be any change based on the previous and next states and props. If it is faster than re-rendering the component, then you get a performance improvement.
The fact that you can control when components are rendered is a very important characteristic of React as it gives you control over its performance. We are going to talk more about performance in the future, stay tuned.
@@ -429,7 +469,9 @@ Is this some sort of template language? Specifically no. This might have been th
Even though we weren't inspired by FruitMachine (React has been used in production since before FruitMachine was open sourced), it's great to see similar technologies emerging and becoming popular.
@@ -476,14 +520,20 @@ Is this some sort of template language? Specifically no. This might have been th
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!
Stoyan Stefanov gave a talk at BrazilJS about React and wrote an article with the content of the presentation. He goes through the difficulties of writing active apps using the DOM API and shows how React handles it.
Ben Alpert converted marked, a Markdown Javascript implementation, in React: marked-react. Even without using JSX, the HTML generation is now a lot cleaner. It is also safer as forgetting a call to escape will not introduce an XSS vulnerability.
Vjeux re-implemented the display part of the IRC logger in React. Just 130 lines are needed for a performant infinite scroll with timestamps and color-coded author names.
Ben Newman made a 13-lines wrapper to use React and Meteor together. Meteor handles the real-time data synchronization between client and server. React provides the declarative way to write the interface and only updates the parts of the UI that changed.
Jordan Walke implemented a complete React project creator called react-page. It supports both server-side and client-side rendering, source transform and packaging JSX files using CommonJS modules, and instant reload.
@@ -491,7 +531,9 @@
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.
We've seen a lot of people comparing React with various frameworks. Ricardo Tomasi decided to re-implement the tutorial without any framework, just plain Javascript.
@@ -454,17 +482,23 @@
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.
@@ -537,6 +571,7 @@
+
@@ -145,9 +151,13 @@
At the end of this step, you'll have a library of reusable components that render your data model. The components will only have render() methods since this is a static version of your app. The component at the top of the hierarchy (FilterableProductTable) will take your data model as a prop. If you make a change to your underlying data model and call ReactDOM.render() again, the UI will be updated. It's easy to see how your UI is updated and where to make changes since there's nothing complicated going on. React's one-way data flow (also called one-way binding) keeps everything modular and fast.
Simply refer to the React docs if you need help executing this step.
There are two types of "model" data in React: props and state. It's important to understand the distinction between the two; skim the official React docs if you aren't sure what the difference is.
-
Step 3: Identify The Minimal (but complete) Representation Of UI State #
+
+
Step 3: Identify The Minimal (but complete) Representation Of UI State
+
To make your UI interactive, you need to be able to trigger changes to your underlying data model. React makes this easy with state.
To build your app correctly, you first need to think of the minimal set of mutable state that your app needs. The key here is DRY: Don't Repeat Yourself. Figure out the absolute minimal representation of the state your application needs and compute everything else you need on-demand. For example, if you're building a TODO list, just keep an array of the TODO items around; don't keep a separate state variable for the count. Instead, when you want to render the TODO count, simply take the length of the TODO items array.
Cool, so we've decided that our state lives in FilterableProductTable. First, add an instance property this.state = {filterText: '', inStockOnly: false} to FilterableProductTable's constructor to reflect the initial state of your application. Then, pass filterText and inStockOnly to ProductTable and SearchBar as a prop. Finally, use these props to filter the rows in ProductTable and set the values of the form fields in SearchBar.
You can start seeing how your application will behave: set filterText to "ball" and refresh your app. You'll see that the data table is updated correctly.
Let's think about what we want to happen. We want to make sure that whenever the user changes the form, we update the state to reflect the user input. Since components should only update their own state, FilterableProductTable will pass callbacks to SearchBar that will fire whenever the state should be updated. We can use the onChange event on the inputs to be notified of it. The callbacks passed by FilterableProductTable will call setState(), and the app will be updated.
Though this sounds complex, it's really just a few lines of code. And it's really explicit how your data is flowing throughout the app.
Hopefully, this gives you an idea of how to think about building components and applications with React. While it may be a little more typing than you're used to, remember that code is read far more than it's written, and it's extremely easy to read this modular, explicit code. As you start to build large libraries of components, you'll appreciate this explicitness and modularity, and with code reuse, your lines of code will start to shrink. :)
