React.js Conf Updates

November 24, 2014 by Vjeux


Yesterday was the React.js Conf call for presenters submission deadline. We were surprised to have received a total of one hundred talk proposals and were amazed that 600 people requested to be notified when ticket go on sale. This is incredible!

When we organized the conference, we decided to start small since this is the first React.js conference. Also, we weren't sure what level of demand to expect, so we planned for a single-track, two-day conference on Facebook's campus. The largest room available would accommodate 18 speaking slots and 200 attendees. The spacial configuration makes it difficult to add a second track and changing venues only two months in advance would be too difficult, so we are deciding to stick with the originally planned format and venue on Facebook's campus.

Unfortunately, this means that we can only accept a small number of the awesome conference talk proposals. In order to make sure attendees get a fair shot at registering, we're going to sell tickets in three separate first-come, first-serve phases. Tickets will cost $200 regardless of which phase they are purchased from and all proceeds will go to charity.

  • Friday November 28th 2014 — Noon PST: First wave of tickets
  • Friday December 5th 2014 — Noon PST: Second wave of tickets
  • Friday December 12th 2014 — Noon PST: Third and last wave of tickets

We really do wish that everyone could attend React.js Conf, but in order to ensure a quality experience for those who attend, we feel it will be best to limit the size of the conference to what was originally planned for. This means that not everyone who wants to attend will be able to, and many talks that would be excellent contributions to the conference will have to be postponed until the next conference. All the talks will be recorded and put online shortly after.

We hope to see many of you at React.js Conf this January.

Sincerely,

React Core Team

React v0.12

October 28, 2014 by Paul O’Shannessy


We're happy to announce the availability of React v0.12! After over a week of baking as the release candidate, we uncovered and fixed a few small issues. Thanks to all of you who upgraded and gave us feedback!

We have talked a lot about some of the bigger changes in this release. We introduced new terminology and changed APIs to clean up and simplify some of the concepts of React. We also made several changes to JSX and deprecated a few functions. We won't go into depth about these changes again but we encourage you to read up on these changes in the linked posts. We'll summarize these changes and discuss some of the other changes and how they may impact you below. As always, a full changelog is also included below.

The release is available for download:

We've also published version 0.12.0 of the react and react-tools packages on npm and the react package on bower.

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.

JSX Changes

We talked more in depth about these before, so here are the highlights.

  • No more /** @jsx React.DOM */!
  • We no longer transform to a straight function call. <Component/> now becomes React.createElement(Component)
  • DOM components don't make use of React.DOM, instead we pass the tag name directly. <div/> becomes React.createElement('div')
  • We introduced spread attributes as a quick way to transfer props.

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.

License Change - BSD

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.


Changelog

React Core

Breaking Changes

  • key and ref moved off props object, now accessible on the element directly
  • React is now BSD licensed with accompanying Patents grant
  • Default prop resolution has moved to Element creation time instead of mount time, making them effectively static
  • React.__internals is removed - it was exposed for DevTools which no longer needs access
  • Composite Component functions can no longer be called directly - they must be wrapped with React.createFactory first. This is handled for you when using JSX.

New Features

  • Spread operator ({...}) introduced to deprecate this.transferPropsTo
  • Added support for more HTML attributes: acceptCharset, classID, manifest

Deprecations

  • React.renderComponent --> React.render
  • React.renderComponentToString --> React.renderToString
  • React.renderComponentToStaticMarkup --> React.renderToStaticMarkup
  • React.isValidComponent --> React.isValidElement
  • React.PropTypes.component --> React.PropTypes.element
  • React.PropTypes.renderable --> React.PropTypes.node
  • DEPRECATED React.isValidClass
  • DEPRECATED instance.transferPropsTo
  • DEPRECATED Returning false from event handlers to preventDefault
  • DEPRECATED Convenience Constructor usage as function, instead wrap with React.createFactory
  • DEPRECATED use of key={null} to assign implicit keys

Bug Fixes

  • Better handling of events and updates in nested results, fixing value restoration in "layered" controlled components
  • Correctly treat event.getModifierState as case sensitive
  • Improved normalization of event.charCode
  • Better error stacks when involving autobound methods
  • Removed DevTools message when the DevTools are installed
  • Correctly detect required language features across browsers
  • Fixed support for some HTML attributes:
    • list updates correctly now
    • scrollLeft, scrollTop removed, these should not be specified as props
  • Improved error messages

React With Addons

New Features

  • React.addons.batchedUpdates added to API for hooking into update cycle

Breaking Changes

  • React.addons.update uses assign instead of copyProperties which does hasOwnProperty checks. Properties on prototypes will no longer be updated correctly.

Bug Fixes

  • Fixed some issues with CSS Transitions

JSX

Breaking Changes

  • Enforced convention: lower case tag names are always treated as HTML tags, upper case tag names are always treated as composite components
  • JSX no longer transforms to simple function calls

New Features

  • @jsx React.DOM no longer required
  • spread ({...}) operator introduced to allow easier use of props

Bug Fixes

  • JSXTransformer: Make sourcemaps an option when using APIs directly (eg, for react-rails)

React.js Conf

