Does fast-render have no effect in React projects using Flow Router?


In my React apps, all my subscriptions are handled at the component level:

getMeteorData() {
  const handle = Meteor.subscribe('myData');

  return {
    ready: handle.ready(),
    things: Things.find({})

Adding meteorhacks:fast-render seems to have no effect. I still see brief loading spinners show up. I’m guessing it only works if you subscribe in the router, which is being deprecated in Flow Router 3.0, so it’s not really a habit I want to get into.


I believe that version 3 adds SSR. My guess is this should negate the need for fast-render. I can’t say this is definitely the case but that’s my educated guess.


Yes, I think you’re right. I’ve avoided using SSR for the time being, because my experiences with it so far have been fairly negative. I’m not sure if it’s something that’s 100% ready for production yet. Or I’m just not grasping how to work with it. :smile:


FlowRouter doesn’t support it yet but you can try reactrouter:react-router-ssr. It does use fast-render behind :smile:


Oh wait. Didn’t we have this:



When you are using subscriptions inside the components, FastRender can’t understand them unless you them on the server using SSR.

For that, try flow-router-ssr:

It’s not yet production ready. (because we don’t have test cases and tried with different scenarios)
But, we are running it on for months.


Even with SSR, fast-render is needed. We need send data down to using FastRender.


If you don’t need SSR and still want to use FastRender. Try using FlowRouter’s subscription registration feature.
In FlowRouter 4.0, we’ll remove it. But it’ll get replaced with SubsManager.


I did try SSR once, but it had trouble with redirects in FlowRouter. I got client/server mismatches (GitHub issue), so I stopped using it. Also, I’m confused about how to use client-only packages (such as meteorflux:reactive-state which is basically a Flux system) in methods like getMeteorData which is both client and server.


For those stuff, you need to move them either into componentDidMount hook or use with checking if(Meteor.isClient){}


That won’t work, since only getMeteorData is reactive. This is a common methodology:

getMeteorData() {
  return {
    reactiveThing: AppState.get('form.reactiveThing')

So an error will occur in SSR because AppState is a client-only structure. But it has to be in getMeteorData as componentDidMount is not reactive.

You recommend checking Meteor.isClient… then how would that work?

getMeteorData() {
  if (Meteor.isClient) {
    return {
      reactiveThing: AppState.get('form.reactiveThing')
  } else {
    return { reactiveThing: 'no idea, cannot return actual data' }


Yes. This is the correct way.
Make sure, both returns the same data in both environments.
(Better approach is to give support for AppState)


But how could I return the same data in both environments? If server-side can’t access AppState (which uses, I believe, ReactiveDict which is client-side only), the server will have no idea what’s going on.