Converted LoadConfigOverlay to a JitsiScreen component that right now is part of navigation as ConnectingPage, plus I
separated appNative and other actions into web and native.
There is no need for AbstractApp to require some getWindowLocation function.
It's only used in one place and we even polyfill it on mobile.
Thus replace it's usage with more specific functions.
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
If multiple JitsiMeetView instances are created (not necessarily
existing at once), it's possible to hit a TypeError when reading the
React Component props of the currently mounted App. Anyway, in certain
places we're already protecting against that out of abundance of caution
so it makes no sense to not protect everywhere.
* feat(Deeplinking): Implement for web.
* ref(unsupported_browser): Move the mobile version to deeplinking feature
* feat(deeplinking_mobile): Redesign.
* fix(deeplinking): Use interface.NATIVE_APP_NAME.
* feat(dial_in_summary): Add the PIN to the number link.
* fix(deep_linking): Handle use case when there isn't deep linking image.
* fix(deep_linking): css
* fix(deep_linking): deeplink -> "deep linking"
* fix(deeplinking_css): Remove position: fixed
* docs(deeplinking): Add comment for the openWebApp action.
I see it as the first step in simplifying the route navigate of the
JavaScript app by removing BlankWelcomePage from _getRouteToRender. From
a faraway point of view, the app is at the route at which it is not in a
conference. Historically, the route was known as the Welcome page. But
mobile complicated the route by saying that actually it may not want to
see the room name input and join button.
Additionally, I renamed BlankWelcomePage to BlankPage because I don't
think of it as a WelcomePage alternative but rather as a more generic
BlankPage which may be utilized elsewhere in the future.
I plan for the next steps to:
* Merge Entryway, _interceptComponent, and _getRouteToRender in one
React Component rendered by AbstractApp so that the whole logic is in
one file;
* Get rid of RouteRegistry and routes.
The counterpart of the external API in the Jitsi Meet Web app uses the
search URL param jwt to heuristically detect that the Web app is very
likely embedded (as an iframe) and, consequently, needs to forcefully
enable itself. It was looking at whether there was a JSON Web Token
(JWT) but that logic got broken when the JWT support was rewritten
because the check started happening before the search URL param jwt was
parsed.
There were getDomain, setDomain, SET_DOMAIN, setRoomURL, SET_ROOM_URL
which together were repeating one and the same information and in the
case of the 'room URL' abstraction was not 100% accurate because it
would exist even when there was no room. Replace them all with a
'location URL' abstraction which exists with or without a room.
Then the 'room URL' abstraction was not used in (mobile) feature
share-room. Use the 'location URL' there now.
Finally, removes source code duplication in supporting the Web
application context root.
The functionality around logging including logging_config.js i.e.
loggingConfig and the other classes and/or functions that initialize
loggers for Jits Meet truly deserves a feature of its own. Start getting
in that direction on both Web and mobile by introducing
features/base/logging and bringing loggingConfig to mobile.
I don't like the file/function name, I'm not excited about the
complexity of the logic it implements, and it's definitely a reusable
piece worthy of being called a utility.
Calinteodor
Saúl Ibarra Corretgé
Lyubo Marinov
hristoterezov
virtuacoplenny
paweldomas
damencho
Ilya Daynatovich
Lyubomir Marinov