Checking if the calendar support in the reducer is not only useless but wrong,
since we don't have access to the entire store (the calendar support is checked
in the base/config feature). If calendar support is not enabled the actions
being reduced won't be dispatched anyway, so no harm is done by removing the
check.
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.
* Removes unused ADD_PEOPLE_APP_NAME
* Moves deep-link header background and logo size as variables.
* Fixes more numbers page space in the header.
* Fixes left padding on deep-linking mobile page.
* Add joing button to the calendar events.
* Add space between calendar lines.
* Adjust recent list name.
* Fixes test failure.
* Restyle mobile recent list message.
* Add analytics events.
* Addressing PR review comments.
* Implements calendar entries edit.
Share text generation between calendar-sync and the share-room feature.
* Fixing comments.
* Clone the event element we modify on update.
* Refactor calendar-sync feature to be loaded on web.
For the web part it just adds new property to enable/disable calendar web integration, disabled by default.
* Initial implementation of retrieving google calendar events.
* Initial implementation of retrieving microsoft calendar events.
* Fixes comments.
* Rework to use the promise part of microsoft-graph-client api.
* Moves dispatching some actions, fixing comments.
* Makes sure we do not initializeClient google-api client multiple times.
* Do not try to login when fetching calendar entries.
The case where there is a calendar type google selected, but not logged in, trying to login on loading welcome page will show a warning that it tried to open a popup, which was denied by browser.
* Updates profile display data on sign in.
* Propagate google-api state to calendar-sync only if we use google cal.
* Adds sign out action.
* Clears the event listener when the popup closes.
* Clears calendarIntegrationInstance on signOut.
* WIP: UI for calendar settings, refactor auth flows
* Clean up some unused constants, functions and exports.
* break circular dependency of function and constant
* Exports only isCalendarEnabled from functions.
* Checks isSignedIn when doing fetchCalendarEntries on web.
* address comments
List microsoftApiApplicationClientID in undocument config.
remove unused SET_CALENDAR_TYPE action
use helper for calendar enabled in bootstrap
reorder actions
reorder imports
change order of signin -> set type -> update profile
add logging for signout error
reword setting dialog desc to avoid redundancy
add jsdoc to microsoft button props
reorder calendar constants
move default state to reducer (not reused anywhere)
update comment about calendar-sync due to removal of getCalendarState
update comment for getCalendarIntegration
remove vague comment
alpha order reducer, return default state on reset
alpha order persistence registry
remove unnecessary getType from apis
update comments in microsoftCalendar
alpha order google-api exports, use api.get in loadGoogleAPI
set jsdoc for google signin props
alpha order googleapi methods
fix calendartab docs
* Moves fetching calendar from APP_WILL_MOUNT to SET_CONFIG.
The web part needs configuration in order to refresh tokens (Microsoft).
* Fixes storing token expire time and refreshing tokens in Microsoft impl.
* Address comments
updateProfile changed to getCurrentEmail
rename result to results
stop storing integration in redux, store if ready for use
use existing helpers to parse redirect url
* update jsdocs, get google app id from redux
* clear integration instead of actual sign out
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.
This commit adds a state getter that considers checking the enabled/disabled state of the calendar feature, so then other features don’t have to do it manually.
Knowledge is power, man!
We moved "knownDomains" from calendar-sync to base/known-domains.
However, we do have an official release in the app stores and I'd like
us to not throw away the knowledge it has acquired.
netaskd
Saúl Ibarra Corretgé
Bettenbuk Zoltan
Saúl Ibarra Corretgé
virtuacoplenny
damencho
Hristo Terezov
Lyubo Marinov
Leonard Kim
yanas
paweldomas