Is that through puppetteer? I can see how that would mess with stuff. Why not use SSR techniques?
I’ve actually been thinking about how to do AOT (ahead of time) rendering (or static pre-rendering as they call it) in Meteor like NextJS does. It wouldn’t be that hard to make spin up a Meteor instance, then run a list of routes against it to get some output, and capture that. I find puppetteer to be problematic, but proper static rendering (either through SSR or AOT techniques like Next uses) clean everything up nicely, because it makes the purpose of execution clear. (I’ve even used react-snapshot a bunch, and it was also more reliable that various other puppetteer solutions - and it just runs jsdom - at least in my limited experience).
More challenging might be to do partial build like Next can. I suppose as long as the SSR output is configured with the right kind of output, it should be possible to diff that output based on triggers. It’d be harder to pull off in Meteor though, because we don’t have methods like getServerSideProps and getSstaticProps which can be run outside of any React code. It would probably not be too hard to create a package to add something like that though.
We use prerender and, apart from problems with JSS, it’s working really just fine. We serve the search engines with the prerendered snapshots from redis via nginx.
With respect to SSR I failed completely and utterly. I’ve read various guides of how other folks do it, and I admit I didn’t understand any of it. It feels like an intellectual barrier I’ve hit with full speed.
I agree that SSR is not easy with Meteor - possible, but not easy. The way they do it in Next is a bazillion times easier, but it required implementing an entirely different routing paradigm (they don’t use React Router). I kind of wonder whether Meteor should have something like that - we almost did back in the day with Flow Router, though its goals were not to facilitate SSR and code splitting the way next/router does. Still, it would be even better in Meteor, given Meteor’s perfect code splitting. I’m thinking a lot about this lately.
I should say though - SSR in Meteor is not harder than platforms like Express.js - it’s just not as easy as Next.js
BUT - there are trade offs. Nextjs is not as flexible with how you put things together as Meteor is. Meteor can literally SSR anything. With Nextjs, you have to use their special data methods and/or block SSR/Static rendering in order to gain the full advantage - and it’s all tightly coupled with React.
I agree completely. I’m trying to do a quick project using methods which fetch data from 3rd party APIs - and the SSR story there is anything but simple.
