224d56698a
when doing a limited sync, and a new fragment is created, this._lastLiveKey is updated immediately. If the transaction would then fail, the fragmentId in this._lastLiveKey was incremented but the fragment wasn't written to the store, so if sync is resumed and would subsequently succeed, fragmentIds would be assigned to events that don't have a corresponding fragment in the timelineFragment store. This would throw errors when trying to load the timeline, breaking the whole app. This changes SyncWriter to only update this._lastLiveKey in the emit phase, when the transactions has been committed already. |
||
|---|---|---|
| doc | ||
| prototypes | ||
| scripts | ||
| src | ||
| .editorconfig | ||
| .eslintrc.js | ||
| .gitignore | ||
| icon.png | ||
| index.html | ||
| package-lock.json | ||
| package.json | ||
| README.md | ||
| yarn.lock | ||
Brawl
A minimal Matrix chat client, focused on performance, offline functionality and working on my Lumia 950 Windows Phone.
Status
Brawl can currently log you in, or pick an existing session, sync already joined rooms, fill gaps in the timeline, and send text messages. Everything is stored locally.
Why
I started writing Brawl both to have a functional matrix client on my aging phone, and to play around with some ideas I had how to use indexeddb optimally in a matrix client.
For every interaction or network response (syncing, filling a gap), Brawl starts a transaction in indexedb, and only commits it once everything went well. This helps to keep your storage always in a consistent state. As little data is kept in memory as well, and while scrolling in the above GIF, everything is loaded straight from the storage.
If you find this interesting, feel free to reach me at @bwindels:matrix.org.
How to use
You can try Brawl here, or try it locally by running yarn install (only the first time) and yarn start in the terminal, and point your browser to http://localhost:3000.