Will the application-wide LocalState variable impact the performance of an app when we are setting up more and more reactive LocalState?

[ezforw]

The states were not destroyed when switching between different routes, although we can set it to null when unmounting, but it would still watching for changes in LocalState even we don't really need it.

Is there anyway we can destroy the states once it's not been used anymore?

[fermuch]

Can you specify a little more?
When the container is destroyed (when you switch routes), all the dependencies tracker generated are also destroyed, including subscriptions to LocalState.

[ezforw]

I watch for changes of LocalState keys whenever the route is changed
Tracker.autorun(function() { FlowRouter.watchPathChange(); console.log(LocalState.keys); });
Let's say both route A & B has 10 LocalState keys.

When navigate to route A, there're 10 keys in LocalState, then navigate to route B, there will be 20 keys in LocalState.

The LocalState keys were not destroyed after switching routes.

[fermuch]

This seems more like a problem with how you're managing your functions.
I couldn't replicate your error. Can you set up a repo where we can see this problem?

[ezforw]

Checkout this repo cloned from mantra sample app https://github.com/ezpub/mantra_sample_blog_localstate_test.git

You will see it in console, LocalState persists between different routes.

As our app grows, there'll be a lot of reactive states, and we really only need the ones that are related to the current page.

I can reset the LocalState to a new ReactiveDict when the route is changed, but I thought by using the structure of Mantra, this could be handled by itself.

The way Mantra uses LocalState is almost the same as using Session (which is not encouraged to use extensively) from what I see.

Correct me if I'm saying something wrong.

[Kshatra]

LocalState.key just gives you data that is internally stored inside reactiveDict. True that the keys cannot be deleted after initialization. And i understand that it may seem sort of ugly. But they has no performance influence on application. The reactive dependencies to this internal data DOES. When Tracker meets some TheReactiveVar.set() it looks throuh list of dependencies (array of functions that are passed to Tracker.autorun() and have TheReactiveVar.set() inside their bodies). But, as fermuch said, "when the container is destroyed (when you switch routes), all the dependencies tracker generated are also destroyed".