Tighter Tracker-React Integration (today)

1

I figured I’d post this again–not just because of the upgrades I’m about to mention–but because with all the standard noise of a busy forum, people are missing it. And given all the concern in the other Blaze/React threads, and the positive reaction from the few people that have stumbled on this, I wanna make sure everyone gets a chance to check it out.

##Re-INTRODUCING THE NEW & IMPROVED: TrackerReact:

meteor add ultimatejs:tracker-react

###HOW DOES IT WORK?
Include the mixin, and simply access any reactive data sources in your render() method. That’s it:

App = React.createClass({
    mixins: [TrackerReact],  ///add this mixin

    tasks() {
        return Tasks.find({}).fetch();
    },


    render() {
        return (
            <div>
                <h1>Todo List - {Session.get('title')}</h1>

                <ul>
                      {this.tasks().map((task) => {
                          return <Task key={task._id} task={task} />;
                      })}
                </ul>
            </div>
        );
    }
});

###Yes, that means no need to “freeze” reactivity in getMeteorData.

There’s a clear path forward. I’ve got a precise vision here for how the Blaze/React situation is supposed to be handled, and it will put to rest all your concerns. If we can show MDG what we want it to look like (and build a lot of it), they will basically have no choice to implement it. So, getting your Blaze/React needs met relies on you doing things like testing/using this package today, perhaps even contributing. This is not just me making this stuff. We need to make it a first class priority ourselves, if we expect MDG to do so.

9 Likes
2

I believe people just learnt to scan through your nickname and go to another post/topic. Opening new topics about the same thing won’t change it for better.

3 Likes
3

I was expecting the CapsLock title… :smile:

1 Like
4

That would be a concern. Getting sick of my pink spaceship already? Doesn’t seem to have applied to you. …Anyway, it would be nice for information to stand out based solely on its own merit, but we’ve all seen lesser solutions win because of better marketing.

5

Api looks clean.

Is there a non trivial overhead to having to call fetch?

6

it is what getMeteorData expects as well. That doesn’t really answer the question though. Does spacebars fetch all its cursors to register the dependencies? I don’t currently know the answer to that. There should be a way to register the dependency based on the cursor alone. If there is such a way, rest assured it will be applied. Right now we’re just trying to get the interface right. If this can all work smoothly, my hope is MDG–who has way more expertise in Meteor internals–optimizes it.

That all said, I really wouldn’t worry about the performance of fetch for now. I got a few other ideas to optimize rendering, i.e. remove autorun creation/stopping from the virtual dom render pass, i.e. put it in the next tick of the event loop via setTimeout. So if we’re doing that, all these fetches which do nothing but register the reactive dependency are basically small javascript operations not effecting anything.

7

Just noticed that getMeteorData does the same too

8

We just released an even easier React and Tracker integration, one cannot make this easier and the implementation can’t be lighter, it’s ridiculous how easy we’ve made it.

Bonus feature: Server Side Rendering (see the clip ;))

Learn how we build easy React Components with Meteor and Tracker using Tracker.Component:

Cheers from the folks at Studio Interact