Multiple people asked what's the story about JSX and CoffeeScript. There is no JSX pre-processor for CoffeeScript and I'm not aware of anyone working on it. Fortunately, CoffeeScript is pretty expressive and we can play around the syntax to come up with something that is usable.
If you take a look at most of our current examples, you'll see us using React.autoBind for event handlers. This is used in place of Function.prototype.bind. Remember that in JS, function calls are late-bound. That means that if you simply pass a function around, the this used inside won't necessarily be the this you expect. Function.prototype.bind creates a new, properly bound, function so that when called, this is exactly what you expect it to be.
Before we launched React, we would write this:
-
React.createClass({
+
React.createClass({onClick:function(event){/* do something with this */},render:function(){return<buttononClick={this.onClick.bind(this)}/>;
@@ -108,7 +108,7 @@
});
We wrote React.autoBind as a way to cache the function creation and save on memory usage. Since render can get called multiple times, if you used this.onClick.bind(this) you would actually create a new function on each pass. With React v0.3 you were able to write this instead:
-
React.createClass({
+
React.createClass({onClick:React.autoBind(function(event){/* do something with this */}),render:function(){return<buttononClick={this.onClick}/>;
@@ -118,7 +118,7 @@
After using React.autoBind for a few weeks, we realized that there were very few times that we didn't want that behavior. So we made it the default! Now all methods defined within React.createClass will already be bound to the correct instance.
Starting with v0.4 you can just write this:
-
React.createClass({
+
React.createClass({onClick:function(event){/* do something with this */},render:function(){return<buttononClick={this.onClick}/>;
diff --git a/blog/2013/07/11/react-v0-4-prop-validation-and-default-values.html b/blog/2013/07/11/react-v0-4-prop-validation-and-default-values.html
index 46b24cce1e..40f19e0a65 100644
--- a/blog/2013/07/11/react-v0-4-prop-validation-and-default-values.html
+++ b/blog/2013/07/11/react-v0-4-prop-validation-and-default-values.html
@@ -100,7 +100,7 @@
Oftentimes you want to validate your props before you use them. Perhaps you want to ensure they are a specific type. Or maybe you want to restrict your prop to specific values. Or maybe you want to make a specific prop required. This was always possible — you could have written validations in your render or componentWillReceiveProps functions, but that gets clunky fast.
React v0.4 will provide a nice easy way for you to use built-in validators, or to even write your own.
-
React.createClass({
+
React.createClass({propTypes:{// An optional string prop named "description".description:React.PropTypes.string,
@@ -115,7 +115,7 @@
});
Do this for a few props across a few components and now you have a lot of redundant code. Starting with React v0.4, you can provide default values in a declarative way:
To make react.js available for use client-side, simply add react to your manifest, and declare the variant you'd like to use in your environment. When you use :production, the minified and optimized react.min.js will be used instead of the development version. For example:
-
# config/environments/development.rb
+
# config/environments/development.rbMyApp::Application.configuredoconfig.react.variant=:development# use :production in production.rbend
-
When you name your file with myfile.js.jsx, react-rails will automatically try to transform that file. For the time being, we still require that you include the docblock at the beginning of the file. For example, this file will get transformed on request.
react-rails takes advantage of the asset pipeline that was introduced in Rails 3.1. A very important part of that pipeline is the assets:precompile Rake task. react-rails will ensure that your JSX files will be transformed into regular JS before all of your assets are minified and packaged.
Daniel Steigerwald is now using React within Este, which is a development stack for web apps in CoffeeScript that are statically typed using the Closure Library.
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
+
fromreactimportjsx# For multiple paths, use the JSXTransformer class.transformer=jsx.JSXTransformer()
@@ -109,21 +109,21 @@
jsx.transform('path/to/input/file.jsx','path/to/output/file.js')
For full paths to React files, use the source module:
-
fromreactimportsource
+
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
+
$ pip install PyReact
Alternatively, add it into your requirements file:
-
PyReact==0.1.1
+
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.
This repository defines a Meteor package that automatically integrates the React rendering framework on both the client and the server, to complement or replace the default Handlebars templating system.
The React core is officially agnostic about how you fetch and update your data, so it is far from obvious which approach is the best. This package provides one answer to that question (use Meteor!), and I hope you will find it a compelling combination.
Alexander Solovyov has been working on React bindings for ClojureScript. This is really exciting as it is using "native" ClojureScript data structures.
A wrapper around JSHint to allow linting of files containg JSX syntax. Accepts glob patterns. Respects your local .jshintrc file and .gitignore to filter your glob patterns.
Please don't take those numbers too seriously, they only reflect one very specific use case and are testing code that wasn't written with performance in mind.
Even though React scores as one of the fastest frameworks in the benchmark, the React code is simple and idiomatic. The only performance tweak used is the following function:
-
/**
+
/** * This is a completely optional performance enhancement that you can implement * on any React component. If you were to delete this method the app would still * work correctly (and still be very performant!), we just use it as an example
diff --git a/blog/2013/12/23/community-roundup-12.html b/blog/2013/12/23/community-roundup-12.html
index 7db85fd0ae..2ffe2956f8 100644
--- a/blog/2013/12/23/community-roundup-12.html
+++ b/blog/2013/12/23/community-roundup-12.html
@@ -114,7 +114,7 @@
We can check the scroll position before the component has updated with componentWillUpdate and scroll if necessary at componentDidUpdate
Geert Pasteels made a small experiment with Socket.io. He wrote a very small mixin that synchronizes React state with the server. Just include this mixin to your React component and it is now live!
Creighton Kirkendall created Kioo, which adds Enlive-style templating to React. HTML templates are separated from the application logic. Kioo comes with separate examples for both Om and Reagent.
...(defn my-nav-item[[captionfunc]](kioo/component"main.html"[:.nav-item]
diff --git a/blog/2014/02/16/react-v0.9-rc1.html b/blog/2014/02/16/react-v0.9-rc1.html
index d06a0cbe4a..7d5ecc4a14 100644
--- a/blog/2014/02/16/react-v0.9-rc1.html
+++ b/blog/2014/02/16/react-v0.9-rc1.html
@@ -115,19 +115,19 @@ Minified build for production: file an issue on GitHub if you see anything awry.
In addition to the changes to React core listed below, we've made a small change to the way JSX interprets whitespace to make things more consistent. With this release, space between two components on the same line will be preserved, while a newline separating a text node from a tag will be eliminated in the output. Consider the code:
In addition to the changes to React core listed below, we've made a small change to the way JSX interprets whitespace to make things more consistent. With this release, space between two components on the same line will be preserved, while a newline separating a text node from a tag will be eliminated in the output. Consider the code:
In v0.9, it will be transformed to this JS instead:
-
React.DOM.div(null,
+
React.DOM.div(null,"Monkeys:",listOfMonkeys," ",submitButton)
diff --git a/blog/2014/03/19/react-v0.10-rc1.html b/blog/2014/03/19/react-v0.10-rc1.html
index cb2b6baa8c..dfb698b840 100644
--- a/blog/2014/03/19/react-v0.10-rc1.html
+++ b/blog/2014/03/19/react-v0.10-rc1.html
@@ -119,7 +119,7 @@ Minified build for production: 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
+
// This is a common pattern. However instance here really refers to a// "descriptor", not necessarily the mounted instance.varinstance=<MyComponent/>;React.renderComponent(instance);
diff --git a/blog/2014/03/21/react-v0.10.html b/blog/2014/03/21/react-v0.10.html
index 2372430318..5e1a2e2b70 100644
--- a/blog/2014/03/21/react-v0.10.html
+++ b/blog/2014/03/21/react-v0.10.html
@@ -119,7 +119,7 @@ Minified build for production: 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
+
// This is a common pattern. However instance here really refers to a// "descriptor", not necessarily the mounted instance.varinstance=<MyComponent/>;React.renderComponent(instance);
diff --git a/blog/2014/03/28/the-road-to-1.0.html b/blog/2014/03/28/the-road-to-1.0.html
index b454521864..a18e7d981d 100644
--- a/blog/2014/03/28/the-road-to-1.0.html
+++ b/blog/2014/03/28/the-road-to-1.0.html
@@ -106,7 +106,7 @@
This is really connected to everything. We want to keep the API as simple as possible and help developers fall into the pit of success. Enabling bad patterns with bad APIs is not success.
Before we even launched React publicly, members of the team were talking about how we could leverage ES6, namely classes, to improve the experience of creating React components. Calling React.createClass(...) isn't great. We don't quite have the right answer here yet, but we're close. We want to make sure we make this as simple as possible. It could look like this:
-
classMyComponentextendsReact.Component{
+
classMyComponentextendsReact.Component{render(){...}
diff --git a/blog/2014/04/04/reactnet.html b/blog/2014/04/04/reactnet.html
index 61b89c80f5..f9e149d723 100644
--- a/blog/2014/04/04/reactnet.html
+++ b/blog/2014/04/04/reactnet.html
@@ -101,14 +101,16 @@ in .NET applications, focusing specifically on ASP.NET MVC web applications.
It has several purposes:
-
On-the-fly JSX to JavaScript compilation. Simply reference JSX files and they
-will be compiled and cached server-side.
JSX to JavaScript compilation via popular minification/combination libraries
(Cassette and ASP.NET Bundling and Minification). This is suggested for
-production websites.
-
Server-side component rendering to make your initial render super fast.
+production websites.
+
Server-side component rendering to make your initial render super fast.
Even though we are focusing on ASP.NET MVC, ReactJS.NET can also be used in
diff --git a/blog/2014/07/13/react-v0.11-rc1.html b/blog/2014/07/13/react-v0.11-rc1.html
index f7901eb847..d647985ccb 100644
--- a/blog/2014/07/13/react-v0.11-rc1.html
+++ b/blog/2014/07/13/react-v0.11-rc1.html
@@ -117,7 +117,7 @@ Minified build for production: Rendering to null#
Since React's release, people have been using work arounds to "render nothing". Usually this means returning an empty <div/> or <span/>. Some people even got clever and started returning <noscript/> to avoid extraneous DOM nodes. We finally provided a "blessed" solution that allows developers to write meaningful code. Returning null is an explicit indication to React that you do not want anything rendered. Behind the scenes we make this work with a <noscript> element, though in the future we hope to not put anything in the document. In the mean time, <noscript> elements do not affect layout in any way, so you can feel safe using null today!
Another feature request we've been hearing for a long time is the ability to have namespaces in JSX. Given that JSX is just JavaScript, we didn't want to use XML namespacing. Instead we opted for a standard JS approach: object property access. Instead of assigning variables to access components stored in an object (such as a component library), you can now use the component directly as <Namespace.Component/>.
Keyboard events now contain a normalized e.key value according to the DOM Level 3 Events spec, allowing you to write simpler key handling code that works in all browsers, such as:
-
handleKeyDown:function(e){
+
handleKeyDown:function(e){if(e.key==='Enter'){// Handle enter key}elseif(e.key===' '){
diff --git a/blog/2014/07/17/react-v0.11.html b/blog/2014/07/17/react-v0.11.html
index 362c1bb8af..57cc8aac3a 100644
--- a/blog/2014/07/17/react-v0.11.html
+++ b/blog/2014/07/17/react-v0.11.html
@@ -123,7 +123,7 @@ Minified build for production: Rendering to null#
Since React's release, people have been using work arounds to "render nothing". Usually this means returning an empty <div/> or <span/>. Some people even got clever and started returning <noscript/> to avoid extraneous DOM nodes. We finally provided a "blessed" solution that allows developers to write meaningful code. Returning null is an explicit indication to React that you do not want anything rendered. Behind the scenes we make this work with a <noscript> element, though in the future we hope to not put anything in the document. In the mean time, <noscript> elements do not affect layout in any way, so you can feel safe using null today!
Another feature request we've been hearing for a long time is the ability to have namespaces in JSX. Given that JSX is just JavaScript, we didn't want to use XML namespacing. Instead we opted for a standard JS approach: object property access. Instead of assigning variables to access components stored in an object (such as a component library), you can now use the component directly as <Namespace.Component/>.
Keyboard events now contain a normalized e.key value according to the DOM Level 3 Events spec, allowing you to write simpler key handling code that works in all browsers, such as:
-
handleKeyDown:function(e){
+
handleKeyDown:function(e){if(e.key==='Enter'){// Handle enter key}elseif(e.key===' '){
diff --git a/blog/2014/07/28/community-roundup-20.html b/blog/2014/07/28/community-roundup-20.html
index 40b9850c91..d66a24c370 100644
--- a/blog/2014/07/28/community-roundup-20.html
+++ b/blog/2014/07/28/community-roundup-20.html
@@ -110,7 +110,7 @@
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.
+
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.
If you missed the last London React Meetup, the video is available, with lots of great content.
+
If you missed the last London React Meetup, the video is available, with lots of great content.
What's new in React 0.11 and how to improve performance by guaranteeing immutability
@@ -149,7 +149,7 @@
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!
As an application grows, dependencies across different stores are a near certainty. Store A will inevitably need Store B to update itself first, so that Store A can know how to update itself. We need the dispatcher to be able to invoke the callback for Store B, and finish that callback, before moving forward with Store A. To declaratively assert this dependency, a store needs to be able to say to the dispatcher, "I need to wait for Store B to finish processing this action." The dispatcher provides this functionality through its waitFor() method.
+
As an application grows, dependencies across different stores are a near certainty. Store A will inevitably need Store B to update itself first, so that Store A can know how to update itself. We need the dispatcher to be able to invoke the callback for Store B, and finish that callback, before moving forward with Store A. To declaratively assert this dependency, a store needs to be able to say to the dispatcher, "I need to wait for Store B to finish processing this action." The dispatcher provides this functionality through its waitFor() method.
The dispatch() method provides a simple, synchronous iteration through the callbacks, invoking each in turn. When waitFor() is encountered within one of the callbacks, execution of that callback stops and waitFor() provides us with a new iteration cycle over the dependencies. After the entire set of dependencies have been fulfilled, the original callback then continues to execute.
Ryan Florence and Michael Jackson ported Ember's router to React in a project called React Router. This is a very good example of both communities working together to make the web better!
While Matt Zabriskie was working on react-tabs he discovered how to use React.Children.map and React.addons.cloneWithProps in order to reference dynamic children.
Jason Brown adapted htmlparser2 to React: htmlparser2-react. That allows you to convert raw HTML to the virtual DOM.
This is not the intended way to use React but can be useful as last resort if you have an existing piece of HTML.
-
varhtml='<div data-id="1" class="hey this is a class" '+
+
varhtml='<div data-id="1" class="hey this is a class" '+'style="width:100%;height: 100%;"><article id="this-article">'+'<p>hey this is a paragraph</p><div><ul><li>1</li><li>2</li>'+'<li>3</li></ul></div></article></div>';
diff --git a/blog/index.html b/blog/index.html
index 95257c5634..cea9dec62d 100644
--- a/blog/index.html
+++ b/blog/index.html
@@ -97,7 +97,7 @@
Ryan Florence and Michael Jackson ported Ember's router to React in a project called React Router. This is a very good example of both communities working together to make the web better!
