React-meteor-data hooks and SSR best practice

react
1

I’ve just been reviewing react-meteor-data and had some questions that I haven’t had to ask before.

(because I used Vue, or I used TanStack Query, or I never touched the hooks API for Meteor before, etc)

Firstly, it looks like the suspense version of useSubscribe internally passes subscription parameters to useEffect’s dependency array, but the original non-suspense version doesn’t; is there some sort of performance or rendering implication there? Does it matter if a non-suspense useSubscribe is in a frequently re-rendered function?

Secondly, I got caught on this last line for the suspense version of useFetch:

This is a version of useFind that can be used with React Suspense […] third parameter is optional, and it is dependency array object. It’s meant for the SSR, you don’t have to use it if you’re not interested in SSR

:raised_hand: that’s me, I’m interested in SSR!

I just was a bit confused what was meant here. I personally like the non-suspense API for useFetch more, does this mean though for SSR I must use the suspense function? Likewise, if using SSR, I must pass all (stateful/prop-drilled) dependencies used in the query in this array at the end?

Thanks for any insights from the resident Meteor+React peeps!

1 Like
2

If I recall correctly, if all is done in the “react-way,” it should be better: it will re-render only when necessary, and it gets cleaned up too. I think ideally you should create your subscriptions upper of the three and then your useFinds should just work

not a must, but it should be better to use the suspense functions, especially because those are likely the future.

Regular useFind:

useFind(() => TestDocs.find(), [])

It is sync because it is using minimongo, so this whole operation is being done in the client! No need to call suspense.

Why I need the suspense version then?

TestDocs in the server won’t be a minimongo collection but rather an actual MongoDB collection, thus under the hood it will be using MongoDB methods, and those do return promises and that is why is necessary to suspend, we need to deal with them.

Now for the arguments:

Yes!
similar to what you would do for the non-suspendable version, is quite different, but it just works, given our example, where id is a reactive data:

useFind(() => TestDocs.find({userAge: age}), [age])

in our suspensable example:

const tasksByUser = useFind(TestDocs, [
    {userAge: age},
  ], [age]);

This is mostly needed because we need to serialize all those params.

1 Like
3

Aaaah, thank you Grubba, thank helps me a lot!

The last time I used React with subscribe was probably with Fibers, and I forgot that with SSR the server context is now missing the sync API even though it’s “client side” code… :man_facepalming:

I need to get some practice writing Suspense style React code…