Some initial work on React support

[tbranyen]

This is much more usable as a wrapped React component, consumption looks like:

import React, { Component, PropTypes } from 'react';
import HyperList from 'react-hyperlist';

export default class MyComponent extends Component {
  render() {
    return (
      <HyperList
        itemHeight={120}
        total={10000}
        generate={this.generate}
      />
    );
  }

  generate() {
    return (
      <div>Testing this out!</div>
    );
  }
}

With the experimental implementation being:

import React, { Component, PropTypes } from 'react';
import HyperListCore from 'hyperlist';

export default class HyperList extends Component {
  render() {
    const { element, scroller, fragment } = this.state;

    // Ensure the scroller is relative in our app.
    scroller.style = Object.assign({}, scroller.style, {
      position: 'relative'
    });

    return (
      <div {...element}>
        <div {...scroller} />
        {fragment}
      </div>
    );
  }

  constructor(props) {
    super(props);

    this.state = { element: {}, scroller: {}, fragment: [], };
  }

  componentDidMount() {
    const {
      height = window.innerHeight,
      itemHeight = 50,
      total = 0,
      reverse = false,
      generate = () => {},
    } = this.props;

    const config = {
      height,
      itemHeight,
      total,
      generate,

      isReact: true,
      useFragment: false,
      overrideScrollPosition: () => document.body.scrollTop,
      cloneElement: React.cloneElement,

      applyPatch: (element, fragment, scroller) => {
        this.setState({ element, fragment, scroller });
      },
    };

    this.list = HyperListCore.create(this, config);

    // Bind to the resize event, and since you should only ever have one
    // handler bound to this, we pave over whatever you had set before.
    window.onresize = e => {
      config.height = window.innerHeight;
      this.list.refresh(this, config);
    };
  }

  componentWillUnmount() {
    window.onresize = null;
    this.list.destroy();
  }
}

[tbranyen]

Some thoughts on this PR:

• I don't really like all the isReact-specific conditionals necessary.
• Probably shouldn't bundle the wrapper w/ this lib
• Is there a way to make this tool more generic (for say Node) using POJOs instead of DOM Elements?

[soyuka]

Hmm, I'm not fond of those conditions. I'm sure that there is a way to manage vanillajs and react with the same code no?

[tbranyen]

Yup, I agree. For now this allows it to work so I can move forward, but I don't think we should merge this as-is.

[soyuka]

I'll give this a shot this weekend and let you know my findings.

I don't really like all the isReact-specific conditionals necessary.

I didn't read this, but yeah adding framework-specific code isn't that clean :p

[soyuka]

If I understand this correctly, React is not DOM-friendly? I mean that for react you need some kind of virtual dom based on objects? Isn't there a way to transform real DOM elements to react-like dom outside this script?

[tbranyen]

There are, like React Faux DOM, but this performs significantly better and allows for a cleaner wrapper to built in React. We might want to approach this as just being VDOM-friendly and not focusing on React-specifically. Like diffHTML could benefit from these changes as well, but allow its VTree representation of a DOM Node to pass through HyperList and get the right positional values associated with it.