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

help
1

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.

2

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.

3

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:

4

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

5

Oh wait. Didn’t we have this: https://atmospherejs.com/kadira/flow-router-ssr

:slight_smile:

6

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: https://atmospherejs.com/kadira/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 https://kadira.io for months.

7

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

1 Like
8

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.

9

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.

10

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

11

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' }
  }
}
12

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

13

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.