reactjs / react-future

Specs & docs for potential future and experimental React APIs and JavaScript syntax.

The Future of React(?)

Welcome to the potential future of React projects. This repo is showcasing example code for APIs that we have not yet implemented nor agreed on. Its purpose is to provide a platform for discussing future changes. It also provides a shared goal so that we can figure out how to incrementally get to our ideal API.

Structure

You'll notice that the files in this repo are structured by numbered files. More stable proposals have lower numbers and more comments. Higher level proposals are built on top of these. You're expected to be familiar with the core proposals before reading the higher level examples.

Core

1. [Classes](./01 - Core/01 - Classes.js)
2. [Mixins](./01 - Core/02 - Mixins.js)
3. [Stateless Functions](./01 - Core/03 - Stateless Functions.js)
4. [Modules](./01 - Core/04 - Modules.js)
5. [Elements](./01 - Core/05 - Elements.js)
6. [Refs](./01 - Core/06 - Refs.js)
7. [Imperative Bridge](./01 - Core/07 - Imperative Bridge.js)

Web Components

• (TBD)

Animations

• (TBD)

Layout

1. [Primitives](./04 - Layout/01 - Primitives.js)
2. [Layout Components](./04 - Layout/02 - Layout Components.js)
3. [Usage](./04 - Layout/03 - Usage.js)
4. [Inline Styles](./04 - Layout/04 - Inline Styles.md)

Workers

1. [Serializable Elements](./05 - Workers/01 - Serializable Elements.js)
2. [Nested Components](./05 - Workers/02 - Nested Components.js)

Embedded Queries

• (TBD)

Returning State

1. [Stateful Functions](./07 - Returning State/01 - Stateful Functions.js)
2. [Module Pattern](./07 - Returning State/02 - Module Pattern.js)
3. [Default Props and Initial State](./07 - Returning State/03 - Default Props and Initial State.js)

Types

1. [Elements](./08 - Types/01 - Elements.js)
2. [DOM Elements](./08 - Types/02 - DOM Elements.js)

Syntax

The language syntax used here is using a hypothetical future JavaScript syntax. It's a mix of ECMAScript 6, proposals for ECMAScript 7, TypeScript and JSX. The idea is that it should be proposals that have a legitimate chance of being standardized.

Contribute

Would you like to take part of the discussion? Open up an issue or pull request.

react-future's Issues

Generators for async sequences

Looking at the latest update in 05 - Async, I really like the syntax coming together here. It seems to give you most of what you need to write components as functions, with the additional benefit of async ordered actions, and what looks to be some sort of first-class redux style internal dispatch system.

I'd like to implement this. I've actually come up with a syntax very similar that we've been testing (emailed you a while back), and it's actually not too far off of this.

One big question comes up. This seems to either imply that you are re-instantiating the move function every time the view renders, or you are simply not showing a way to have a render() function equivalent. That being one of the big upsides of React, I'm curious.

I could imagine extending it to be something like this:

let Foo : Component<PropTypes> = ({ state = initState, props, update, dispatch }) => {
  function* move({ x, y }, cancelMove) {
    yield state.cancelMove()
    yield update({ ...state, cancelMove, x, y, })
    yield sleep(500)
    yield dispatch({ action: 'STOPPED_MOVING' })
    yield update({ ...state, stops: stops + 1 })
    yield props.onStop({
      lastPosition: [state.x, state.y]
    }, cancel)
  }

  return (props, state) => {

    // do stuff..

    return (
      <div
        onMouseMove={move}
        onMouseLeave={e => state.cancelMove()}>
        Stopped moving {state.stops} times.
      </div>
    )
  }
}

Where the returned function now lets you react to things. Though this adds a bit of verbosity and repitition. I could be way off though here, is it really not a big deal to re-instantiate functions within the render? Or was this just a simple sketch and hasn't accounted for the render function case.

Passing styles around should be discouraged

From: https://github.com/reactjs/react-future/blob/master/04%20-%20Layout/04%20-%20Inline%20Styles.md#pass-styles-around

