ReactEurope Round-up

August 13, 2015 by Matthew Johnston


Last month, the first React.js European conference took place in the city of Paris, at ReactEurope. Attendees were treated to a range of talks covering React, React Native, Flux, Relay, and GraphQL. Big thanks to everyone involved with organizing the conference, to all the attendees, and everyone who gave their time to speak - it wouldn't have been possible without the help and support of the React community.

Christopher Chedeau gave the opening keynote to the conference:

Spencer Ahrens walks through building an advanced gestural UI leveraging the unique power of the React Native layout and animation systems to build a complex and fluid experience:

Lee Byron explores GraphQL, its core principles, how it works, and what makes it a powerful tool:

Joseph Savona explores the problems Relay solves, its architecture and the query lifecycle, and how can you use Relay to build more scalable apps. There are examples of how Relay powers applications as complex as the Facebook News Feed:

Nick Schrock and Dan Schafer take a deeper dive into putting GraphQL to work. How can we build a GraphQL API to work with an existing REST API or server-side data model? What are best practices when building a GraphQL API, and how do they differ from traditional REST best practices? How does Facebook use GraphQL? Most importantly, what does a complete and coherent GraphQL API looks like, and how can we get started building one?

Sebastian Markbåge talks about why the DOM is flawed and how it is becoming a second-class citizen in the land of React apps:

Sebastian McKenzie goes over how existing JSX build pipeline infrastructure can be further utilised to perform even more significant code transformations such as transpilation, optimisation, profiling and more, reducing bugs, making your code faster and you as a developer more productive and happy:

Cheng Lou gives a talk on the past, the present and the future of animation, and the place React can potentially take in this:

And there was a Q&A session with the whole team covering a range of React topics:

And there were lots of great talks from the React community:

  • Michael Chan looks at how to solve problems like CSS theming and media queries with contexts and plain old JavaScript. He also looks at the role of container-components and when it's better to "just use CSS.".
  • Elie Rotenberg talks about Flux over the Wire, building isomorphic, real-time React apps using a novel interpretation of Flux.
  • Ryan Florence says “Your front and back ends are already successfully in production but you don't have to miss out on the productivity that React brings. Forget the rewrites, this is brownfield!”.
  • Dan Abramov demonstrates how React can be used together with Webpack Hot Module Replacement to create a live editing environment with time travel that supercharges your debugging experience and transforms the way you work on real apps every day.
  • Mikhail Davydov shows you how to ask the browser layout engine for help, how to avoid slavery of DSL, and build declarative Text UI using only web-technologies like HTML, JS, CSS and React.
  • Kevin Robinson shares how user experience choices are a primary influence on how Twitter design the data layer, especially for teams developing new products with full-stack capabilities.
  • Jed Watson shares what Thinkmill have learned about React and mobile app development, and how they've approached the unique challenges of mobile web apps - with tools that are useful to all developers building touch interfaces with React, as well as a walkthrough of their development process and framework.
  • Michael Jackson discusses how your users can benefit from the many tools that React Router provides including server-side rendering, real URLs on native devices, and much, much more.
  • Michael Ridgway walks you through an isomorphic Flux architecture to give you the holy grail of frontend development.
  • Aria Buckles covers Khan Academy's techniques and patterns to make dealing with large pure components simpler, as well as current open questions.
  • Evan Morikawa and Ben Gotow talk about specific features of React & Flux, React CSS, programming design patterns, and custom libraries, which can turn a static application into a dynamic platform that an ecosystem of developers can build on top of.
  • Zalando, Rangle.io, Automattic, Thinkmill, and Red Badger provided lots of insight into how larger companies are using React.

There was also a great series of Lightning talks from Joshua Sierles, Ovidiu Cherecheș, Mike Grabowski, Dave Brotherstone, Sunil Pai, Andreas Savvides, and Petr Bela.

You can view the full list of talks on the ReactEurope YouTube channel.

Relay Technical Preview

August 11, 2015 by Joseph Savona


Relay #

Today we're excited to share an update on Relay - the technical preview is now open-source and available on GitHub.

Why Relay #

While React simplified the process of developing complex user-interfaces, it left open the question of how to interact with data on the server. It turns out that this was a significant source of friction for our developers; fragile coupling between client and server caused data-related bugs and made iteration harder. Furthermore, developers were forced to constantly re-implement complex async logic instead of focusing on their apps. Relay addresses these concerns by borrowing important lessons from React: it provides declarative, component-oriented data fetching for React applications.

Declarative data-fetching means that Relay applications specify what data they need, not how to fetch that data. Just as React uses a description of the desired UI to manage view updates, Relay uses a data description in the form of GraphQL queries. Given these descriptions, Relay coalesces queries into batches for efficiency, manages error-prone asynchronous logic, caches data for performance, and automatically updates views as data changes.

