Using anything non-serializable for action types is discouraged:
https://redux.js.org/faq/actions#actions
In fact, this is the Flow definition for dispatching actions:
declare export type DispatchAPI<A> = (action: A) => A;
declare export type Dispatch<A: { type: $Subtype<string> }> = DispatchAPI<A>;
Note how the `type` field is defined as a subtype of string, which Symbol isn’t.
To kill componentWillMount, call destroyLocalTrack after mount.
Navigation to the blank page was synthetically forced and no
UI issues were noticed, possibly because destroyLocalTrack may
already be async so destruction may already have been occurring
after mount.
For the most part the changes are taking the "static propTypes" declaration off
of components and declaring them as Flow types. Sometimes to support flow some
method signatures had to be added. There are some exceptions in which more had
to be done to tame the beast:
- AbstractVideoTrack: put in additional truthy checks for videoTrack.
- Video: add truthy checks for the _videoElement ref.
- shouldRenderVideoTrack function: Some component could pass null for the
videoTrack argument and Flow wanted that called out explicitly.
- DisplayName: Add a truthy check for the input ref before acting on it.
- NumbersList: Move array checks inline for Flow to comprehend array methods
could be called. Add type checks in the Object.entries loop as the value is
assumed to be a mixed type by Flow.
- AbstractToolbarButton: add additional truthy check for passed in type.
There are (at least) two changes that are breaking:
- defaultTab is gone
- The re-rendering logic looks to have been re-written so that
passing in a new array of tabs causes a re-render, which can
reset the currently selected tab.
The fixes involved removing defaultTab from each tab configuration,
as it is no longer respected anyway. Also, instead of letting Tabs
be uncontrolled and allowing it to set its own selected, which
would result in the first tab automatically being selected on
Tabs re-render, use Tabs a controlled prop to dicate which
tab is selected; this is accomplished by specifying a selected
prop.
* feat(welcome-page): be able to open settings dialog
- Create a getter for getting a settings tab's props so the device
selection tab can get updated available devices.
- Be able to call a function from a tab after it has mounted. This is
used for device selection to essentially call enumerateDevices on
the welcome page so the device selectors are populated.
- Remove event UIEvents.AUDIO_OUTPUT_DEVICE_CHANGED. Instead directly call
setAudioOutputDeviceId where possible.
- Fix initialization of the audioOutputDeviceId in settings by defaulting
the audio output device to the one set in settings.
* squash: updateAvailableDevices -> getAvailableDevices, add comment for propsUpdateFunction
* fix(welcome-page): css tweaks in prep for branded welcome page
- Watermarks should no longer depend on toolbar size. The left watermark made
room for the toolbar when the toolbar was on the left side of the screen, but
the toolbar has been moved to the bottom. The right watermark...well it'll
clash with the vertical filmstrip but at least the margins will be consistent
with the left watermark.
- Apply new font-family so fonts are more likely to be consistent across the
app. Design likes SF UI and keeps requesting it so use it by default.
- Change sizings of welcome page header to be more responsive. This will help
the header be scrollable when there is no additional content and the header
overflows.
- Change colors of the welcome page header and remove background image that
was in the header. Leave in the dom for the background image in case other
deployments need to continue showing an image.
- Add a period to the title of the welcome page.
- Move watermarks dom location as it is not part of the header; it's part of the
whole page.
* [squash] Size and font adjustments. Renaming.
It will only be requested if a user joins a meeting or flips the switch from
video to audio and back, but never as the first thing when the welcome page is
mounted.
BaseApp does all the heavy-lifting related to creating the redux store,
navigation, and so on.
App currently handles URL props and actually triggering navigation based on
them.
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
As part of the work on fixing the problem with the multiplying
thumbnails, we've associated remote participant w/ JitsiConference.
However, there are periods of time when multiple JitsiConferences are in
the redux state (and that period is going to be shorted by
StateListenerRegistry). In order to give more control to the feature
base/participants, reduce the occurrences of direct access to the
features/base/participants redux state and utilize the feature's
existing read access functions. Which will allow us in the future to
enhance these functions to access participants which are relevant to the
current conference of interest to the user only.
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.
In order to be able to add analytics to the deep-linking pages the
lib-jitsi-meet initialization has been moved so it happens earlier.
The introduced `initPromise` will eventually disappear, once conference is
migrated into React and / or support for Temasys is dropped. At that stage, it
can be turned into a sync function which all platforms share.
* 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.
Saúl Ibarra Corretgé
virtuacoplenny
Bettenbuk Zoltan
Leonard Kim
Hristo Terezov
Saúl Ibarra Corretgé
Leonard Kim
yanas
Ritwik Heda
Lyubo Marinov
Guus der Kinderen