@faceyspacey Yea you’re right. Minimongo basically acts as an in memory cache. React ‘state’ is just local data that’s not persisted… the overlap would be Session in the global sense and template vars in the private sense.
React still uses ‘state’ to temp. save mode/database data. For example make an ajax request and then setState with the payload (however flux is typically used to share this data easier).
This brings us to the real problem we’re trying to solve: it’s hard to reach instance storage/state from other components in plain Blaze. Template instance storage isn’t easily reachable by other template instances like Session storage is.
Agreed. However, this is a good thing. I’ve burned myself hard by doing this. If you could reach in then it’s no better than using Session. Once things get unpredictable and changes start cascading it’s a disaster to debug. Like it or hate it, I have to admit the Flux/Redux flow of data is very predicable.
thereby enabling you to use its instance storage even when triggered on a child template!
This is clever. It’s also a double edge sword… if one uses this just as a workaround to reaching into a parent directly it’s not much better. IMHO it’s better and more predictable if you just keep the views very dumb so that they’re just collection data on event handler fire and then calling a function and passing that data. This keeps it easy to share and easy to test. For example:
// actions.js
// app can reactively change depending on the current song id
// put in namespace to mitigate globals
Actions.playSong = function(trackId) {
Session.set('Music:currentTrack:id', trackId);
app.debug('currentTrack', trackId);
}
// template(s).js
class MyComponent extends Meteor.Component {
// call action and pass in ID
['click .track-container']() {
Actions.playSong(this.trackId)
},
}
class OtherComponent extends Meteor.Component {
['click .other-track-thing']() {
Actions.playSong(this.trackId)
},
}