Relay is also component-oriented, extending the notion of a React component to include a description of what data is necessary to render it. This colocation allows developers to reason locally about their application and eliminates bugs such as under- or over-fetching data.

Relay is in use at Facebook in production apps, and we're using it more and more because Relay lets developers focus on their products and move fast. It's working for us and we'd like to share it with the community.

What's Included #

We're open-sourcing a technical preview of Relay - the core framework that we use internally, with some modifications for use outside Facebook. As this is the first release, it's good to keep in mind that there may be some incomplete or missing features. We'll continue to develop Relay and are working closely with the GraphQL community to ensure that Relay tracks updates during GraphQL's RFC period. But we couldn't wait any longer to get this in your hands, and we're looking forward to your feedback and contributions.

Relay is available on GitHub and npm.

What's Next #

The team is super excited to be releasing Relay - and just as excited about what's next. Here are some of the things we'll be focusing on:

  • Offline support. This will allow applications to fulfill queries and enqueue updates without connectivity.
  • Real-time updates. In collaboration with the GraphQL community, we're working to define a specification for subscriptions and provide support for them in Relay.
  • A generic Relay. Just as the power of React was never about the virtual DOM, Relay is much more than a GraphQL client. We're working to extend Relay to provide a unified interface for interacting not only with server data, but also in-memory and native device data (and, even better, a mix of all three).
  • Finally, it's all too easy as developers to focus on those people with the newest devices and fastest internet connections. We're working to make it easier to build applications that are robust in the face of slow or intermittent connectivity.

Thanks!

New React Devtools Beta

August 3, 2015 by Jared Forsyth


We've made an entirely new version of the devtools, and we want you to try it out!

The full devtools gif

Why entirely new? #

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.

What are the benefits? #

  • 100% React
  • Firefox compatible
  • React Native compatible
  • more extensible & hackable

Are there any new features? #

Yeah!

The Tree View #

The new tree view of the devtools

  • Much richer view of your props, including the contents of objects and arrays
  • Custom components are emphasized, native components are de-emphasized
  • Stateful components have a red collapser
  • Improved keyboard navigation (hjkl or arrow keys)
  • Selected component is available in the console as $r
  • Props that change highlight in green
  • Right-click menu

    • Scroll node into view
    • Show the source for a component in the "Sources" pane
    • Show the element in the "Elements" pane

Searching #

Select the search bar (or press "/"), and start searching for a component by name.

The Side Pane #

  • Now shows the context for a component
  • Right-click to store a prop/state value as a global variable

How do I install it? #

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.

Also Firefox! #

We also have an initial version of the devtools for Firefox, which you can download from the same release page.

Feedback welcome #

Let us know what issues you run into on GitHub, and check out the README for more info.

Update #

August 12, 2015

A second beta is out, with a number of bugfixes. It is also listed on the releases page.

React v0.14 Beta 1

July 3, 2015 by Ben Alpert


This week, many people in the React community are at ReactEurope in the beautiful (and very warm) city of Paris, the second React conference that's been held to date. At our last conference, we released the first beta of React 0.13, and we figured we'd do the same today with our first beta of React 0.14, giving you something to play with if you're not at the conference or you're looking for something to do on the way home.

With React 0.14, we're continuing to let React mature and to make minor changes as the APIs continue to settle down. I'll talk only about the two largest changes in this blog post; when we publish the final release we'll be sure to update all of our documentation and include a full changelog.

You can install the new beta with npm install react@0.14.0-beta1 and npm install react-dom@0.14.0-beta1. As mentioned in Deprecating react-tools, we're no longer updating the react-tools package so this release doesn't include a new version of it. Please try the new version out and let us know what you think, and please do file issues on our GitHub repo if you run into any problems.

Two Packages #

As we look at packages like react-native, react-art, react-canvas, and react-three, it's become clear that the beauty and essence of React has nothing to do with browsers or the DOM.

We think the true foundations of React are simply ideas of components and elements: being able to describe what you want to render in a declarative way. These are the pieces shared by all of these different packages. The parts of React specific to certain rendering targets aren't usually what we think of when we think of React. As one example, DOM diffing currently enables us to build React for the browser and make it fast enough to be useful, but if the DOM didn't have a stateful, imperative API, we might not need diffing at all.

To make this more clear and to make it easier to build more environments that React can render to, we're splitting the main react package into two: react and react-dom.

The react package contains React.createElement, React.createClass and React.Component, React.PropTypes, React.Children, and the other helpers related to elements and component classes. We think of these as the isomorphic or universal helpers that you need to build components.

The react-dom package contains ReactDOM.render, ReactDOM.unmountComponentAtNode, and ReactDOM.findDOMNode, and in react-dom/server we have server-side rendering support with ReactDOMServer.renderToString and ReactDOMServer.renderToStaticMarkup.

