You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
1.Could you describe your use case please?
I used to use (kadira:flow-router-ssr) package but since kadira shut down I swapped over to your package because I needed some of your functionality. For the case example refer to: kadira:flow-router-ssr.
2.Why other SSR solution couldn't be used as separate package?
I can't fine a good solution. If you guys have one I'd love to know.
@jborseth with code splitting in Meteor 1.5 apps is lightweight and load blazing fast.
What you have described sounds like request to support fast-render, not SSR, am I right?
How SSR should behave in case of access to page which requires authentication or other user action?
How the application state is transferred to Client, like - it's rendered, but JS has continuous runtime how to transfer its state?
We may render Blaze template on Server and respond with DOM string, which in this case is static HTML, with no JS listeners, runtime, etc. If we will respond with rendered HTML page, and then request app's bundle, run it and render template again but this time on a Client. Is this expected behavior?
Questions may sound obvious, but we need to make sure we are on the same page. Thank you.
Just to add to the conversation. We are also using FlowRouter SSR in our React + Meteor app. The primary goal was SEO. We forked the original FlowRouterSSR branch when Kadira announced it was stopping support for it: https://github.com/bensventures/flow-router (Works up to Meteor 1.5, not tested in 1.6 yet)
Trying to give some answers to your questions above:
SSR is active only on routes you also include from the server. I think each app should decide to include or not the pages that should be rendered on the server. SSR for profile pages works for us, I think thanks to fast-render.
If I'm not mistaken, FlowRouterSSR uses features from Fast-render to get the state of the app and send state + rendered html to the client on first load.
React handle SSR automatically I think. Your app sends rendered html without listeners, React inits on top of that, detecting rendered element and adding only what it needs to them. Not sure how this would work with Blaze.
Historically FlowRouterSSR only worked with React I believe. It would of course be nice to have it working with both Blaze and React. And in a less hacky way than what it is now. I had to look at the code to get it to work with 1.5 and the SSR branch feels more like a hack with fast-render than a real SSR implementation.
SSR makes also sense for stuff like facebook crawler, which uses og-tags to read information. But unfortunatly as of october 2018, the facebook crawler still does not interpret javascript.
With react, its usually pretty easy to do SSR, so i thinking about switching to react-router for that, but it would be awesome if FlowRouter would support it. I think it's not that hard with the new meteor api.
@macrozone why you need this on router level? It's possible to implement on app-level with the new meteor api, right?
Although, SSR will add tags to head it wouldn't be good for SEO due to Cloaking. You don't need to waste time and resources on implementing SSR, better use self hosted Prerendering or SaaS Prerendering solution
@dr-dimitru of course this needs to be on the router level, because you don't want to specify all routes twice (one on server and one on client). But maybe i try to do some proof-of-concept at the weekend...
I don't understand the cloaking argument. That's definitly not cloaking.
Yes, prerenders work as well, but you won't get the other advantages like even faster page loads. SSR is not wasted time and resources, its the right way to go. Prerendering is just a workaround.
FastRender.onPageLoad(sink => {
console.log(sink);
console.log(FlowRouter);
const currentRoute = FlowRouter._routes.find(
route => .... // find the right route
)
if(currentRoute) {
/* now action should be isomorphly defined. On the client it should just mount the component (flow router uses probably still have react-mounter) and on the server it should call sink.renderIntoElementById('react-root', renderToString(<ComponentDefinedInAction />));
*/
currentRoute.action(...., {sink})
}
});
i currently stuck at finding the right route from sink.request.url. This is done with page.js on the client with some fancy regex. But i try now to find out, whether i can use the same logic on the server
Activity
dr-dimitru commentedon Jun 1, 2017
Hello @tmpg ,
Thank you for interest.
tmpg commentedon Jun 2, 2017
1.Could you describe your use case please?
I used to use (kadira:flow-router-ssr) package but since kadira shut down I swapped over to your package because I needed some of your functionality. For the case example refer to: kadira:flow-router-ssr.
2.Why other SSR solution couldn't be used as separate package?
I can't fine a good solution. If you guys have one I'd love to know.
dr-dimitru commentedon Jun 2, 2017
@tmpg I meant what for you've used server rendering, what the purpose? Emails? SEO? Is there any other purpose?
dr-dimitru commentedon Jun 2, 2017
@tmpg we're using meteor-ssr
dr-dimitru commentedon Jun 7, 2017
@jborseth with code splitting in Meteor 1.5 apps is lightweight and load blazing fast.
What you have described sounds like request to support fast-render, not SSR, am I right?
dr-dimitru commentedon Jun 10, 2017
Hello @jborseth and @tmpg ,
I'm wondering:
Questions may sound obvious, but we need to make sure we are on the same page. Thank you.
bensventures commentedon Nov 17, 2017
Just to add to the conversation. We are also using FlowRouter SSR in our React + Meteor app. The primary goal was SEO. We forked the original FlowRouterSSR branch when Kadira announced it was stopping support for it: https://github.com/bensventures/flow-router (Works up to Meteor 1.5, not tested in 1.6 yet)
Trying to give some answers to your questions above:
SSR is active only on routes you also include from the server. I think each app should decide to include or not the pages that should be rendered on the server. SSR for profile pages works for us, I think thanks to fast-render.
If I'm not mistaken, FlowRouterSSR uses features from Fast-render to get the state of the app and send state + rendered html to the client on first load.
React handle SSR automatically I think. Your app sends rendered html without listeners, React inits on top of that, detecting rendered element and adding only what it needs to them. Not sure how this would work with Blaze.
Historically FlowRouterSSR only worked with React I believe. It would of course be nice to have it working with both Blaze and React. And in a less hacky way than what it is now. I had to look at the code to get it to work with 1.5 and the SSR branch feels more like a hack with fast-render than a real SSR implementation.
dr-dimitru commentedon Apr 30, 2018
Related to #47 - add FastRender support, where is partially implemented SSR.
macrozone commentedon Oct 11, 2018
SSR makes also sense for stuff like facebook crawler, which uses og-tags to read information. But unfortunatly as of october 2018, the facebook crawler still does not interpret javascript.
With react, its usually pretty easy to do SSR, so i thinking about switching to react-router for that, but it would be awesome if FlowRouter would support it. I think it's not that hard with the new meteor api.
dr-dimitru commentedon Oct 11, 2018
@macrozone why you need this on router level? It's possible to implement on app-level with the new meteor api, right?
Although, SSR will add tags to head it wouldn't be good for SEO due to Cloaking. You don't need to waste time and resources on implementing SSR, better use self hosted Prerendering or SaaS Prerendering solution
macrozone commentedon Oct 11, 2018
@dr-dimitru of course this needs to be on the router level, because you don't want to specify all routes twice (one on server and one on client). But maybe i try to do some proof-of-concept at the weekend...
I don't understand the cloaking argument. That's definitly not cloaking.
Yes, prerenders work as well, but you won't get the other advantages like even faster page loads. SSR is not wasted time and resources, its the right way to go. Prerendering is just a workaround.
macrozone commentedon Oct 13, 2018
one idea:
i currently stuck at finding the right route from sink.request.url. This is done with page.js on the client with some fancy regex. But i try now to find out, whether i can use the same logic on the server
dr-dimitru commentedon Oct 13, 2018
@macrozone what actually do you need to compare against
sink.request.url? Or what do you need to get out of thesink.request.url? Route name?macrozone commentedon Oct 13, 2018
@dr-dimitru I got it, i will open up a PR soon.
v3.6.1
dr-dimitru commentedon Dec 16, 2018
Hello everyone, thank you for the patience here 🙃
Please take a look and try v3.6.1, where we merged #58 introducing Basic SSR API, thanks to @macrozone and @coagmano
dr-dimitru commentedon Oct 12, 2019
Hello @tmpg @macrozone @coagmano @tmpg @bensventures ,
Friendly ping on this one. What its status? Is it implemented and working properly?
macrozone commentedon Oct 13, 2019
@dr-dimitru yes, it works. But i only use it in one project, which still uses FlowRouter and Meteor-collections