We use `export default` begrudgingly here. Ideally we'd use just `export`, though this entire SDK expects things to be exported as a default. Instead of breaking everything, we'll sacrifice our export pattern for a smaller diff - a later commit can always do the default export -> regular export conversion.
Verification with cross-signing may requiring asking for your secret storage
passphrase, which is displayed in it's own modal on top of flows. For now while
verification takes in modals also, mark the verification ones as static so they
don't lose state when secret storage appears on top mid-flow.
With a switch to Only One Webpack™ we need a way to help developers generate the component index without a concurrent watch task. The best way to do this is to have developers import their components, but how do they do that when we support skins? The answer in this commit is to change skinning.
Skinning now expects to receive your list of overrides instead of the react-sdk+branded components. For Riot this means we send over *only* the Vector components and not Vector+react-sdk.
Components can then be annotated with the `replaceComponent` decorator to have them be skinnable. The decorator must take a string with the dot path of the component because we can't reliably calculate it ourselves, sadly.
The decorator does a call to `getComponent` which is where the important part of the branded components not including the react-sdk is important: if the branded app includes the react-sdk then the decorator gets executed before the skin has finished loading, leading to all kinds of fun errors. This is also why the skinner lazily loads the react-sdk components to avoid importing them too early, breaking the app.
The decorator will end up receiving null for a component because of the getComponent loop mentioned: the require() call is still in progress when the decorator is called, therefore we can't error out. All usages of getComponent() within the app are safe to not need such an error (the return won't be null, and developers shouldn't use getComponent() after this commit anyways).
The AuthPage, being a prominent component, has been converted to demonstrate this working. Changes to riot-web are required to have this work.
The reskindex script has also been altered to reflect these skinning changes - it no longer should set the react-sdk as a parent. The eventual end goal is to get rid of `getComponent()` entirely as it'll be easily replaced by imports.
This lays a foundation for redirecting all the traffic through the new store, but for now the core parts of the app need to stop caring if the right panel is open.
With this version of babel (via babel-eslint), eslint now fails
with a somewhat confusing, "Unexpected reserved type number"
(from the flow plugin...) if you get this wrong.
Fixes https://github.com/vector-im/riot-web/issues/11496
Fixes https://github.com/vector-im/riot-web/issues/11385
Fixes https://github.com/vector-im/riot-web/issues/10007
Fixes https://github.com/vector-im/riot-web/issues/9769
React does (kinda) bind `this._isUnmounting` for us in the context of the EventTile, but the EventTile then passes the function straight through to the ReadReceiptMarker component, which then binds it in the context of EventTile. This results in `this._mounted` being falsey all the time, preventing the ReadReceiptMarker from hitting the code where it updates rrInfo in its unmount.
The velocity stuff is smart enough to realize that it has a read receipt and shuffles everything over by one, but when it goes to check the starting height (which will be null/undefined because the RRMarker didn't update it) it assumes it has never seen the receipt before and appends it again - this is what causes some holes/stacking.
By forcefully binding the `this._isUnmounting` function we ensure that the `this._mounted` variable is correctly referenced in the context of the MessagePanel, allowing the RRMarker to update its position, and therefore allowing the velocity behaviour to be consistent.
Removes one of the two places we use Velocity, so we're one step
closer to getting rid of it for good.
Should therefore fix the fact that Velocity is leaking data entries
and therefore <hr> elements.
Hopefully also makes the logic in getEventTiles incrementally simpler,
if still somwewhat byzantine.
I was about to add the getDerivedStateFromProps function to change
how read markers worked, but doing that in an old style class
means the statics object, so let;s just convert the thing.
This fixes the login page to be more helpful when the current homeserver is
unreachable: it reveals the server change field, so you have some chance to
progress forward.
Fixes https://github.com/vector-im/riot-web/issues/11077
This adds very basic cache (literally just a `Map` for now) to store room alias
to room ID mappings. The improves the perceived performance of Riot when
switching rooms via browser navigation (back / forward), as we no longer try to
resolve the room alias every time.
The cache is only in memory, so reloading manually or as part of the clear cache
process will start afresh.
Fixes https://github.com/vector-im/riot-web/issues/10020
As the FilePanel is now rendered as part of the RoomView,
we don't need to respond to room changes, as RoomView has
a key of the roomId, so the whole subtree would be recreated.
If discovery results in a warning for the identity server (as in can't be found
or is malformed), this allows you to continue signing in and shows the warning
above the form.
Fixes https://github.com/vector-im/riot-web/issues/11102
We need to reset the scroll offset otherwise the component may be
scrolled past the only content it has (Chrome just corrected the
scroll offset but Firefox scrolled it anyway).
NB. Introducing the new deriveStateFromProps method seems to
means that react no longer calls componentWillMount so I've
had to change it to componentDidMount (which it should have
been anyway).
Fixes https://github.com/vector-im/riot-web/issues/11263
This patch extends our search to include our platform specific event
index.
There are 3 search scenarios and are handled differently when platform
support for indexing is present:
- Search a single non-encrypted room: Use the server-side search
like before.
- Search a single encrypted room: Search using our platform specific
event index.
- Search across all rooms: Search encrypted rooms using our local
event index. Search non-encrypted rooms using the classic
server-side search. Combine the results.
The combined search will result in having twice the amount of search
results since comparing the scores fairly wasn't deemed sensible.
A sync call may not have all events that happened since the last time
the client synced. In such a case the room is marked as limited and
events need to be fetched separately.
When such a sync call happens our event index will have a gap. To
close the gap checkpoints are added to start crawling our room again.
Unnecessary full re-crawls are prevented by checking if our current
/room/roomId/messages request contains only events that were already
present in our event index.
This patch adds support to create an event index if the clients platform
supports it and starts an event crawler.
The event crawler goes through the room history of encrypted rooms and
eventually indexes the whole room history of such rooms.
It does this by first creating crawling checkpoints and storing them
inside a database. A checkpoint consists of a room_id, direction and
token.
After the checkpoints are added the client starts a crawler method in
the background. The crawler goes through checkpoints in a round-robin
way and uses them to fetch historic room messages using the
rooms/roomId/messages API endpoint.
Every time messages are fetched a new checkpoint is created that will
be stored in the database with the fetched events in an atomic way, the
old checkpoint is deleted at the same time as well.