This pattern promotes a leaky abstraction where components are unable to fully understand their styling unless they also know their call-sites. It's the stylistic equivalent of PropTypes.any. If components need to style their children, they should do so through well defined interfaces. One possible compromise is to have the StylePropType helper validate certain properties and values.

Usage of super in mixins

From what I understand of es6 specs, and in other languages like typescript, super() is reserved for super constructor call, in the mixins proposal would not super.method() makes more sense ?

class B {
  static getQueries() {
    super.getQueries(); // This will end up calling an empty function, placed by mixin()
    console.log('B')
  }

  componentDidMount() {
    console.log('B');
    super.componentDidMount(); // This will end up calling A.componentDidMount
  }
}

Killing React.createElement

Problem

import React from 'react';
React.createElement();

Solution

Add to ReactDOM.render() and AppRegistry.registerComponent():

function prerender (tempalte) {
    if (typeof template !== 'object') {
        return template;
    }
    let { props: { children }} = template;
    delete template.props.children;
    return React.createElement(template.type, template.props, template.children.map(child => prerender(child)));
   
}

and

<div className="card">
    <span>hello</span>
</div>

will become

({
    type: 'div',
    props: {
        className: 'card',
        children: [
            {
                type: 'span',
                children: 'hello'
            }
        ]
    }
})

Why

• The importance of semantic markup
• React should not be a dev dependency for small modules it takes too much time to use. More than that if PropTypes will go native now no imports at all except for helpers!!!

Cached Data

Is it possible to make the react-dom diff from the cache instead as well as you code? Say you are making a server render call, and the data could be cached. Instead of rendering again, react-dom diffs your render all and sends it directly to the cache.

A personal, (and a bit insane twist) would be to delete the server-sided code once everything has been cached/called. But this doesn't scale very well..

Knowing which of these made it into 0.14

Is there any easy way to know what's in here that's in 0.14, such as https://github.com/reactjs/react-future/blob/master/01%20-%20Core/03%20-%20Stateless%20Functions.js

Stateless Functions are already implemented

React compiling down to raw application code

Ahead of Time compiling is becoming a thing in the ever evolving Javascript world. At the end of the day, web frameworks simply have to change (virtual) DOM nodes at the appropriate time. Framework specific logic, like change detection, re-rendering and diffing, etc, are simply ways of letting developers be able to reason about when they expect a change to occur in the DOM.

If a compile step can intimately understand all the code paths a certain application can take, web applications don't have to incur the overhead of implementing the entire framework logic.

Angular is doing it in a limited way and a recent library svelte is requiring AOT compilation.

I'm not sure if this is the right location for this discussion, but I think this is something that the React community seriously needs to begin considering.

TypeScript Definition Files

Leaving this here to remind me of an idea I had for TypeScript definition files.

Lifecycle methods: drop the 'component'. just 'willMount'. it's cleaner

Pardon the stupid joke.

I was curious what was the rationale (if there is one) behind having 'component' in the lifecycle methods. To me it seems unnecessary as they are clearly in the context of a component. What would make sense to me though is grouping the lifecycle methods like this:

class Example extends React.Component {

  lifecycle: {
    willMount() {...},
    didMount() {...},
    willReceiveProps() {...},
    //especially weird that shouldComponentUpdate is the only method that has 'component' in the middle
    shouldUpdate() {...},
    willUpdate() {...},
    didUpdate() {...},
    willUnmount() {...},
  }  

}

App breaks if i try to directly access the url - With Error - Choose is not defined

My App works properly without any issues if I use links to navigate. but when I try to access the URL where component makes use of "jsx-control-statements" tags like Choose when it breaks with ReferenceError: Choose is not defined.

Can Someone help me figure out this issue?

JSX syntax for merging props

We need some nicer sugar for this new transferring pattern:

Transfer DOM props using merge strategy for className, style, aria, data. Ideally, this could just be a deepMerge all the time if className was an array:

var button = React.DOM.button(React.DOM.merge(
  this.props,
  {
    className: 'FancyButton',
    style: {
      backgroundColor: this.props.color,
      padding: 10,
      width: this.props.width - 10,
      height: this.props.height - 10
    },
    color: undefined,
    size: undefined
  }
));