October 27, 2014 by Vjeux


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!

Community Round-up #23

October 17, 2014 by Lou Husson


This round-up is a special edition on Flux. If you expect to see diagrams showing arrows that all point in the same direction, you won't be disappointed!

React And Flux at ForwardJS

Facebook engineers Jing Chen and Bill Fisher gave a talk about Flux and React at ForwardJS, and how using an application architecture with a unidirectional data flow helped solve recurring bugs.

Yahoo

Yahoo is converting Yahoo Mail to React and Flux and in the process, they open sourced several components. This will help you get an isomorphic application up and running.

Reflux

Mikael Brassman wrote Reflux, a library that implements Flux concepts. Note that it diverges significantly from the way we use Flux at Facebook. He explains the reasons why in a blog post.

React and Flux Interview

Ian Obermiller, engineer at Facebook, made a lengthy interview on the experience of using React and Flux in order to build probably the biggest React application ever written so far.

I’ve actually said this many times to my team too, I love React. It’s really great for making these complex applications. One thing that really surprised me with it is that React combined with a sane module system like CommonJS, and making sure that you actually modulize your stuff properly has scaled really well to a team of almost 10 developers working on hundreds of files and tens of thousands of lines of code.

Really, a fairly large code base... stuff just works. You don’t have to worry about mutating, and the state of the DOM just really makes stuff easy. Just conceptually it’s easier just to think about here’s what I have, here’s my data, here’s how it renders, I don’t care about anything else. For most cases that is really simplifying and makes it really fast to do stuff.

Read the full interview...

Adobe's Brackets Project Tree

Kevin Dangoor is converting the project tree of Adobe's Bracket text editor to React and Flux. He wrote about his experience using Flux.

Async Requests with Flux Revisited

Reto Schläpfer came back to a Flux project he hasn't worked on for a month and saw many ways to improve the way he implemented Flux. He summarized his learnings in a blog post.

The smarter way is to call the Web Api directly from an Action Creator and then make the Api dispatch an event with the request result as a payload. The Store(s) can choose to listen on those request actions and change their state accordingly.

Before I show some updated code snippets, let me explain why this is superior:

  • There should be only one channel for all state changes: The Dispatcher. This makes debugging easy because it just requires a single console.log in the dispatcher to observe every single state change trigger.

  • Asynchronously executed callbacks should not leak into Stores. The consequences of it are just too hard to fully foresee. This leads to elusive bugs. Stores should only execute synchronous code. Otherwise they are too hard to understand.

  • Avoiding actions firing other actions makes your app simple. We use the newest Dispatcher implementation from Facebook that does not allow a new dispatch while dispatching. It forces you to do things right.

Read the full article...

Undo-Redo with Immutable Data Structures

Ameya Karve explained how to use Mori, a library that provides immutable data structures, in order to implement undo-redo. This usually very challenging feature only takes a few lines of code with Flux!

undo: function() {
  this.redoStates = Mori.conj(this.redoStates, Mori.first(this.undoStates));
  this.undoStates = Mori.drop(1, this.undoStates);
  this.todosState = Mori.first(this.undoStates);
  this.canUndo = Mori.count(this.undoStates) > 1;
  this.canRedo = true;
  if (Mori.count(this.undoStates) > 1) {
    this.todos = JSON.parse(this.todosState);
  } else {
    this.todos = [];
  }
  this.emit('change');
},

Flux in practice

Gary Chambers wrote a guide to get started with Flux. This is a very practical introduction to Flux.

So, what does it actually mean to write an application in the Flux way? At that moment of inspiration, when faced with an empty text editor, how should you begin? This post follows the process of building a Flux-compliant application from scratch.

Read the full guide...

Components, React and Flux

Dan Abramov working at Stampsy made a talk about React and Flux. It's a very good overview of the concepts at play.

React and Flux

Christian Alfoni wrote an article where he compares Backbone, Angular and Flux on a simple example that's representative of a real project he worked on.

Wow, that was a bit more code! Well, try to think of it like this. In the above examples, if we were to do any changes to the application we would probably have to move things around. In the FLUX example we have considered that from the start.

Any changes to the application is adding, not moving things around. If you need a new store, just add it and make components dependant of it. If you need more views, create a component and use it inside any other component without affecting their current "parent controller or models".

Read the full article...

Flux: Step by Step approach

Nicola Paolucci from Atlassian wrote a great guide to help your getting understand Flux step by step.

DeLorean: Back to the future!

DeLorean is a tiny Flux pattern implementation developed by Fatih Kadir Akin.

  • Unidirectional data flow, it makes your app logic simpler than MVC
  • Automatically listens to data changes and keeps your data updated
  • Makes data more consistent across your whole application
  • It's framework agnostic, completely. There's no view framework dependency
  • Very small, just 4K gzipped
  • Built-in React.js integration, easy to use with Flight.js and Ractive.js and probably all others
  • Improve your UI/data consistency using rollbacks

Facebook's iOS Infrastructure

Last but not least, Flux and React ideas are not limited to JavaScript inside of the browser. The iOS team at Facebook re-implemented Newsfeed using very similar patterns.

Random Tweet

React v0.12 RC

