Accepted answer

Here is a POC implementation I've done with ImmutableJS internal structure. This is not a public API so it is not ready for production and does not currently handle corner cases but it works.

var ImmutableListRenderer = React.createClass({
  render: function() {
    // Should not require to use wrapper <span> here but impossible for now
    return (<span>
        {this.props.list._root ? <GnRenderer gn={this.props.list._root}/> : undefined}
        {this.props.list._tail ? <GnRenderer gn={this.props.list._tail}/> : undefined}

// "Gn" is the equivalent of the "internal node" of the persistent data structure schema of the question
var GnRenderer = React.createClass({
    shouldComponentUpdate: function(nextProps) {
      console.debug("should update?",( !==;
      return ( !==;
    propTypes: {
        gn: React.PropTypes.object.isRequired,
    render: function() {
        // Should not require to use wrapper <span> here but impossible for now
        return (
                {,index) { 
                    // TODO should check for Gn instead, because list items can be objects too...
                    var isGn = typeof gnItem === "object"
                    if ( isGn ) {
                        return <GnRenderer gn={gnItem}/>
                    } else {
                        // TODO should be able to customize the item rendering from outside
                        return <span>{" -> " + gnItem}</span>

The client code looks like

    <ImmutableListRenderer list={ImmutableList}/>, 

Here is a JsFiddle that logs the number of shouldComponentUpdate calls after a single element of the list (size N) is updated: this does not require to call N times shouldComponentUpdate

Further implementation details are shared in this ImmutableJs github issue


Recently I had a performance bottleneck trying to render a table with 500+ records, the reducers were immutable and I was using reselect to memoize the complex selectors, after pulling some hair, I found the problem was solved memoizing all the selectors.


In our product we also had issues related to the amount of code being rendered, and we started using observables (see this blog). This might partially solve your problem, as changing todo will no longer require the parent component that holds the list to be re-rendered (but adding still does).

It might also help you in re-rendering the list faster as your todoItem components could just return false when the props change on shouldComponentUpdate.

For further performance improvements when rendering the overview, I think your tree / paging idea is nice indeed. With observable arrays, each page could start to listen to array splices (using an ES7 polyfill or mobservable) in a certain range. That would introduce some administration, as these ranges might change over time, but should get you to O(log(n))

So you get something like:

var TodosContainer = React.createClass({
  componentDidMount() {
     this.props.todos.observe(function(change) {
         if (change.type === 'splice' && change.index >= this.props.startRange && change.index < this.props.endRange)

  renderTodo: function(todo) {
     return <Todo key={} todoData={todo} x={this.props.x} y={this.props.y} .../>;

  render: function() {
     var todos = this.props.todos.slice(this.props.startRange, this.props.endRange).map(this.renderTodo)
     return (
          <ReactCSSTransitionGroup transitionName="transition-todo">


The central problem with large lists and react seems that you cannot just shift new DOM nodes into the dom. Othwerwise you won't need the 'pages' at all to partition the data in smaller chunks and you could just splice one new Todo item into the dom, as done with JQuery in this jsFiddle. You could still do that with react if you use a ref for each todo item, but that would be working around the system I think as it might break the reconciliation system?

Related Query

More Query from same tag