Transfer props using deep merge:

var wideFancyButton = FancyButton(mergeDeep(
  this.props,
  {
    size: {
      width: 1000 // override width
    }
  }
));

Transfer props using flat merge:

var myButton = WideFancyButton(merge(
  this.props,
  {
    size: {
      width: 100, // will be overridden
      height: 100
    }
  }
));

Is it enough to just add syntax support for the deepMerge scenario? Flat merge is important for custom complex types in props.

Add new properties: `classNames` and `styles`

After having programmed in React Native for two years and having finally returned to the web, I am horrified by all the boilerplate involved in conditionally applying styles. The pattern adopted by the community at large and by React Native is to iterate over an array of styles or classnames, filter out falsey values, and then merge the result. See the classnames package with over 4.5 million downloads for proof that this is a need in the community as well as the success of React Native and React Native Web which follow this pattern.

In order to maintain backwards compatibility, I propose keeping the properties style and className as specced, but then adding two additional properties styles and classNames which have the falsey filtering behavior described above. In the case both style and styles are defined on the component, the resulting objects would simply be merged with style taking precedence (similarly for className and classNames).

working around with specificity and autoprefixer

How do we work around with the specificity problem if we are declaring styles inline? 1.0.0.0?

One common use case is if you want to reuse a component and just change it slightly, like more padding or with different color? If you duplicate that component then you are not using the DRY principle.

Another question is about leveraging the power of autoprefixer which you can hook up with caniuse service and figure out what property should have prefix, special usecase is flex.

Last question is how to circumvent repetitions of styles if we're doing inline styles. Say instead of reusing classes, now we're reusing a lot of inline styles?

I would also like to note that yahoo has a quite different approach and was comparing it against inline styles. They call it Atomic CSS. http://www.smashingmagazine.com/2013/10/21/challenging-css-best-practices-atomic-approach/

cc @vjeux

Classes - 1

Isn't it possible to take the render(props, etc, etc) with arguments, and pass it as a stateless function, that loads externally on demand instead on as a group with prefixed parameters?

Consider allowing attribute logic

Edit: For those of you reading this thread through from the beginning to get some context, below is the original post which uses the example of an if={condition} attribute directive. However, upon further discussion this is actually a bad example. Really the primary purpose of an attribute directive would be to "sprinkle" behavior onto existing components without modifying their core functionality. For example, a better instance of this would be something like a <img tooltip="message"/>, where the tooltip directive simply sprinkles on tooltip functionality onto the image component.

