Upgrade React_View to support ES6 classes, and the newest React.js

[karth295]

// Automagically makes bus calls reactive in render
import ReactiveComponent from statebus

class Hello extends ReactiveComponent {
  render() {
    return ReactDOM.div({
      style: {
        color: this.props.color,
        height: bus.height,
        width: bus.width,
      }
    });
  }
}

Big drawback: This is obviously more verbose than the coffeescript client:

dom.Hello = ->
  DIV
    style:
      color: @props.color
      height: bus.height
      width: bus.width

But the ES6 version has some benefits:

1. There's a lot less magic -- no "dom.PROPERTY", no weird runtime compilation errors, it's obvious where "this.props" comes from, etc.

2. We can use import/export to easily use/write libraries. I'm not a huge fan of including <script> tags and using global variables.

3. I personally like OOP. Sharing (private) state between all of the react state hooks can happen through properties on the object, rather than statebus.

4. People familiar with React will find the ES6 version familiar.

[toomim]

We already have a ES5 version of what you're proposing. It used to be called ReactiveComponent, but has since been renamed to React_View. We built this for ES5 because that's what React was using at the time. At some point (maybe version 0.13?) React switched to full ES6 support, and adopted ES6 classes and module imports, but I haven't updated statebus to use the new version of React with its ES6 syntax.

So I think we could rename this bug report to "Upgrade React_View to support ES6 classes, and the newest React.js".

Here's an example of using React_View:

<script src="https://stateb.us/client4.js"></script>
<script>
var comp = React_View({
    displayName: 'My Component',
    render: function () {
        var foo = fetch('/foo')
        return React.DOM.div({
          style: {
            color: this.props.color,
            height: foo.height,
            width: foo.width,
          }
    }
})

document.addEventListener('DOMContentLoaded', function () {React.render(comp(), document.body)}, false)
</script>

React components used to be raw {...] objects like above, back before ES6 classes existed.

We should add React_View to the readme. And we might also want to reconsider the name, I haven't thought about the best name for this function yet. It used to be called ReactiveComponent, just like you called it above. You can see the name ReactiveComponent being used in the current consider.it code. We used this system for all of consider.it.

[toomim]

I haven't learned es6 modules yet. Do they actually eliminate <script> tags on the client? Don't you need webpack or something to get that?

[karth295]

Yeah :/

But that still seems cleaner than adding script tags in the correct order.

[toomim]

Ok, cool, I agree with you.

We can also write our own require() function that loads statebus code over the internet, where each piece of code can require() other pieces of code over the internet. Then we don't need webpack. Travis and Morgan have implemented prototypes of this model. We might be able to make a production version of this pretty simply... it basically needs to do a fetch() and then eval(). I don't like forcing statebus users to install webpack, which forces them to have a server, and install npm, etc. You should be able to make a client without running a server.

Plus, once we have this basic system working, we can add sweet new features:

• Cache the code in localStorage to cut down on load times
• Live editing, so you can change the running code in the page as you type w/o clicking reload.
• Inline editor on every page, start editing to fork your own version of the page

So I think the future of statebus code loading will be about code living on statebus itself, and live updating the code affecting all servers and clients that fetch it. If we implement the basic version of that now, we can address your dislike for <script> tags with their crappy dependency resolution and global variables, and be ready to add the sweet extended features in the future whenever we want to, which will upgrade all statebus sites using this API without them having to change anything.

I'm sending you some links now (in your fb messages) on the discussions we've had for this feature.

[karth295]

import/export kinda suck for now (you have to use external libraries), but in the future browsers should just support them natively. Either way, having a statebus version of require doesn't stop you from using something like Webpack, so LGTM.

For the record I'll use statebus version because setting up webpack doesn't sound very fun.

[toomim]

This is almost done. I think I'm going to change the API name too, so and write up docs for it, and make it connect easily to HTTP servers, so that people can easily use statebus to connect react components to existing REST servers.