fix(useTrackerSuspense): Resolve unresponsiveness in withDeps and optimize subsequent updates

[welkinwong]

Summary

This PR addresses a critical responsiveness issue in the withDeps version of useTrackerSuspense and introduces a performance optimization for how subsequent updates are handled.

Changes

1. Fix: Unresponsiveness in withDeps version

   • Problem: The withDeps implementation was becoming unresponsive after the initial render, causing the component to not update when its dependent data changed.
   • Solution: The root cause has been identified and fixed, ensuring that components now reactively update as expected.

2. Performance Optimization: Subsequent Updates

   • Problem: Previously, all subsequent data updates would trigger a new Promise, causing the Suspense boundary to fallback to the loading state again. This resulted in a poor user experience with unnecessary loading spinners and content flickering.
   • Solution: Updated the logic so that after the initial data load, subsequent updates return the new data directly without throwing a Promise. This prevents the Suspense boundary from reverting to its fallback state and allows for smooth, in-place updates.

Impact

• Fixes: Components using useTracker with deps will now remain responsive to data changes.
• Improves: User experience is significantly enhanced as updated data is rendered seamlessly without triggering loading states.
• Maintains: The core Suspense-driven behavior for the initial data fetch remains unchanged.

[nachocodoner]

How great is to see your PRs all time! Thanks.

Just out of curiosity, can these optimizations also be applied to useTracker when it's not used within react-meteor-data/suspense? import { useTracker } from 'meteor/react-meteor-data'?

I'm also wondering if it's fine to use the suspense version in other parts of the code, and what the differences would be.

[welkinwong]

@nachocodoner You're absolutely right - these optimizations can indeed be applied to the non-suspense version (import { useTracker } from 'meteor/react-meteor-data'). Once the suspense version becomes stable, we can backport these optimizations to the non-suspense version.

To be honest, I've been thinking about whether we could potentially unify the suspense and non-suspense versions into a single version in the future. We could detect whether the user's reactiveFn returns a Promise or not, and then decide whether to throw the Promise accordingly. This approach would allow us to expose only unified useTracker, useSubscribe, and useFind APIs. It would also automatically provide helpful warnings for user mistakes - like using async functions in non-suspense environments.

Regarding using the suspense version in other parts of the code - absolutely, as long as the parent component in React is wrapped with <Suspense> (otherwise React would fall back to the error boundary).

The main difference between suspense and non-suspense versions lies in their adaptation to React 18/19+ components wrapped with <Suspense>. By throwing Promises, the suspense version allows parent React components to trigger fallback (loading) states and resume rendering once data is ready. This eliminates the need for numerous const [loading, setLoading] = useState(false) declarations, makes component behavior more synchronous, and significantly simplifies handling multiple dependent data requests.

[nachocodoner]

Thank you for the detail explanation.

Indeed, it would be good to unify them or at least bring the same optimziations. Many users still use the non-suspense version, and the work of optimization you did will bring them those gains. We may consider that for later. 🙏