Multiple suspense useTracker slow loading

[Dani055]

Using more than a few suspense trackers that have the same suspense results in really slow loading times. This is quite a pain, as it is currently a roadblock in our way to transition to Meteor V3.

We have quite a lot of isomorphic code we need to make async and the suspense trackers are documented in the official Meteor migration guide as a way to handle that. Guide

The problem is that using more than just a few of them results in really slow loading times. I have not yet been able to pin the exact amount - on larger production apps with more React components it seems to be around 4-5, but on a fresh Meteor app (reproduction repo below) more than 10 start being a problem.

Reproduction repo

Reproduction is quite simple.

• meteor npm i
• Start the meteor app with npm run start or npm run start-single-database if there's a MongoDB instance running on the machine.
• The component that has the trackers in it is the one under the / route
• alternatively, watch the demo video I uploaded in the repo

Would really appreciate help with this issue, or ideas for contributing to resolve it.

[nachocodoner]

Thanks for the detailed reproduction. I don’t have input yet, but I’ll look into it when I have time. It seems useTracker for Suspense hasn’t been updated in two years. When we adapted the other hooks for the Suspense version recently, we didn’t revisit this one.

Tagging @welkinwong, who added Suspense support for useFind and others. Do you have any idea what could be causing the slowdown?

[welkinwong]

Thanks for the detailed reproduction. I don’t have input yet, but I’ll look into it when I have time. It seems useTracker for Suspense hasn’t been updated in two years. When we adapted the other hooks for the Suspense version recently, we didn’t revisit this one.

Tagging @welkinwong, who added Suspense support for useFind and others. Do you have any idea what could be causing the slowdown?

@nachocodoner The original code immediately cleared the cache after each Promise was resolved. This caused components to re-throw Promises on updates, leading to exponential growth in Promise throws with multiple useTracker instances. Actually, immediate cache clearance is only needed on the server side.

@Dani055 I've fixed this issue. Before the PR gets merged, if you have time, you can clone https://github.com/welkinwong/react-packages/tree/master/packages/react-meteor-data to your project's packages folder and test it to see if there are any other issues.

[Dani055]

@nachocodoner @welkinwong Thank you for your quick response and action. I tried more than 30 trackers in the reproduction repo and it's definitely usable now. There's still a tiny noticable slowdown as the tracker numbers increase, but I'm guessing that could just be a limit of React/the implementation itself.

I'm also noticing a double flicker of the suspense as the page is refreshed (only on refresh, changing the URL with React router does not make it flicker). At first I thought it was related to strict mode, but the project has that turned off.

[welkinwong]

@Dani055 By "double flicker," do you mean transitioning from blank to displaying data? This occurs because the data hasn't reached the local state yet. You can try switching to suspense/useSubscribe to subscribe to the data, which will result in synchronous data loading (no flickering).

[Dani055]

@welkinwong By "double flicker" I mean:

• Refresh page
• Suspense shows (Loading...)
• UI with loaded information shows briefly
• Suspense shows (Loading...)
• UI shows with loaded information again

[welkinwong]

@Dani055 The issue is likely because Meteor.subscribe('') causes data to arrive asynchronously, and useTrack monitors both the initial query and reactive query, throwing twice promise. You can try switching to suspense/useSubscribe to see if this problem persists. If the issue persists, please provide a reproducible repository.

[welkinwong]

@welkinwong By "double flicker" I mean:

• Refresh page
• Suspense shows (Loading...)
• UI with loaded information shows briefly
• Suspense shows (Loading...)
• UI shows with loaded information again

@Dani055 It's possible that this is connected to #457.

[Dani055]

@welkinwong Using useSubscribe did indeed remove the flicker on reload. I can't find any more obvious bugs in the playground repo. Once the fix is rolled out and we can move our project to the new version, if we find anything else I'll be sure to report it in an issue.

On this note, I have a question for you:
The docs of suspense/useTracker mention you need to use Tracker.withComputation to keep reactivity in case the function is more complex than a simple find. Suppose we have the following example:

  const shouldShow = useTracker("shouldShow", async () => {
    const collection1 = await Collection1.find().fetchAsync();

    if(logic){
      ...
    }

    const collection2 = await Collection2.fetchAsync();
    for(const l of logic){
      ...
    }

    const item = await Collection1.findOneAsync({_id: id})

    return item ? true : false
  })

What's the correct way of keeping reactivity here? Should Tracker.withComputation wrap the whole function or just the Meteor collection await lines?

[welkinwong]

@welkinwong Using useSubscribe did indeed remove the flicker on reload. I can't find any more obvious bugs in the playground repo. Once the fix is rolled out and we can move our project to the new version, if we find anything else I'll be sure to report it in an issue.

On this note, I have a question for you: The docs of suspense/useTracker mention you need to use Tracker.withComputation to keep reactivity in case the function is more complex than a simple find. Suppose we have the following example:

  const shouldShow = useTracker("shouldShow", async () => {
    const collection1 = await Collection1.find().fetchAsync();

    if(logic){
      ...
    }

    const collection2 = await Collection2.fetchAsync();
    for(const l of logic){
      ...
    }

    const item = await Collection1.findOneAsync({_id: id})

    return item ? true : false
  })

What's the correct way of keeping reactivity here? Should Tracker.withComputation wrap the whole function or just the Meteor collection await lines?

@Dani055 If your tracker callback only contains a single reactive read (e.g., one find().fetchAsync() with no preceding await), you can skip Tracker.withComputation—the dependency is recorded before any async hops. As soon as you introduce multiple reactive calls separated by await, wrap the entire function so the same computation context is restored for every awaited step:

const shouldShow = useTracker("shouldShow", async (comp) =>
  Tracker.withComputation(comp, async () => {
    const collection1 = await Collection1.find().fetchAsync()

    if (logic) {
      // ...
    }

    const collection2 = await Collection2.fetchAsync()
    for (const l of logic) {
      // ...
    }

    const item = await Collection1.findOneAsync({ _id: id })
    return Boolean(item)
  })
)

[nachocodoner]

FYI, this issue has been added to react-meteor-data@4.0.1-beta.1. Could you verify it is ok for you and fixed?

[Dani055]

I updated our project with react-meteor-data@4.0.1-beta.1 and we're not running into issues where we were before. It's hard identify any other issues right now, as it is going to take us time to move from the sync useTracker to the suspense one.