Skip to content

Conversation

@binh-dam-ibigroup
Copy link
Collaborator

@binh-dam-ibigroup binh-dam-ibigroup commented Oct 1, 2020

This PR depends on #239 and requires changes from ibi-group/otp-middleware#77 ibi-group/otp-middleware#90.

It causes the trip settings UI to

  • check for trip availability for each day of the week,
  • provide a visual indication for days a trip is not available,
  • set the flag to false for days on which a trip is not available, so those updates are persisted upon saving. (If a trip becomes unavailable on a day after the user saves it -- e.g. service is dropped on weekends on a route -- if the user makes a change, those days would no longer be monitored).

image

@binh-dam-ibigroup binh-dam-ibigroup added the BLOCKED Blocked (waiting on another PR to be merged) label Oct 1, 2020
Comment on lines 60 to 68
async componentDidMount () {
// Check itinerary existence for all days.
const { accessToken, config, setFieldValue, values } = this.props

const itineraryCheckResult = await checkItinerary(
config.persistence.otp_middleware,
accessToken,
values
)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since this check occurs every time the component mounts, it might be possible that an itinerary becomes impossible for an existing itinerary that was possible before. Is there a way to have this run only when creating a monitored trip?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That was my initial thought and It is possible from the UI, but it will currently fail on the backend (the preUpdateHook method will trigger an error if the trip does not exist for one of the monitored days). Should the backend be changed to accommodate that?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should probably think about this a little more in depth. At some point this UI should also show when an itinerary is no longer possible which means updating things in the backend and then communicating that somehow to the frontend.

Copy link
Collaborator Author

@binh-dam-ibigroup binh-dam-ibigroup Oct 26, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I went ahead and remove the trip existence enforcement when saving existing trips in ibi-group/otp-middleware@78e31e7. With commit aeb519f, the UI will still perform the check and highlight the days an existing trip is not possible, however it will let the user save that trip. Trip existence continues to be enforced for new trips.

Base automatically changed from form-validation to dev October 9, 2020 17:47
Copy link
Contributor

@evansiroky evansiroky left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Until we figure out how to communicate that a Monitored Trip is no longer possible on a particular day of the week, we should have this itinerary existence check run only upon the creation of a new Monitored Trip.

@binh-dam-ibigroup
Copy link
Collaborator Author

Until we figure out how to communicate that a Monitored Trip is no longer possible on a particular day of the week, we should have this itinerary existence check run only upon the creation of a new Monitored Trip.

@evansiroky Did you mean also not enforcing that in the backend?

@binh-dam-ibigroup binh-dam-ibigroup removed the BLOCKED Blocked (waiting on another PR to be merged) label Oct 26, 2020
Copy link
Contributor

@evansiroky evansiroky left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems good

@evansiroky evansiroky removed their assignment Oct 26, 2020
const setLastPhoneSmsRequest = createAction('SET_LAST_PHONE_SMS_REQUEST')
export const setPathBeforeSignIn = createAction('SET_PATH_BEFORE_SIGNIN')
export const clearItineraryExistence = createAction('CLEAR_ITINERARY_AVAILABILITY')
const setitineraryExistence = createAction('SET_ITINERARY_AVAILABILITY')
Copy link
Member

@landonreed landonreed Nov 10, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nitpick: I think the action string should match the action name i.e., replace AVAILABILITY with EXISTENCE.

Also setitineraryExistence has a typo (the first i should be capitalized).

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated in 846892a.

export function checkItineraryExistence (trip) {
return async function (dispatch, getState) {
const { accessToken, apiBaseUrl, apiKey } = getMiddlewareVariables(getState())
const requestUrl = `${apiBaseUrl}${API_MONITORED_TRIP_PATH}${API_MONITORED_TRIP_CHECK_SUBPATH}`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think API_MONITORED_TRIP_CHECK_SUBPATH needs to be in a constant if it's only used one time. Having constants far away from the place they're used can make things hard to read.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure. Updated in 846892a

const mapStateToProps = (state, ownProps) => {
const { accessToken, itineraryExistence } = state.user
return {
accessToken,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is accessToken needed still?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good find. Updated in 846892a.

* @returns true if there is a trip matching for the specified availability/existence check.
*/
function itineraryExists (dayCheck) {
return dayCheck && dayCheck.valid
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure this method is needed any longer, is it? We should be guaranteed to have an entry for each day in the ItineraryExistence response, right?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No it is not. Updated in 846892a.

<FormGroup validationState={monitoredDaysValidationState}>
<ControlLabel>What days do you take this trip?</ControlLabel>
<div>
{allDays.map(({ name, fullText, text }, index) => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems a bit redundant to have allDays and ALL_DAYS, which effectively contain the same info.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated in 846892a.

Copy link
Member

@landonreed landonreed left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a few nitpicks. Otherwise, looks great!

@landonreed landonreed merged commit 96d89d1 into dev Nov 10, 2020
@landonreed landonreed deleted the check-itinerary-existence branch November 10, 2020 23:03
@evansiroky evansiroky mentioned this pull request Nov 20, 2020
@github-actions
Copy link
Contributor

github-actions bot commented Jan 8, 2021

🎉 This PR is included in version 2.0.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants