Yea if you’re on a deadline I would do that but still keep everything in the ‘both’ folder so that it’s available when you do want to use SSR. Are you able to just stub out the collection if it’s on the server or would that change the markup that gets generated?
I suppose I could stub it on the server, and we’d just have an empty MongoDB. As long as I ran all the queries in componentDidMount() and stored data there, it would be client side only… I think. I’m not 100% sure how I’d stub a collection.
QueryResults = new Mongo.Collection('results');
This is just going to define it on both server and client, no?
Right so if you pass a name into the collection it will create a collection on the database and also one in minimongo on the client. The null collection is just temporary in memory.
If you’re null collection is just being used to store the data from the salesforce API response, wouldn’t it be easier to skip the reactive data sources and just use setState to update the React component like you would without Meteor? For example something like this:
Dashboard = React.createClass({
displayName: 'Dashboard',
getInitialState() {
return { queryDone: false }
},
componentDidMount() {
jsforce.browser.init({ /* .. secret credentials.. */});
jsforce.browser.on('connect', (conn) => {
let queryStr = 'SELECT ...';
conn.query(queryStr, (err, result) => {
if (err) {
console.error('error', err)
} else {
this.setState({queryDone: true, eventsList: result.records})
}
})
});
},
render() {
if (!this.state.queryDone) {
return (<div>Loading...</div>);
} else {
return (
<EventsTable list={this.state.eventsList} />
);
}
}
});
That could work. I actually have that now and it’s passable, but what about if the query changes? I’d need to reactively run a new query and re-render, hence why I was using Meteor’s pub/sub model. But if I use an unnamed/unsynchronized Mongo collection, then I can’t use this.added within Meteor.publish since the former requires a collection name.
So if you put this.setState wherever the query returns it’s results then it will update the UI. I guess I don’t follow exactly what needs to be subscribed to / published or how you’re querying the REST API for subsequent updates.
If you needed to publish this data set to lots of users then setting up a subscription makes sense (one API request on the server then publish to many). However if you’re just hitting an API it seems like normal React conventions would work best. However I don’t think I quite follow the use case so take this with a grain of salt.
Hi Sashko,
So what if we just persist the data we get on the client side? As in getting the REST API data on the front end, and then upsert the data into a named Mongo.Collection so DDP puts it into Mongo.
This would lean into the framework and we should be able to do SSR with React, no?
Originally I was thinking about “what I need” and not how the framework works.
Because we are doing oauth and retrieving the data on the client, I was using Session to store the result.
This was working well if the user navigated to the page from the login screen. But was seeing errors on the server side paraphrasing “Session doesn’t exist.” when deep linking into the users dashboard.
Over the weekend I decided maybe we should harness what Meteor is good at, and instead of restricting the technical requirements to what the app only needs to do, to just go ahead and use the full power of Meteor.
What do you guys think?
I need to create a simple app to demonstrate how React and Meteor can work with the Twitter API. This thread helped me tremendously. Thank you guys. Here is what I came up with: