Everything you wrote looks fine. Rerenders are designed to be cheap, and even disposable in React (in fact, concurrent rendering mode depends on the disposability of “stateless” functional components). You should only worry about it if it slows everything down.
One thing you might need to wrap your head around with
useTracker, is that it will run and rerun for it’s entire lifecycle - which is probably a newer concept coming from PHP. It does things when the component is mounted, like starting a subscription, which will update the computation whenever anything it subscribed to changes, including loading and individual document change events, and that will cause rerender. That’s probably what you want.
A react rerender will not rerun everything in the computation from scratch every time (it might rerun the Mongo query though, if you don’t use deps), so you don’t have to worry about it restarting the subscription on every re-render. Subscriptions are only started on mount - at the beginning of the lifecycle. When the component is unmounted (you navigate to another route, with different components, etc.), then the computation is destroyed, and subscriptions stopped, etc.
One thing that wasn’t clear in your writeup though - you should NOT call methods from
useTracker. That would cause the method to be invoked every time the computation is run, which can happen for a whole bunch of reasons.
useEffect with deps is the right place to call a computation. One interesting pattern you can use, is you can use
useEffect to call a method, then update a local memory only collection (or use
ground:db), and in the same component, if you have
useTracker set up to query that collection, it’ll update the react component like magic! (Or you could just use local react state, the meteor way would get you a global data store that can be used in multiple component instances.)