October 16, 2014 by Sebastian Markbåge


We are finally ready to share the work we've been doing over the past couple months. A lot has gone into this and we want to make sure we iron out any potential issues before we make this final. So, we're shipping a Release Candidate for React v0.12 today. If you get a chance, please give it a try and report any issues you find! A full changelog will accompany the final release but we've highlighted the interesting and breaking changes below.

The release candidate is available for download:

We've also published version 0.12.0-rc1 of the react and react-tools packages on npm and the react package on bower.

React Elements

The biggest conceptual change we made in v0.12 is the move to React Elements. We talked about this topic in depth earlier this week. If you haven't already, you should read up on the exciting changes in there!

JSX Changes

Earlier this year we decided to write a specification for JSX. This has allowed us to make some changes focused on the React specific JSX and still allow others to innovate in the same space.

The @jsx Pragma is Gone!

We have wanted to do this since before we even open sourced React. No more /** @jsx React.DOM */!. The React specific JSX transform assumes you have React in scope (which had to be true before anyway).

JSXTransformer and react-tools have both been updated to account for this.

JSX for Function Calls is No Longer Supported

The React specific JSX transform no longer transforms to function calls. Instead we use React.createElement and pass it arguments. This allows us to make optimizations and better support React as a compile target for things like Om. Read more in the React Elements introduction.

The result of this change is that we will no longer support arbitrary function calls. We understand that the ability to do was a convenient shortcut for many people but we believe the gains will be worth it.

JSX Lower-case Convention

We used to have a whitelist of HTML tags that got special treatment in JSX. However as new HTML tags got added to the spec, or we added support for more SVG tags, we had to go update our whitelist. Additionally, there was ambiguity about the behavior. There was always the chance that something new added to the tag list would result in breaking your code. For example:

return <component />;

Is component an existing HTML tag? What if it becomes one?

To address this, we decided on a convention: All JSX tags that start with a lower-case letter or contain a dash are treated as HTML.

This means that you no longer have to wait for us to upgrade JSX to use new tags. This also introduces the possibility to consume custom elements (Web Components) - although custom attributes are not yet fully supported.

Currently we still use the whitelist as a sanity check. The transform will fail when it encounters an unknown tag. This allows you to update your code without hitting errors in production.

In addition, the HTML tags are converted to strings instead of using React.DOM directly. <div/> becomes React.createElement('div') instead of React.DOM.div().

JSX Spread Attributes

Previously there wasn't a way to for you to pass a dynamic or unknown set of properties through JSX. This is now possible using the spread ... operator.

var myProps = { a: 1, b: 2 };
return <MyComponent {...myProps} />;

This merges the properties of the object onto the props of MyComponent.

Read More About Spread Attributes

If you used to use plain function calls to pass arbitrary props objects...

return MyComponent(myProps);

You can now switch to using Spread Attributes instead:

return <MyComponent {...myProps} />;

Breaking Change: key and ref Removed From this.props

The props key and ref were already reserved property names. This turned out to be difficult to explicitly statically type since any object can accept these extra props. It also screws up JIT optimizations of React internals in modern VMs.

These are concepts that React manages from outside the Component before it even gets created so it shouldn't be part of the props.

We made this distinction clearer by moving them off the props object and onto the ReactElement itself. This means that you need to rename:

someElement.props.key -> someElement.key

You can no longer access this.props.ref and this.props.key from inside the Component instance itself. So you need to use a different name for those props.

You do NOT need to change the way to define key and ref, only if you need to read it. E.g. <div key="my-key" /> and div({ key: 'my-key' }) still works.

Breaking Change: Default Props Resolution

This is a subtle difference but defaultProps are now resolved at ReactElement creation time instead of when it's mounted. This is means that we can avoid allocating an extra object for the resolved props.

You will primarily see this breaking if you're also using transferPropsTo.

Deprecated: transferPropsTo

transferPropsTo is deprecated in v0.12 and will be removed in v0.13. This helper function was a bit magical. It auto-merged a certain whitelist of properties and excluded others. It was also transferring too many properties. This meant that we have to keep a whitelist of valid HTML attributes in the React runtime. It also means that we can't catch typos on props.

Our suggested solution is to use the Spread Attributes.

return <div {...this.props} />;

Or, just if you're not using JSX:

return div(this.props);

Although to avoid passing too many props down, you'll probably want to use something like ES7 rest properties. Read more about upgrading from transferPropsTo.

Deprecated: Returning false in Event Handlers

It used to be possible to return false from event handlers to preventDefault. We did this because this works in most browsers. This is a confusing API and we might want to use the return value for something else. Therefore, this is deprecated. Use event.preventDefault() instead.

Renamed APIs

As part of the new React terminology we aliased some existing APIs to use the new naming convention:

  • React.renderComponent -> React.render
  • React.renderComponentToString -> React.renderToString
  • React.renderComponentToStaticMarkup -> React.renderToStaticMarkup
  • React.isValidComponent -> React.isValidElement
  • React.PropTypes.component -> React.PropTypes.element
  • React.PropTypes.renderable -> React.PropTypes.node

The older APIs will log a warning but work the same. They will be removed in v0.13.