First, thank you for your patience. It has been a very tumultuous time and lots of bugs to debug. Second, here's my PR.
NOTE ON NUMBER OF FILES CHANGED:
6 files are tests; 4 new and 2 modified to reflect the changes of the sessionsStore and other small changes.
1 file is deleted
UpcomingBookings and MyGallery are updated to reflect changes of the store
Alright, now to the PR
STORE CHANGESsessions store
The state no longer has sessions. Now it has fulfilledRequests, upcomingRealTimeSessions, and requestedObservations.
fulfilledRequests: these are NORMAL observations that have the state of COMPLETED and REAL_TIME observations that have an end value that's in the past (16 minutes ago or more) since their state is always PENDING. These values are sorted in the action sortSessions which is a success callback of fetchSessions. This array is used to obtain the observation id and make a request to the archive to obtain the thumbnails and display them on MyGallery
upcomingRealTimeSessions: these are REAL_TIME observations that are in the future and are also sorted in sortSessions
requestedObservations: these are NORMAL observations with the state of PENDING. The difference between how this value is obtain vs the other two above is that the former hits the /requestgroups endpoint and the other two are obtained from the /observations endpoint. The reason for this is that, for one, when scheduling a NORMAL observation, the user makes a request to the /requestgroups endpoint because they may make more than one request per scheduling. And for all the other requests, hitting the /observations endpoint is necessary to obtain the observation_id to render the images related to the observation id.
fetchSessions: fetches sessions by making a request to the /observations endpoint. The success callback is sortSessions
sortSessions: this callback sorts sessions based on the following criteria: if the state is COMPLETE or the observation type is REAL_TIME and the end is 16 minutes ago or more, then the response gets stored in fulfilledRequests
fetchPendingObservations: this stores all the results in requestedObservations. It makes a request to the /requestgroups endpoint. This is used to display the Pending Observations (seen below)
SCHEDULING CHANGES
First, here's a video to better demonstrate both of the flows
In the beginner view, the user starts first by selecting a date range. This date range is used to make an api request to whats up in the sky to get a list of all available targets (in N and S hemispheres) as well as recommended exposures associated with each target. The targets are sorted based on the object it corresponds to (e.g. M100 would go under galaxy) and only the first 3 targets are sorted and displayed. I can change this, but for now, we're only showing 3. The user then selects the desired target and if I'm ok with defaults is selected, then the selected target along with the recommended exposure settings are what's requested to the /requestgroups endpoint.
Alternatively, the user can select Let me choose and the component SchedulingSettings renders. This component will not render the project name, target, ra, dec fields that you see in AdvancedScheduling because the props passed to the SchedulingSettings component.
Now in the advanced view, the SchedulingSettings renders entirely. The difference here is that fields are disabled and they become enabled as the user fills them out. For target, the ra and dec get auto populated by making a request to simbad2k. Then once a valid target is selected, the rest of the fields are enabled.
Both components (Advanced and Beginner) pass the selections through emits to the parent component, Scheduling View. It is here that the POST request to /requestgroups happens. If there is only one target, the value for operator is SINGLE. And if there is more than one target, the value is MANY. The requests get populated based on how many targets there are and each target is its own request (plus configuration)
In more detail:
createInstrumentConfigs: generates instrument configurations for each exposure (including exposure settings)
createRequest: constructs a request with target details, exposure settings, and time window
scheduleObservation: gathers request data, constructs the request list for single or multiple targets and sends a POST request to the /requestgroup endpoint
UPDATED FIXES:
Renamed consts, changed some hardcoded values, added more comments, added magic numbers, but the biggest change was splitting the sessions store (now called realTimeSessions). There are now two stores: realTimeSessions and obsPortalData. The former handles tokens for rt sessions, the current session's id, current session. The latter handles any completed observations (to display thumbnails), upcoming real time sessions, and pending request groups. The reason why upcoming real time sessions is handled here is because the action fetchCompleteObservationsAndUpcomingRTSessions sorts these two since it's the same api request.
FIX: SCHEDULE FLOW
First, thank you for your patience. It has been a very tumultuous time and lots of bugs to debug. Second, here's my PR.
NOTE ON NUMBER OF FILES CHANGED:
sessionsStoreand other small changes.UpcomingBookingsandMyGalleryare updated to reflect changes of the storeAlright, now to the PR
STORE CHANGES
sessions storestateno longer hassessions. Now it hasfulfilledRequests,upcomingRealTimeSessions, andrequestedObservations.fulfilledRequests: these areNORMALobservations that have the state ofCOMPLETEDandREAL_TIMEobservations that have an end value that's in the past (16 minutes ago or more) since their state is alwaysPENDING. These values are sorted in the actionsortSessionswhich is a success callback offetchSessions. This array is used to obtain the observation id and make a request to the archive to obtain the thumbnails and display them onMyGalleryupcomingRealTimeSessions: these areREAL_TIMEobservations that are in the future and are also sorted insortSessionsrequestedObservations: these areNORMALobservations with the state ofPENDING. The difference between how this value is obtain vs the other two above is that the former hits the/requestgroupsendpoint and the other two are obtained from the/observationsendpoint. The reason for this is that, for one, when scheduling aNORMALobservation, the user makes a request to the/requestgroupsendpoint because they may make more than one request per scheduling. And for all the other requests, hitting the/observationsendpoint is necessary to obtain theobservation_idto render the images related to the observation id.fetchSessions: fetches sessions by making a request to the/observationsendpoint. The success callback issortSessionssortSessions: this callback sorts sessions based on the following criteria: if the state isCOMPLETEor the observation type isREAL_TIMEand the end is 16 minutes ago or more, then the response gets stored infulfilledRequestsfetchPendingObservations: this stores all the results inrequestedObservations. It makes a request to the/requestgroupsendpoint. This is used to display thePending Observations(seen below)SCHEDULING CHANGES First, here's a video to better demonstrate both of the flows
Beginner scheduling view
https://github.com/user-attachments/assets/dae9a927-36c3-418a-97ae-efd05cdfab70
In the beginner view, the user starts first by selecting a date range. This date range is used to make an api request to whats up in the sky to get a list of all available targets (in N and S hemispheres) as well as recommended exposures associated with each target. The targets are sorted based on the object it corresponds to (e.g. M100 would go under galaxy) and only the first 3 targets are sorted and displayed. I can change this, but for now, we're only showing 3. The user then selects the desired target and if
I'm ok with defaultsis selected, then the selected target along with the recommended exposure settings are what's requested to the/requestgroupsendpoint. Alternatively, the user can selectLet me chooseand the componentSchedulingSettingsrenders. This component will not render the project name, target, ra, dec fields that you see inAdvancedSchedulingbecause the props passed to theSchedulingSettingscomponent.Advanced scheduling view
https://github.com/user-attachments/assets/c5359c49-28c9-46a6-b5d4-7c7e3c3dbb10
Now in the advanced view, the
SchedulingSettingsrenders entirely. The difference here is that fields are disabled and they become enabled as the user fills them out. For target, the ra and dec get auto populated by making a request to simbad2k. Then once a valid target is selected, the rest of the fields are enabled.Both components (Advanced and Beginner) pass the selections through emits to the parent component,
Scheduling View. It is here that the POST request to/requestgroupshappens. If there is only one target, the value foroperatorisSINGLE. And if there is more than one target, the value isMANY. The requests get populated based on how many targets there are and each target is its own request (plus configuration) In more detail:createInstrumentConfigs: generates instrument configurations for each exposure (including exposure settings)createRequest: constructs a request with target details, exposure settings, and time windowscheduleObservation: gathers request data, constructs the request list for single or multiple targets and sends a POST request to the/requestgroupendpointUPDATED FIXES:
Renamed consts, changed some hardcoded values, added more comments, added magic numbers, but the biggest change was splitting the
sessionsstore (now calledrealTimeSessions). There are now two stores:realTimeSessionsandobsPortalData. The former handles tokens for rt sessions, the current session's id, current session. The latter handles any completed observations (to display thumbnails), upcoming real time sessions, and pending request groups. The reason why upcoming real time sessions is handled here is because the actionfetchCompleteObservationsAndUpcomingRTSessionssorts these two since it's the same api request.