You can read down for more discussion, but basically this behavior could be implemented easily enough by making attribute logic simply syntactic sugar for wrapper components (e.g. <Tooltip message='message'><img/></Tooltip>. There are some fiddly bits to iron out (particularly with parameter passing and order of invocation) and desirability (some think it's an abuse of the proper purpose of components) but it is is technically possible.

Original post follows:

There's lots of use cases where working with attributes is a whole lot more convenient than working with components, making the code more terse and readable.

Compare

<if condition={true}>
  <span>Hello world</span>
</if>

to

<span *jsxIf={true}>Hello world</span>

Both these accomplish the same thing, but the second is far superior from a developer perspective.

To provide another example of superior developer experience, compare a React style take on a Angular 2's flex layout:

<Flex val={33} val-gt-sm={67}>
   <div>Hello World</div>
</Flex>

<div *fxFlex={33} *fxFlex.gt-sm={67}>Hello world</div>

The second is still more succinct and readable.

I know there would be technical bugbears a plenty, but the wins seem pretty significant. I love React too much to see Angular gain developer mindshare over something as simple as syntactic attribute sugar.

(Also, for what it's worth React already has some notion of "magic" attributes, such as ref on DOM nodes).

Web Worker Rendering Idea

After reading the Angular 2 google doc on rendering architecture
I got thinking about how this could be achieved with React. Wouldn't it be awesome if a web worker could be used for your application logic so the main thread can stay responsive to user interaction? Imagine if you could send a virtual dom diff from a worker to the main thread.

The current problem with this architecture is that a virtual element is not always serializable. This is because we want to be able to attach event handlers to respond to events triggered by a user. These event handlers are not always called with serializable arguments for example DOM elements. What if instead you could describe your event handler in terms of a function and that functions data dependencies? Perhaps something similar to GraphQL. Then just let the main thread send what is required when such an event is triggered. A virtual element could then be serialized and sent over a web worker message channel.

You could take this a step further and take advantage of the diffing process. Only send the diffs of the elements that have changed including the changes in data dependency. When a user triggers an event the Main thread figures out the event and the required data and sends it back to the UI thread.

You could potentially get multiple UI threads sending diffs to the main thread as long as each UI thread owned a given branch of the virtual tree.

Does this sound like something worth exploring? Am I missing something that would stop this from working?

Inputs aren't generic across different backends

The current recommended way to get the value of an input is

this.refs.myInput.getDOMNode().value

or in an event handler,

e.target.value

Both of these are DOM-specific. Ideally this wouldn't involve talking to the DOM directly – the current way makes the React abstraction leakier and prevents the same component API from being supported against multiple backends.

We could make something like this.refs.myInput.getValue() work, but perhaps there's something cleaner we can build?

A different approach for handling styles.

This idea in my head isn't fully formed for it to be a pull request yet. But I would love to start a discussion on this.

The idea is a different implementation for CSS so that it isn't actually inline, but still gets the other benefits of authoring CSS in javascript such passing styles around etc etc.

The big challenge is that the implementation would be much more complicated. And may require a little bit of a custom syntax.

This is what I'm suggesting:

Follow the InlineStyles proposal on the API level. But instead of rendering the styles inline, Each set of CSS rules is put into it's own Style Tag, and manages by React.

The computed styles can can be converted to a string and can be used as an object property. That property can hold an array of React-ids for elements it applies to. Then the Style tags can be updated using the same Diffing strategy and the selectors for sets of CSS rules can be updates.

One way to explain this is to think of CSS in reverse. Instead of CSS rules belonging to Elements, Elements belong to (sets of) CSS rules.

From what I can imagine, here are the pros and cons of this approach:

• There will be a lot of Style tags: Each Set of CSS will have it's own Style tag to be able to minimise changes. (it's also possible to use a generated ClassName to be able to minimise the number of changes to Style tags and just create new ones on the fly and apply the correct ClassNames.)
• It will be totally possible to use pseudo selectors and elements
• Media Queries will still be tricky. (This is because they can't just be a another selector and wrap entire selectors instead.

Attempt to improve "Returning state" section

What about if we can get rid of this:

render(state = { count: 0 }, props = {}) {
  return (
    <div>
      <span>Clicked {state.count} times!</span>
      <a href="javascript:void(0)" 
        onClick={() => render({ count: state.count + 1, }, props)}>
        Click to increment!
      </a>
    </div>
  );
}

Allow multiple refs per element / Multiple elements per ref

This is not a common case, but there are times when it would be great to be able to put multiple refs to the same Element.

Additionally, refs, currently work like ids, where every ref has a one-to-one relationship with a single element. It would be great to be able to have a similar system that works a lot more like a class.

Example:

var App = React.createClass({

  componentDidMount: function(){
    var refs = this.refClass.focussed;

    refs.forEach(function(ref){
      var el = ref.getDOMNode();
      var rect = el.getBoundingClientRect();

      el.classList.add(someFunction(rect));
    });
  },

  render: function(){
    return React.DOM.div({ref: ['container'], refClass:['div', 'focussed']},
      React.DOM.span({ref: ['span'], refClass:['focussed']})
    );
  }

});

The value is not obvious for making general apps, but it makes a whole set of additions on top of React possible. Currently the closest thing we have is a hack workaround where refs are names with sequential names — a1, a2 ...

When in javascript, it should really be possible to just use arrays for things like this, as with sequential names, you need to know the number of refs before hand.

Flux over the Worker

Please blame @vjeux for me promoting my work again!

To implement Flux over the Wire I rearranged the Flux abstraction slightly to make it more symmetrical. Basically, Flux has two sides, the single source of truth and the client components. The single source of truth observes actions and emits updates. The client components observe updates and emit actions. Emitting (action or updates) is fire & forget, the communication between the SSoT and the components is asynchronous by design. This allows to use the same abstraction for either local, traditional Flux, and for flux over the wire, which is basically having your single source of truth residing on your datacenter and your clients residing in your visitors browsers. Updates & actions are sent via Websockets (or polyfill), and stores are exposed as HTTP GET endpoints for performance and caching. This all works pretty well in practice for doing stuff like multi-user chat or magically auto-updating newsfeed.

However, this abstraction can basically sit on top of any asynchronous communication mechanism. One of the most promising is using it to communicate with a Webworker via postMessage. This would enable the state of the app to live in the webworker, and, more importantly, to have the action handlers run in this worker. Assuming we can efficiently transfer immutable objects back and forth between the window and the worker, then one can defer expensive business logic calculations off the main thread. While it would be very overkill for the typical TodoMVC demo, I think this could make sense for things like sorting huge arrays or calculating layout of stuff like that.

What do you think?

How to keep the implementation details of the underlying implementation from leaking out

myComponentInstance.getDOMNode() and similar things are uncool.

It would be better to fully encapsulate the underlying implementation and expose an explicit way to get at each of the outputs that can be generated from the underlying implementation.

Currently React is focused on HTML5, but theoretically React components could encapsulate SVG, Canvas, WebGL, iOS View Hierarchy, Android View Hierarchy, or even OpenGL itself. We certainly don't ever want anything like myReactComponentInstance.getOpenGLContext() evar.

So, what can/will/should be done about this?

No selectors for CSS?

https://github.com/reactjs/react-future/blob/master/04%20-%20Layout/Inline%20Style%20Extension.md#no-selectors

What about hover (etc) styles for descendants? This seems like a major issue with the current approach, unless I'm missing something.

.button:hover > .label {
  top: 1px;
  font-weight: bold;
}

Also, if you're really intending for these to be supplied as styles, as opposed to classNames, I'm pretty sure that would destroy the overall performance.

Import module syntax

Hi,

you are using the following import module syntax:

import { Button: MySpecialButton } from "Button";

ES6 defines different syntax (http://wiki.ecmascript.org/doku.php?id=harmony:modules) with the as keyword. I would expect the following import:

import { Button as MySpecialButton } from "Button";

Is it the same thing or does your import with colon mean something else?

API for managing selection state

Managing the selection with something like a filtered controlled <input> is a huge pain right now -- if you do the simple thing of filtering the value in the onChange handler

handleChange: function(e) {
  this.setState({text: e.target.value.replace(/^[0-9]/g, '')});
},

then your cursor jumps to the end of the text box when typing non-digit characters anywhere into the field.

For comparison, Elm treats the selection state as part of an input's value.

Replace constructor helpers with native functions

To me React.createClass() has always felt awkward to use. After seeing the stateless functions example I started wondering if we can't just toss out the helper functions and reinstate native function composition. It would be nice if we could just pass the following example to rendercomponent():

button.js :

/**
 * Module dependencies
 */

var react = require('react');

/**
 * Exports
 */

module.exports = button;

/**
 * Expose button prototype
 */

var button = Button.prototype;

/**
 * A button component
 * 
 * @param {Object} props
 * @api public
 */

function Button(props) {
  this.props = props || {};
  this.displayName = 'button';
};

/**
 * Button template
 *
 * @return {Function}
 * @api private
 */

button.render = function() {
  return react.DOM.div(null, 'Click me!');
};

What do you think?

Discuss Conditional JSX Expression

From @syranide

http://wiki.ecmascript.org/doku.php?id=harmony:array_comprehensions could this be something to consider for JSX? I.e. statement like syntax inside braces, more readable than ternary and various other hacks while still being very much like JS. <div>{if (x) <div />}</div>, etc.

Is there any plan of implementing in webgl mode?

Or implemeting another way of improve the rendering performance

React as a Specification

React can be a language agnostic design pattern.

Many languages have implemented their own version of JavaScript. A natural step for them is to come up with some sort of implementation for React.

Rather than tying React to JavaScript, imagine making it more like JSX or GraphQL--a specification that languages are free to implement.

EXAMPLE

Of course, then the main challenge is getting browsers to be able to use that non-JS code... i.e. Shift the paradigm from thinking of JS as another scripting language to it serving the purpose of a VM for the browser.

Improved device input abstraction

I would like to propose a greater abstraction from the top level composite events that the browser provides. This would allow developers building applications with react to avoid the complexity of composite events and heuristics that plague most cross-input applications.

https://github.com/facebook/react/issues/2061is the perfect example.

Depending on the UA, touchstart, touchmove, and touchend event details, and backwards-compatibility heuristics, the subsequent click event will often be delayed from the original user events by ~300ms. The fragmentation of UA implementations has only gotten worse in time (Chrome disabling it with certain heuristics like the <meta name="viewport" content="width=device-width"> with iOS8 introducing it’s own set of heuristics (ftlabs/fastclick#262 (comment)).

I believe that there is a great opportunity for React to take a step away from the browser event pipeline and do the sensible thing for the 95%. Begin with the click event, then move on to a sensible API for mouse, touch and pointer events.

To quote @petehunt

There is a lot of stuff you get for free when you build like the browser doesn’t exists and this is one thing that distinguishes React from Web Components and Polymer and that kind of thing …they’re getting closer and closer in with the browser, and we’re getting farther and farther from the browser. And I think that our technique is more sustainable in the long term.

Server-side: Media queries and pseudo classes for inline styles

https://github.com/reactjs/react-future/blob/f8808dd4cd275dcc2a81b41989a71cd23ad98308/04%20-%20Layout/04%20-%20Inline%20Styles.md provides a proposed API for defining inline styles on a component. In some cases, it's necessary to use media queries or pseudo classes in a selector, which isn't directly possible with inline styles. Any ideas here?

cc @vjeux

Support memoization of component functions during render phase

var Hello = React.createClass({
    getExpensiveNumber: function() {
       return ...; // expensive value computed from props and state
    },
    computeSomethingBasedOnExpensiveValue: function() {
      return this.getExpensiveNumber() + 1;
    },

    render: function() {
        return <div>Number is {this.getExpensiveNumber()}, next number is {this.computeSomethingBasedOnExpensiveValue()}</div>;
    }
});

In the following example, we can see this.getExpensiveNumber() is called twice during the render phase, which means the expensive code runs twice.

Current solutions for this execution cost problem are:

• Compute the expensive value only once at the beginning of the render method, and pass it to all rendering functions that needs it. In complex components this can lead to boilerplate and more complex method signatures.
• Perform the expensive computation in state, but this is not advised by React documentation as it duplicates the source of truth (and also introduce boilerplate).

Since React's render method is supposed to not have any side effect, and during the render phase neither props and state are supposed to change, another possibility is to be able to memoize the expensive render functions. During a single render phase, they are supposed to always return the exact same value (for primitives at least, it could be another object's identity...).

We could probably have a syntax like this one:

var Hello = React.createClass({
    getExpensiveNumber: React.renderMemoized(function() {
       return ...; // expensive value computed from props and state
    }),
    computeSomethingBasedOnExpensiveValue: function() {
      return this.getExpensiveNumber() + 1;
    },

    render: function() {
        return <div>Number is {this.getExpensiveNumber()}, next number is {this.computeSomethingBasedOnExpensiveValue()}</div>;
    }
});

And this will memoize the function per render phase, meaning the expensive call will only run once per render instead of twice.

Just a silly question

Will you guys ever do the same thing like Google did on angularjs..?
..angularjs 2.0 was a total rewrite and if youre using 1.x your in deep shieet. Luckily I didn't have anything angular in production.

For me at least, its very important that IF I choose to use something, going forward shouldn't mean discarding all the stuff you have done. I understand that of course one must do stuff to go on.. but, a total rewrite.. ewww.