Change Details

issue: [[ https://linear.app/comm/issue/ENG-5822/change-login-logic-in-nav-reducer | ENG-5822 ]] `webLogInExtraInfoSelector` / `nativeLogInExtraInfoSelector` were used to obtain additional data for the login action. That included `calendarQuery`. `calendarQuery` was calculated using a function returned by `currentCalendarQuery`. This function had to be executed when the login call was being made, because it depended on the time of execution - it compared the current date to the last interaction with calendar, and if the difference was greater than some value, it would reset the date range. We no longer want to do that, because login in to one keyserver shouldn't change the range dates for other keyservers. Note 1: on web we were never expiering anyway, because the `calendarRangeInactivityLimit` was set to `null`. So on web we always returned `navInfo.startDate`, `navInfo.endDate`. Note 2: on native if the user is in the calendar, then `currentCalendarQuery` also doesn't expire and returns `navInfo.startDate`, `navInfo.endDate`. Note 3: on native if the user is not in the calendar, then as they navigate to it, `CalendarQueryHandler` takes care of updating the time range. `CalendarQueryHandler` will be updated to work for multiple keyservers in [[ https://linear.app/comm/issue/ENG-5779/update-calendarqueryhandler | ENG-5779 ]], but as long as we have only one socket the current version should work fine. `logInExtraInfoSelector` can thus return a value, not a function. `webLogInExtraInfoSelector` can be removed, because we don't need `calendarActive` value anymore, and we can just return what `logInExtraInfoSelector` returned. `nativeLogInExtraInfoSelector` still needs to return a function, because it `await`s underneath. See the discussion [[ https://linear.app/comm/issue/ENG-5765/refactor-login-logic-in-reducers-pt1#comment-e224aef1 | here ]] for more details

issue: [[ https://linear.app/comm/issue/ENG-5822/change-login-logic-in-nav-reducer | ENG-5822 ]] `webLogInExtraInfoSelector` / `nativeLogInExtraInfoSelector` were used to obtain additional data for the login action. That included `calendarQuery`. `calendarQuery` was calculated using a function returned by `currentCalendarQuery`. This function had to be executed when the login call was being made, because it depended on the time of execution - it compared the current date to the last interaction with calendar, and if the difference was greater than some value, it would reset the date range. We no longer want to do that, because login in to one keyserver shouldn't change the range dates for other keyservers. Note 1: on web we were never expiering anyway, because the `calendarRangeInactivityLimit` was set to `null`. So on web we always returned `navInfo.startDate`, `navInfo.endDate`. Note 2: on native if the user is in the calendar, then `currentCalendarQuery` also doesn't expire and returns `navInfo.startDate`, `navInfo.endDate`. Note 3: on native if the user is not in the calendar, then as they navigate to it, `CalendarQueryHandler` takes care of updating the time range. `CalendarQueryHandler` will be updated to work for multiple keyservers in [[ https://linear.app/comm/issue/ENG-5779/update-calendarqueryhandler | ENG-5779 ]], but as long as we have only one socket the current version should work fine. `logInExtraInfoSelector` can thus return a value, not a function. `webLogInExtraInfoSelector` can be removed, because we don't need `calendarActive` value anymore, and we can just return what `logInExtraInfoSelector` returned. `nativeLogInExtraInfoSelector` still needs to return a function, because it `await`s underneath. See the discussion [[ https://linear.app/comm/issue/ENG-5765/refactor-login-logic-in-reducers-pt1#comment-e224aef1 | here ]] for more details I would also like to note that this change means that I will not be updating `reduceCalendarQuery` or `reduceBaseNavInfo` for login actions, because calendar query passed into keyserver login will be the same as the one in state. And identity login has noting to do with the calendar query. And `reduceBaseNavInfo` takes the `calendarQuery` from action and uses its start and end dates.

issue: [[ https://linear.app/comm/issue/ENG-5822/change-login-logic-in-nav-reducer | ENG-5822 ]] `webLogInExtraInfoSelector` / `nativeLogInExtraInfoSelector` were used to obtain additional data for the login action. That included `calendarQuery`. `calendarQuery` was calculated using a function returned by `currentCalendarQuery`. This function had to be executed when the login call was being made, because it depended on the time of execution - it compared the current date to the last interaction with calendar, and if the difference was greater than some value, it would reset the date range. We no longer want to do that, because login in to one keyserver shouldn't change the range dates for other keyservers. Note 1: on web we were never expiering anyway, because the `calendarRangeInactivityLimit` was set to `null`. So on web we always returned `navInfo.startDate`, `navInfo.endDate`. Note 2: on native if the user is in the calendar, then `currentCalendarQuery` also doesn't expire and returns `navInfo.startDate`, `navInfo.endDate`. Note 3: on native if the user is not in the calendar, then as they navigate to it, `CalendarQueryHandler` takes care of updating the time range. `CalendarQueryHandler` will be updated to work for multiple keyservers in [[ https://linear.app/comm/issue/ENG-5779/update-calendarqueryhandler | ENG-5779 ]], but as long as we have only one socket the current version should work fine. `logInExtraInfoSelector` can thus return a value, not a function. `webLogInExtraInfoSelector` can be removed, because we don't need `calendarActive` value anymore, and we can just return what `logInExtraInfoSelector` returned. `nativeLogInExtraInfoSelector` still needs to return a function, because it `await`s underneath. See the discussion [[ https://linear.app/comm/issue/ENG-5765/refactor-login-logic-in-reducers-pt1#comment-e224aef1 | here ]] for more details I would also like to note that this change means that I will not be updating `reduceCalendarQuery` or `reduceBaseNavInfo` for login actions, because calendar query passed into keyserver login will be the same as the one in state. And identity login has noting to do with the calendar query. And `reduceBaseNavInfo` takes the `calendarQuery` from action and uses its start and end dates.