var React = require('react');
var ReactDOM = require('react-dom');

var MyComponent = React.createClass({
  render: function() {
    return <div>Hello World</div>;
  }
});

ReactDOM.render(<MyComponent />, node);

We anticipate that most components will need to depend only on the react package, which is lightweight and doesn't include any of the actual rendering logic. To start, we expect people to render DOM-based components with our react-dom package, but there's nothing stopping someone from diving deep on performance and writing a awesome-faster-react-dom package which can render the exact same DOM-based components. By decoupling the component definitions from the rendering, this becomes possible.

More importantly, this paves the way to writing components that can be shared between the web version of React and React Native. This isn't yet easily possible, but we intend to make this easy in a future version so you can share React code between your website and native apps.

The addons have moved to separate packages as well: react-addons-clone-with-props, react-addons-create-fragment, react-addons-css-transition-group, react-addons-linked-state-mixin, react-addons-pure-render-mixin, react-addons-shallow-compare, react-addons-transition-group, and react-addons-update, plus ReactDOM.unstable_batchedUpdates in react-dom.

For now, please use the same version of react and react-dom in your apps to avoid versioning problems -- but we plan to remove this requirement later. (This release includes the old methods in the react package with a deprecation warning, but they'll be removed completely in 0.15.)

DOM node refs #

The other big change we're making in this release is exposing refs to DOM components as the DOM node itself. That means: we looked at what you can do with a ref to a DOM component and realized that the only useful thing you can do with it is call this.refs.giraffe.getDOMNode() to get the underlying DOM node. In this release, this.refs.giraffe is the actual DOM node.

Refs to custom component classes work exactly as before.

var Zoo = React.createClass({
  render: function() {
    return (
      <div>
        Giraffe's name: <input ref="giraffe" />
      </div>
    );
  },

  showName: function() {
    // Previously:
    // var input = this.refs.giraffe.getDOMNode();
    var input = this.refs.giraffe;

    alert(input.value);
  }
});

This change also applies to the return result of ReactDOM.render when passing a DOM node as the top component. As with refs, this change does not affect custom components (eg. <MyFancyMenu> or <MyContextProvider>), which remain unaffected by this change.

Along with this change, we're also replacing component.getDOMNode() with ReactDOM.findDOMNode(component). The findDOMNode method drills down to find which DOM node was rendered by a component, but it returns its argument when passed a DOM node so it's safe to call on a DOM component too. We introduced this function quietly in the last release, but now we're deprecating .getDOMNode() completely: it should be easy to change all existing calls in your code to be ReactDOM.findDOMNode. We also have an automated codemod script to help you with this transition. Note that the findDOMNode calls are unnecessary when you already have a DOM component ref (as in the example above), so you can (and should) skip them in most cases going forward.

We hope you're as excited about this release as we are! Let us know what you think of it.

Deprecating JSTransform and react-tools

June 12, 2015 by Paul O’Shannessy


Today we're announcing the deprecation of react-tools and JSTransform.

As many people have noticed already, React and React Native have both switched their respective build systems to make use of Babel. This replaced JSTransform, the source transformation tool that we wrote at Facebook. JSTransform has been really good for us over the past several years, however as the JavaScript language continues to evolve, the architecture we used has begun to show its age. We've faced maintenance issues and lagged behind implementing new language features. Last year, Babel (previously 6to5) exploded onto the scene, implementing new features at an amazing pace. Since then it has evolved a solid plugin API, and implemented some of our non-standard language features (JSX and Flow type annotations).

react-tools has always been a very thin wrapper around JSTransform. It has served as a great tool for the community to get up and running, but at this point we're ready to let it go. We won't ship a new version for v0.14.

Migrating to Babel #

Many people in the React and broader JavaScript community have already adopted Babel. It has integrations with a number of tools. Depending on your tool, you'll want to read up on the instructions.

We've been working with the Babel team as we started making use of it and we're confident that it will be the right tool to use with React.

Other Deprecations #

esprima-fb #

As a result of no longer maintaining JSTransform, we no longer have a need to maintain our Esprima fork (esprima-fb). The upstream Esprima and other esprima-based forks, like Espree, have been doing an excellent job of supporting new language features recently. If you have a need of an esprima-based parser, we encourage you to look into using one of those.

Alternatively, if you need to parse JSX, take a look at acorn parser in combination with acorn-jsx plugin which is used inside of Babel and thus always supports the latest syntax.

JSXTransformer #

JSXTransformer is another tool we built specifically for consuming JSX in the browser. It was always intended as a quick way to prototype code before setting up a build process. It would look for <script> tags with type="text/jsx" and then transform and run. This ran the same code that react-tools ran on the server. Babel ships with a nearly identical tool, which has already been integrated into JS Bin.

We'll be deprecating JSXTransformer, however the current version will still be available from various CDNs and Bower.