It looks like we should use getMeteorData as high up the stack as possible, same as state. From the example I’ve seen, this is where we subscribe as well as make a fetch. Now, let’s say the child component doesn’t need that fetched data, but the grandchild component does. Should I pass it through the child as a prop, use getMeteorData again in the grandchild, or go directly to the source (eg use Collection.findOne() in a method)?
It seems like the 3rd option, although the easiest, kills the whole notion of loose coupling. However, if that grandchild component makes a Meteor.call I don’t know any other way to do it, since I want to get a trustworthy document from the server. Any guidance?
@mattkrick I’m interested in this as well as and also curious to see what the best practice is when dealing Flow Router. Should the getMeteorData be defined all the way up at the MainLayout and passed down to each route (child) that needs it?
Ahhh I just got into contexts with the use of Material-ui, I need to make more use of them. So what would you recommend for calling Meteor methods inside components? Just stick with accessing the collection directly?
It’s hard to say - putting the method call into your component couples it to your data model and server structure, but on the other hand it’s not hard to factor it out later if you need to.
It depends on how reusable you want your components to be from the start.
That makes sense, thanks @sashko! One unexpected thing I noticed is that if a collection is accessed in the getMeteorData function, then a Collection.find() becomes reactive in the render() method. I expected all reactive functions to lose their reactivity in the render() function, regardless of the presence of a getMeteorData method. Could you explain why this happens? Seems weird that 1 method can affect the reactivity of another…
Reproduction code here: https://github.com/mattkrick/react-tac-toe/blob/master/client/components/Game/Status.jsx#L27 (comment out line #16 and line #27 is no longer reactive).
The count inside render isn’t reactive, it’s just that Connections.find().fetch() is causing getMeteorData to force a render, which in turn gets a new count.