getMeteorState fine-grained reactivity

[ccorcos]

Suppose you have multiple states you want to get.

getMeteorState: function() {
  return {
    something: Somethings.find().fetch()
    otherthing: Otherthings.find().fetch()
  }
}

Whenever the smallest thing changes in either collection, BOTH will be rerun. It seems like this should look more like Template.helpers.

getMeteorState: {
    something: function() {Somethings.find().fetch()}
    otherthing: function() {Otherthings.find().fetch()}
}

[benjamn]

I bet we could support both of these styles at the same time!

[ccorcos]

Hey, I made my own mixin that I think you might enjoy

https://github.com/ccorcos/meteor-react-utils

Two big differences are:

1. this.rprops are reactive variables for the props so you can use them in getMeteorState
2. getMeteorState has fine-grained reactivity as discussed here so on componentWillRecieveProps we can update only what we need.

[jonagoldman]

+1 I am having real trouble when a component depends on more than one collection. This should be built in react-meteor.

[ccorcos]

@jonagoldman check out my mixin: https://github.com/ccorcos/meteor-react-mixin

[rralian]

@benjamn is this issue being actively pursued? I've started playing with this package, and I really like it so far. But I'm concerned that this issue will bite me if I build anything with decent complexity.

[ccorcos]

@rralian, the reality is that most React components have a narrow scope. Rarely will you have more than one reactive state variable. And if you do, this is all on the client anyways. Javascript is fast, and React will prevent unnecessary re-renders. Point is, its not going to kill you. But its an obvious optimization in my opinion.

If you comfortable with Tracker, I'd highly suggest building your own mixin like I did. It isn't terribly difficult and you can get all the specifics you want out of it.