Improve Dialog component to auto close on cancel or on submit
Change logic to determine whether a dialog is using the new component
Convert some files to TS
- add possibility to allow execution of the button's routine besides triggering
`toolbarButtonClicked` API event
- keep backwards compatibility
- get rid of `ToolbarButton`
* Created desktop reactions menu
Moved raise hand functionality to reactions menu
* Added reactions to chat
* Added animations
* Added reactions to the web mobile version
Redesigned the overflow menu. Added the reactions menu and reactions animations
* Make toolbar visible on animation start
* Bug fix
* Cleanup
* Fixed overflow menu desktop
* Revert mobile menu changes
* Removed unused CSS
* Fixed iOS safari issue
* Fixed overflow issue on mobile
* Added keyboard shortcuts for reactions
* Disabled double tap zoom on reaction buttons
* Refactored actions
* Updated option symbol for keyboard shortcuts
* Actions refactor
* Refactor
* Fixed linting errors
* Updated BottomSheet
* Added reactions on native
* Code cleanup
* Code review refactor
* Color fix
* Hide reactions on one participant
* Removed console log
* Lang fix
* Update schortcuts
* feat(toolbox) allow any toolbox button to be displayed as main
fixes the previous behaviour where only a certain set of buttons were whitelisted for being displayed in the main toolbar
* code review
* code review - fix avatar icon position
Up until now we relied on implicit loading of middlewares and reducers, through
having imports in each feature's index.js.
This leads to many complex import cycles which result in (sometimes) hard to fix
bugs in addition to (often) breaking mobile because a web-only feature gets
imported on mobile too, thanks to the implicit loading.
This PR changes that to make the process explicit. Both middlewares and reducers
are imported in a single place, the app entrypoint. They have been divided into
3 categories: any, web and native, which represent each of the platforms
respectively.
Ideally no feature should have an index.js exporting actions, action types and
components, but that's a larger ordeal, so this is just the first step in
getting there. In order to both set example and avoid large cycles the app
feature has been refactored to not have an idex.js itself.
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.
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.
* feat(keyboard-shortcuts): show help in a react dialog
- Move shortcut help dom declaration to a react component
- Let open/close logic be handled by AtlasKit Dialog
- Remove static html for help from index.html
- Consolidate keyboard shortcut css
* squash: use lozenge for key styling
* squash: use different iteration style
* squash: update package-lock for lozenge
Robert Pintilii
Calinteodor
Shahab
Horatiu Muresan
Saúl Ibarra Corretgé
Avram Tudor
Steffen Kolmer
Saúl Ibarra Corretgé
Bettenbuk Zoltan
Leonard Kim
Leonard Kim