mattermost / mattermost-mobile

Next generation iOS and Android apps for Mattermost in React Native
https://about.mattermost.com/
Apache License 2.0
2.25k stars 1.36k forks source link

The local storage redux-persist will grow infinitely, thus making app slower and slower? #4645

Closed fzyzcjy closed 3 years ago

fzyzcjy commented 4 years ago

Submit feature requests to http://www.mattermost.org/feature-requests/. File non-security related bugs here in the following format:

Summary

IMHO, after reviewing the code, it seems that the local storage will grow infinitely. The reason is that, redux-persist will persist the whole state tree into AsyncStorage. Thus the longer a user uses, the bigger the state tree will be. Thus, not only will the storage be big, but the users will feel slower (since the state tree is bigger and bigger infinitely).

Thanks very much for any suggestions, or pointing out where I am wrong :)

Environment Information

N/A

Steps to reproduce

N/A

Expected behavior

N/A

Observed behavior

N/A

Possible fixes

N/A

enahum commented 4 years ago

@fzyzcjy we have this middleware that cleans up the reducers once you send the app to the background https://github.com/mattermost/mattermost-mobile/blob/master/app/store/middlewares/message_retention.js#L59

That being said, we are also working on a new version (designing stage) that won't be using redux but a proper database instead.

fzyzcjy commented 4 years ago

Get it, thanks! IMHO this may be a little bit complicated... Naively I originally thought there may be a way that this (cleaning up) can be done quite trivially!

enahum commented 4 years ago

If you have any ideas suggestions, feel free to share them

fzyzcjy commented 4 years ago

Yes I am writing my suggestion! Wait a minute :)

fzyzcjy commented 4 years ago

My naive suggestion

We can first build a graph of references. For example, to say "if we want to keep postId=42, we need to keep the reaction data associated to it" (here), we annotate that "hey state.entities.posts.reactions's primary key is a post.id).

Then we can mimic the Java GC (of course not the full algorithm), i.e., we can start from some objects that we want to keep (say postId=100,200,300), then find its references (say reaction=aaa,bbb), then find its references of references, etc. Finally we have a sub-graph of what we want to keep and just persist that sub-graph.

enahum commented 4 years ago

It sounds like a good idea, are you willing to give it a try and submit a PR?

fzyzcjy commented 4 years ago

I can do that in my free time :)