Background:
There are certain values/fields that makes sense to have them persist rather than pass them as props or emits. In this PR, I've implemented a sessions store that stores the date, time, location, type (for now, it's always 'realtime'. The type will allow for reusability when it comes to scheduling observations and accessing the same store), and an id as a new RTI session is created. I've also made the changes where it was obvious to access the store instead of passing props/emits.
Implementation:
I created a new folder called stores and inside it, is a file called sessions.js. This store could be deconstructed into smaller stores (e.g. coordinates.js) but I thought that perhaps that would be too small a store and for the time being, this seems like the right approach.
The store is pretty concise. I initialize sessions as an empty array, currentSessionId is null, and nextSessionId starts as 1.
currentSessionId is meant to be used primarily for rendering purposes in DashboardView and when the user selects that session, render the data that relates to that session. Perhaps better nomenclature needs to take over this variable. Will think of one.
The addSession action is pretty simple but becomes more evident of what it does in the TimePicker and LeafletMap components. I'll go into the details of how it pushes a session in a moment. This action also adds one nextSessionId and currentSessionId is assigned the previous value of nextSessionId. This is so that each session's id is unique and ascending in order.
In the components, the changes were minimal. In LeafletMap, instead of using emits to assign latitude and longitude, we now assign the values to the store as { site: location.site, lat: location.lat, lon: location.lng } and then these get modified/simplified in the TimePicker component.
In TimePicker, the function bookDate restructures the selectedSite value to be inside the location object as latitude and longitude and date, time, and type get pushed along location as a newSession to the sessionsStore. The location will become useful when syncing the SkyMap and Aladin and What's Up In The Sky. site (from the LeafletMap component) currently goes away because it doesn't serve a purpose now but it will when we want to render the upcoming bookings in the DashboardView.
DEVELOPER FEATURE: Added Sessions Store
Background: There are certain values/fields that makes sense to have them persist rather than pass them as props or emits. In this PR, I've implemented a sessions store that stores the date, time, location, type (for now, it's always
'realtime'. Thetypewill allow for reusability when it comes to scheduling observations and accessing the same store), and an id as a new RTI session is created. I've also made the changes where it was obvious to access the store instead of passing props/emits.Implementation: I created a new folder called
storesand inside it, is a file calledsessions.js. This store could be deconstructed into smaller stores (e.g.coordinates.js) but I thought that perhaps that would be too small a store and for the time being, this seems like the right approach. The store is pretty concise. I initializesessionsas an empty array,currentSessionIdisnull, andnextSessionIdstarts as1.currentSessionIdis meant to be used primarily for rendering purposes inDashboardViewand when the user selects that session, render the data that relates to that session. Perhaps better nomenclature needs to take over this variable. Will think of one. TheaddSessionaction is pretty simple but becomes more evident of what it does in theTimePickerandLeafletMapcomponents. I'll go into the details of how it pushes a session in a moment. This action also adds onenextSessionIdandcurrentSessionIdis assigned the previous value ofnextSessionId. This is so that each session's id is unique and ascending in order.In the components, the changes were minimal. In
LeafletMap, instead of using emits to assign latitude and longitude, we now assign the values to the store as{ site: location.site, lat: location.lat, lon: location.lng }and then these get modified/simplified in theTimePickercomponent. InTimePicker, the functionbookDaterestructures theselectedSitevalue to be inside thelocationobject aslatitudeandlongitudeanddate,time, andtypeget pushed alonglocationas anewSessionto thesessionsStore. Thelocationwill become useful when syncing theSkyMapandAladinand What's Up In The Sky.site(from theLeafletMapcomponent) currently goes away because it doesn't serve a purpose now but it will when we want to render the upcoming bookings in theDashboardView.VISUALS
Screenshot of the store