- Migrate threads to DB when needed
- Use threads from DB and avoid fetching from keyserver when data is present.
Depends on D9956
Details
Details
- Reviewers
tomek michal - Commits
- rCOMM65c3cc5b137b: [web] start using threads from database
Test plan was done twice, in Chrome and Safari:
- Check if migrating works
- Check if threads are not fetched from keyserver when there are in DB
- Modify thread and reload app
- Modify thread on different account
- Close app, modify thread on different account and open app (test if checkpointing works)
I tested this on the account with ~4k threads, I didn't notice any perf downgrade, moreover, I think initial app load was faster when reading threads from DB.
Diff Detail
Diff Detail
- Repository
- rCOMM Comm
- Branch
- publish-web-persistence
- Lint
No Lint Coverage - Unit
No Test Coverage
Event Timeline
| web/redux/initial-state-gate.js | ||
|---|---|---|
| 33 | I think your IDE added this | |
| keyserver/src/responders/redux-state-responders.js | ||
|---|---|---|
| 95 | Can we use canUseDatabaseOnWeb from https://phab.comm.dev/D9948? | |
| 161 | I'm wondering if it would be beneficial to differentiate between empty thread infos and excluding them. So in this case, instead of returning an empty object, we would return e.g. null. Would that be useful? | |
| web/redux/initial-state-gate.js | ||
| 65 | Should we check the length just like in https://phab.comm.dev/D9954? | |
| 72 | Can we use canUseDatabaseOnWeb? | |
Comment Actions
address review
| keyserver/src/responders/redux-state-responders.js | ||
|---|---|---|
| 161 | I don't think that improves or changes anything, there is no advance in the current state. | |
| web/redux/initial-state-gate.js | ||
| 33 | ahhh... IDE did it again 😠 | |
| 65 | This is the result of the function from D9954. So the check if inside getClientStore | |
| 72 | sure, that was my idea but I messed something while creating diff | |