c6e2607f1f
This came up now because Timeline uses a MappedList to map PendingEvents to PendingEventEntries. In the map function, we setup links between entries to support local echo for relations. When opening a timeline that has unsent relations, the initial populating of the MappedList will try to emit an update for the target entry in remoteEntries. This all happens while the ListView of the timeline is calling subscribe and all collections in the chain are populating themselves based on their sources. This usually entails calling subscribe on the source, and now you are subscribed, iterate over the source (as you're not allowed to query an unsubscribed observable collection, as it might not be populated yet, and even if it did, it wouldn't be guaranteed to be up to date as events aren't flowing yet). So in this concrete example, TilesCollection hadn't populated its tiles yet and when the update to the target of the unsent relation reached TilesCollection, the tiles array was still null and it crashed. I thought what would be the best way to fix this and have a solid model for observable collections to ensure they are always compatible with each other. I considered splitting up the subscription process in two steps where you'd first populate the source and then explicitly start events flowing. I didn't go with this way because it's really only updates that make sense to be emitted during setup. A missed update wouldn't usually bring the collections out of sync like a missed add or remove would. It would just mean the UI isn't updated (or any subsequent filtered collections are not updated), but this should be fine to ignore during setup, as you can rely on the subscribing collections down the chain picking up the update while populating. If we ever want to support add or remove events during setup, we would have to explicitly support them, but for now they are correct to throw. So for now, just ignore update events that happen during setup where needed. |
||
|---|---|---|
| .github/workflows | ||
| assets | ||
| doc | ||
| prototypes | ||
| scripts | ||
| src | ||
| .dockerignore | ||
| .editorconfig | ||
| .eslintignore | ||
| .eslintrc.js | ||
| .gitignore | ||
| .gitlab-ci.yml | ||
| codestyle.md | ||
| Dockerfile | ||
| Dockerfile-dev | ||
| index.html | ||
| LICENSE | ||
| package.json | ||
| README.md | ||
| sw.js | ||
| TODO.md | ||
| yarn.lock | ||
Hydrogen
A minimal Matrix chat client, focused on performance, offline functionality, and broad browser support. This is work in progress and not yet ready for primetime. Bug reports are welcome, but please don't file any feature requests or other missing things to be on par with Element Web.
Goals
Hydrogen's goals are:
- Work well on desktop as well as mobile browsers
- UI components can be easily used in isolation
- It is a standalone webapp, but can also be easily embedded into an existing website/webapp to add chat capabilities.
- Loading (unused) parts of the application after initial page load should be supported
If you find this interesting, come and discuss on #hydrogen:matrix.org.
How to use
Hydrogen is deployed to hydrogen.element.io. You can run it locally yarn install (only the first time) and yarn start in the terminal, and point your browser to http://localhost:3000. If you prefer, you can also use docker.
Hydrogen uses symbolic links in the codebase, so if you are on Windows, have a look at making git & symlinks work there.
FAQ
Some frequently asked questions are answered here.