...on room switch. We were setting most of the state in viewRoom,
but getting the current room ID from the RoomViewStore, but this
meant we did one setState from the RoomViewStore updating,
re-rendered and then setState again in viewRoom causing another
render. This just sets the room ID in viewRoom.
- this should fix a race where if the 'hangup' arrives hard on the tail of the
Call.incoming, we don't ignore it.
(We still have a problem in that we blip the hangup tone and UI, but that is
arguably a separate problem)
the RightPanel will be mounted once we're done doing the first sync, so wait until then and then dispatch a view_user. This is not very nice but it's what we do for view_room.
With the fallback of existing behaviour, which is UserView (no middle panel and no avatar, display name).
To improve, MemberInfo should probably track the current roomId and userId and then update the view asynchronously by re-fetching the member object when either roomId or userId change.
Also, it should be hitting the profile API to get the user's avatar if a room hasn't been specified.
This is mostly with the intent of making the login tests more reliable, but it
seems generally worthwhile:
* keep screenAfterLogin in the object props rather than `state` so that we can
clear it without triggering a rerender
* also move our record of the window width to the object props, and call
`handleResize` from componentWillMount rather than componentDidMount so that
we don't trigger a rerender by updating `state.width`
* Remove update of unused `loading` state
* don't just log errors without any context as to where they came from or what
they mean
* avoid the use of '%s' and multi-argument console.log because it looks awful
under karma.
Fixes riot-web#4334
When we do a token login, don't carry on with the normal app startup
(transitioning to the loggedIn state etc) - instead tell the app about the
successful login and wait for it to redirect.
Replace onLoadCompleted with onTokenLoginCompleted so that the app can see what
it's supposed to be doing.
MatrixChat is essentially a glorified state machine, with its states partially
determined by the loading, loggedIn and loggingIn state flags. If we actually
make each of the states implied by those flags an explicit 'view', then
everything gets much clearer.
'screen' is overloaded, as it us used for the parameter of `showScreen` (and,
by implication, `state.screenAfterLogin`). Attempt to clear up the confusion by
replacing 'screen' with 'view' and using some constants for the potential
values.
This should be a no-op!
This fixes an unintuitive behaviour where, if you follow a link to
riot.im/app/#/login, we take you to the login page, but not before we've
registered a guest account (or restarted the MatrixClient with the stored
creds).
This actually ends up simplifying some of the startup dance, as we special-case
the registration flows earlier on.
Fix for https://github.com/vector-im/riot-web/issues/4224
Due to the way `MatrixChat` does a state update when the `view_room` dispatch fires and a second update when `RoomViewStore` sends an update, the current event ID and room ID were becoming out of sync. The solution devised was to have the event ID managed by the `RoomViewStore` itself and do any defaulting there (for when we revisit a room that we saved scroll state for previously).
This required a few changes:
- The addition of `update_scroll_state` in `RoomViewStore` allows the `RoomView` to save scroll state for a room before swapping to another one. Previously the caching of scroll state was done in `RoomView`.
- The `view_room` dispatch now accepts an `event_id`, which dictates which event is supposed to be scrolled to in the `MessagePanel` when a new room is viewed. It also accepts `event_offset`, but currently, this isn't passed in by a dispatch in the app, but it is clobbered when loading the default position when an `event_id` isn't specified. Finally, `highlighted` was added to distinguish whether the initial event being scrolled to is also highlighted. This flag is also used by `viewRoom` in `MatrixChat` in order to decide whether to `notifyNewScreen` with the specified `event_id`.
This reverts commit c3d37c1ff9.
This commit was introducing a bug where no rooms would be shown if
you want straight to /#/login and logged in (because this causes
a guest session to be created but the indexeddb store not to be
cleared, so the new login picks up the stale indexedb sync data.
Before, we were relying on the fact that `ready` would still have
been false from before. This was not the case, for example, if we
naviagted straight to /#/login (which causes a guest session to be
set up and the sync for that completes after we navigate to the
login screen).
We should always mark ourselves as not-ready after login since we
will always have to wait for the sync.
In order to get ILAG internationalised
Conflicts:
src/components/structures/LoggedInView.js
src/components/structures/MatrixChat.js
src/components/views/dialogs/ChatCreateOrReuseDialog.js
src/components/views/dialogs/SetDisplayNameDialog.js
src/createRoom.js
src/i18n/strings/en_EN.json
This reverts commit c3d37c1ff9.
This commit was introducing a bug where no rooms would be shown if
you want straight to /#/login and logged in (because this causes
a guest session to be created but the indexeddb store not to be
cleared, so the new login picks up the stale indexedb sync data.
This is a URL that can be used to start a chat with a user.
- If the user is a guest, setMxId dialog will appear before anything and a defered action will cause `ChatCreateOrReuseDialog` to appear once they've logged in.
- If the user is registered, they will not see the setMxId dialog.
fixes https://github.com/vector-im/riot-web/issues/4034
but with this at least clicking on a text input will not make you
be thrown into composer instead
Signed-off-by: Michael Telatynski <7t3chguy@gmail.com>
These must now make a dispatch to RoomViewStore instead of calling `viewRoom` directly on MatrixChat. This will call both `viewRoom` of MatrixChat _and_ the logic in RVS so there is some redundancy here. It'd be best to move as much as possible of viewRoom out to the RVS itself.
But for now, this fixes a bug that occures when leaving (the viewed room would not change).
This changes the default behaviour of displaying the room directory to instead displaying the default homepage. If specified, the config "welcomePageUrl" can be used to override the default '/home.html'.
This allows for a truely flux-y way of storing the currently viewed room, making some callbacks (like onRoomIdResolved) redundant and making sure that the currently viewed room (ID) is only stored in one place as opposed to the previous many places.
This was required for the `join_room` action which can be dispatched to join the currently viewed room.
Another change was to introduce `LifeCycleStore` which is a start at encorporating state related to the lifecycle of the app into a flux store. Currently it only contains an action which will be dispatched when the sync state has become PREPARED. This was necessary to do a deferred dispatch of `join_room` following the registration of a PWLU (PassWord-Less User).
The following actions are introduced:
- RoomViewStore:
- `view_room`: dispatch to change the currently viewed room ID
- `join_room`: dispatch to join the currently viewed room
- LifecycleStore:
- `do_after_sync_prepared`: dispatch to store an action which will be dispatched when `sync_state` is dispatched with `state = 'PREPARED'`
- MatrixChat:
- `sync_state`: dispatched when the sync state changes. Ideally there'd be a SyncStateStore that emitted an `update` upon receiving this, but for now the `LifecycleStore` will listen for `sync_state` directly.
