Closed fzyzcjy closed 3 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.
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!
If you have any ideas suggestions, feel free to share them
Yes I am writing my suggestion! Wait a minute :)
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.
It sounds like a good idea, are you willing to give it a try and submit a PR?
I can do that in my free time :)
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