core: refactor routing
Unfortunately, as the Jitsi Meet development evolved the routing mechanism
became more complex and thre logic ended up spread across multiple parts of the
codebase, which made it hard to follow and extend.
This change aims to fix that by rewriting the routing logic and centralizing it
in (pretty much) a single place, with no implicit inter-dependencies.
In order to arrive there, however, some extra changes were needed, which were
not caught early enough and are thus part of this change:
- JitsiMeetJS initialization is now synchronous: there is nothing async about
it, and the only async requirement (Temasys support) was lifted. See [0].
- WebRTC support can be detected early: building on top of the above, WebRTC
support can now be detected immediately, so take advantage of this to simplify
how we handle unsupported browsers. See [0].
The new router takes decissions based on the Redux state at the time of
invocation. A route can be represented by either a component or a URl reference,
with the latter taking precedence. On mobile, obviously, there is no concept of
URL reference so routing is based solely on components.
[0]: https://github.com/jitsi/lib-jitsi-meet/pull/779
2018-06-29 07:58:31 +00:00
|
|
|
// @flow
|
2018-07-12 03:57:44 +00:00
|
|
|
|
core: refactor routing
Unfortunately, as the Jitsi Meet development evolved the routing mechanism
became more complex and thre logic ended up spread across multiple parts of the
codebase, which made it hard to follow and extend.
This change aims to fix that by rewriting the routing logic and centralizing it
in (pretty much) a single place, with no implicit inter-dependencies.
In order to arrive there, however, some extra changes were needed, which were
not caught early enough and are thus part of this change:
- JitsiMeetJS initialization is now synchronous: there is nothing async about
it, and the only async requirement (Temasys support) was lifted. See [0].
- WebRTC support can be detected early: building on top of the above, WebRTC
support can now be detected immediately, so take advantage of this to simplify
how we handle unsupported browsers. See [0].
The new router takes decissions based on the Redux state at the time of
invocation. A route can be represented by either a component or a URl reference,
with the latter taking precedence. On mobile, obviously, there is no concept of
URL reference so routing is based solely on components.
[0]: https://github.com/jitsi/lib-jitsi-meet/pull/779
2018-06-29 07:58:31 +00:00
|
|
|
import type { Component } from 'react';
|
|
|
|
|
|
|
|
import { isRoomValid } from '../base/conference';
|
|
|
|
import JitsiMeetJS from '../base/lib-jitsi-meet';
|
|
|
|
import { Platform } from '../base/react';
|
|
|
|
import { toState } from '../base/redux';
|
|
|
|
import { Conference } from '../conference';
|
|
|
|
import { getDeepLinkingPage } from '../deep-linking';
|
|
|
|
import { UnsupportedDesktopBrowser } from '../unsupported-browser';
|
|
|
|
import {
|
|
|
|
BlankPage,
|
|
|
|
WelcomePage,
|
|
|
|
generateRoomWithoutSeparator,
|
|
|
|
isWelcomePageAppEnabled,
|
|
|
|
isWelcomePageUserEnabled
|
|
|
|
} from '../welcome';
|
|
|
|
|
|
|
|
declare var interfaceConfig: Object;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Object describing application route.
|
|
|
|
*
|
|
|
|
* @typedef {Object} Route
|
|
|
|
* @property {Component} component - React Component constructor.
|
|
|
|
* @property {string|undefined} href - New location, in case navigation involves
|
|
|
|
* a location change.
|
|
|
|
*/
|
|
|
|
export type Route = {
|
|
|
|
component: Class<Component<*>>,
|
|
|
|
href: ?string
|
|
|
|
};
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Determines which route is to be rendered in order to depict a specific Redux
|
|
|
|
* store.
|
|
|
|
*
|
2018-07-12 03:57:44 +00:00
|
|
|
* @param {(Function|Object)} stateful - THe redux store, state, or
|
|
|
|
* {@code getState} function.
|
core: refactor routing
Unfortunately, as the Jitsi Meet development evolved the routing mechanism
became more complex and thre logic ended up spread across multiple parts of the
codebase, which made it hard to follow and extend.
This change aims to fix that by rewriting the routing logic and centralizing it
in (pretty much) a single place, with no implicit inter-dependencies.
In order to arrive there, however, some extra changes were needed, which were
not caught early enough and are thus part of this change:
- JitsiMeetJS initialization is now synchronous: there is nothing async about
it, and the only async requirement (Temasys support) was lifted. See [0].
- WebRTC support can be detected early: building on top of the above, WebRTC
support can now be detected immediately, so take advantage of this to simplify
how we handle unsupported browsers. See [0].
The new router takes decissions based on the Redux state at the time of
invocation. A route can be represented by either a component or a URl reference,
with the latter taking precedence. On mobile, obviously, there is no concept of
URL reference so routing is based solely on components.
[0]: https://github.com/jitsi/lib-jitsi-meet/pull/779
2018-06-29 07:58:31 +00:00
|
|
|
* @returns {Promise<Route>}
|
|
|
|
*/
|
2018-07-12 03:57:44 +00:00
|
|
|
export function _getRouteToRender(stateful: Function | Object): Promise<Route> {
|
core: refactor routing
Unfortunately, as the Jitsi Meet development evolved the routing mechanism
became more complex and thre logic ended up spread across multiple parts of the
codebase, which made it hard to follow and extend.
This change aims to fix that by rewriting the routing logic and centralizing it
in (pretty much) a single place, with no implicit inter-dependencies.
In order to arrive there, however, some extra changes were needed, which were
not caught early enough and are thus part of this change:
- JitsiMeetJS initialization is now synchronous: there is nothing async about
it, and the only async requirement (Temasys support) was lifted. See [0].
- WebRTC support can be detected early: building on top of the above, WebRTC
support can now be detected immediately, so take advantage of this to simplify
how we handle unsupported browsers. See [0].
The new router takes decissions based on the Redux state at the time of
invocation. A route can be represented by either a component or a URl reference,
with the latter taking precedence. On mobile, obviously, there is no concept of
URL reference so routing is based solely on components.
[0]: https://github.com/jitsi/lib-jitsi-meet/pull/779
2018-06-29 07:58:31 +00:00
|
|
|
const state = toState(stateful);
|
|
|
|
const { room } = state['features/base/conference'];
|
|
|
|
const isMobileApp = navigator.product === 'ReactNative';
|
|
|
|
const isMobileBrowser
|
|
|
|
= !isMobileApp && (Platform.OS === 'android' || Platform.OS === 'ios');
|
|
|
|
const route: Route = {
|
|
|
|
component: BlankPage,
|
|
|
|
href: undefined
|
|
|
|
};
|
|
|
|
|
|
|
|
return new Promise(resolve => {
|
2018-07-12 03:57:44 +00:00
|
|
|
// First, check if the current endpoint supports WebRTC. We are
|
core: refactor routing
Unfortunately, as the Jitsi Meet development evolved the routing mechanism
became more complex and thre logic ended up spread across multiple parts of the
codebase, which made it hard to follow and extend.
This change aims to fix that by rewriting the routing logic and centralizing it
in (pretty much) a single place, with no implicit inter-dependencies.
In order to arrive there, however, some extra changes were needed, which were
not caught early enough and are thus part of this change:
- JitsiMeetJS initialization is now synchronous: there is nothing async about
it, and the only async requirement (Temasys support) was lifted. See [0].
- WebRTC support can be detected early: building on top of the above, WebRTC
support can now be detected immediately, so take advantage of this to simplify
how we handle unsupported browsers. See [0].
The new router takes decissions based on the Redux state at the time of
invocation. A route can be represented by either a component or a URl reference,
with the latter taking precedence. On mobile, obviously, there is no concept of
URL reference so routing is based solely on components.
[0]: https://github.com/jitsi/lib-jitsi-meet/pull/779
2018-06-29 07:58:31 +00:00
|
|
|
// intentionally not performing the check for mobile browsers because:
|
2018-07-12 03:57:44 +00:00
|
|
|
// - the WelcomePage is mobile ready;
|
|
|
|
// - if the URL points to a conference, getDeepLinkingPage will take
|
|
|
|
// care of it.
|
core: refactor routing
Unfortunately, as the Jitsi Meet development evolved the routing mechanism
became more complex and thre logic ended up spread across multiple parts of the
codebase, which made it hard to follow and extend.
This change aims to fix that by rewriting the routing logic and centralizing it
in (pretty much) a single place, with no implicit inter-dependencies.
In order to arrive there, however, some extra changes were needed, which were
not caught early enough and are thus part of this change:
- JitsiMeetJS initialization is now synchronous: there is nothing async about
it, and the only async requirement (Temasys support) was lifted. See [0].
- WebRTC support can be detected early: building on top of the above, WebRTC
support can now be detected immediately, so take advantage of this to simplify
how we handle unsupported browsers. See [0].
The new router takes decissions based on the Redux state at the time of
invocation. A route can be represented by either a component or a URl reference,
with the latter taking precedence. On mobile, obviously, there is no concept of
URL reference so routing is based solely on components.
[0]: https://github.com/jitsi/lib-jitsi-meet/pull/779
2018-06-29 07:58:31 +00:00
|
|
|
if (!isMobileBrowser && !JitsiMeetJS.isWebRtcSupported()) {
|
|
|
|
route.component = UnsupportedDesktopBrowser;
|
|
|
|
resolve(route);
|
|
|
|
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (isRoomValid(room)) {
|
|
|
|
if (isMobileApp) {
|
|
|
|
route.component = Conference;
|
|
|
|
resolve(route);
|
|
|
|
} else {
|
|
|
|
// Update the location if it doesn't match. This happens when a
|
|
|
|
// room is joined from the welcome page. The reason for doing
|
2018-07-12 03:57:44 +00:00
|
|
|
// this instead of using the history API is that we want to load
|
|
|
|
// the config.js which takes the room into account.
|
core: refactor routing
Unfortunately, as the Jitsi Meet development evolved the routing mechanism
became more complex and thre logic ended up spread across multiple parts of the
codebase, which made it hard to follow and extend.
This change aims to fix that by rewriting the routing logic and centralizing it
in (pretty much) a single place, with no implicit inter-dependencies.
In order to arrive there, however, some extra changes were needed, which were
not caught early enough and are thus part of this change:
- JitsiMeetJS initialization is now synchronous: there is nothing async about
it, and the only async requirement (Temasys support) was lifted. See [0].
- WebRTC support can be detected early: building on top of the above, WebRTC
support can now be detected immediately, so take advantage of this to simplify
how we handle unsupported browsers. See [0].
The new router takes decissions based on the Redux state at the time of
invocation. A route can be represented by either a component or a URl reference,
with the latter taking precedence. On mobile, obviously, there is no concept of
URL reference so routing is based solely on components.
[0]: https://github.com/jitsi/lib-jitsi-meet/pull/779
2018-06-29 07:58:31 +00:00
|
|
|
const { locationURL } = state['features/base/connection'];
|
|
|
|
|
|
|
|
// eslint-disable-next-line no-negated-condition
|
|
|
|
if (window.location.href !== locationURL.href) {
|
|
|
|
route.href = locationURL.href;
|
|
|
|
resolve(route);
|
|
|
|
} else {
|
|
|
|
// Maybe show deep-linking, otherwise go to Conference.
|
|
|
|
getDeepLinkingPage(state).then(component => {
|
|
|
|
route.component = component || Conference;
|
|
|
|
resolve(route);
|
|
|
|
});
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!isWelcomePageUserEnabled(state)) {
|
2018-07-12 03:57:44 +00:00
|
|
|
// Web: if the welcome page is disabled, go directly to a random
|
|
|
|
// room.
|
core: refactor routing
Unfortunately, as the Jitsi Meet development evolved the routing mechanism
became more complex and thre logic ended up spread across multiple parts of the
codebase, which made it hard to follow and extend.
This change aims to fix that by rewriting the routing logic and centralizing it
in (pretty much) a single place, with no implicit inter-dependencies.
In order to arrive there, however, some extra changes were needed, which were
not caught early enough and are thus part of this change:
- JitsiMeetJS initialization is now synchronous: there is nothing async about
it, and the only async requirement (Temasys support) was lifted. See [0].
- WebRTC support can be detected early: building on top of the above, WebRTC
support can now be detected immediately, so take advantage of this to simplify
how we handle unsupported browsers. See [0].
The new router takes decissions based on the Redux state at the time of
invocation. A route can be represented by either a component or a URl reference,
with the latter taking precedence. On mobile, obviously, there is no concept of
URL reference so routing is based solely on components.
[0]: https://github.com/jitsi/lib-jitsi-meet/pull/779
2018-06-29 07:58:31 +00:00
|
|
|
|
|
|
|
let href = window.location.href;
|
|
|
|
|
|
|
|
href.endsWith('/') || (href += '/');
|
|
|
|
route.href = href + generateRoomWithoutSeparator();
|
|
|
|
} else if (isWelcomePageAppEnabled(state)) {
|
|
|
|
// Mobile: only go to the welcome page if enabled.
|
|
|
|
|
|
|
|
route.component = WelcomePage;
|
|
|
|
}
|
|
|
|
|
|
|
|
resolve(route);
|
|
|
|
});
|
|
|
|
}
|