Switch bundles and URL away from location_id

[brian428]

As discussed, we'll switch to using an id bundle value and URL value, along with a source value (CWMS or WQ for now, but there could be others). It is worth noting that in the location summary data, there is an id property that is set to the location_code for CWMS locations and to the WQ ID for WQ locations. So we can probably just switch over to using that as the location ID that we track.

We may still want selectors for selectLocationCode and selectWqId, which inspects the current source and returns either the ID or null if the source isn't CWMS vs. WQ. That way components can select the location code or water quality ID without having to know about or check against the source value. So in other words, if a CWMS data component does selectLocationCode, but the currently selected id and source is for WQ, this would return null. So the CWMS data component wouldn't do anything (not render, etc.). And same in reverse for using selectWqId. That way the components don't have to worry about what the source is set to. Thoughts?

[brian428]

For reference, the new REST URLs to use in conjunction with this are:

// CWMS location data water/cwms/:id/detail water/cwms/:id/stream-locations water/cwms/:id/levels/current water/cwms/:id/children water/cwms/:id/nid

I updated the other tickets related to adding the WQ bundles with the new URLs for those.

I have a branch in the API repo with these changes. Let me know when this is ready and I can merge that PR into the API. I'll try to check email next week so we can do this around the same time.

[mohitb3]

Right now whenever you select a new location on the map, we call the following apis to get the location data /water/locations/details/:location_code /water/locations/stream-locations/:stream_location_code /water/locations/details/:location_code/levels/current /water/locations/details/:location_code/children

Just so I understand correctly, are you changing the api so that if the user selects a location with source cwms, we call the /water/cwms/ endpoints instead? Likewise if the user selects a location with source WQ, we would call /water/wq/ endpoints?

So basically will all of the endpoints for the different sources have the following structure: /water/:source/:id/details /water/:source/:id/stream-locations /water/:source/:id/levels/current /water/:source/:id/children /water/:source/:id/nid

[brian428]

No, unfortunately the CWMS and WQ data are totally different. So there is no WQ endpoint that would be equivalent to any of the CWMS endpoints, and vice-versa. So you can't just rely on replacing the source as a URL param. The two sets of REST endpoints (CWMS vs. WQ) are totally different because the underlying data is totally different. Hopefully that makes sense?

[brian428]

So to add, we will only call the CWMS rest endpoints if the location source is CWMS, and only call the WQ endpoints if the source is WQ.

[brian428]

If it makes sense to have separate inner components within the detail panel, one specific to CWMS and specific to WQ, that may be one way to handle this.

[mohitb3]

Gotcha, are we still updating the the /water/locations/ endpoints to /water/cwms/, or will the /water/cwms/ endpoints be new endpoints that are in conjecture with /water/locations/ if the location source is CWMS?

[brian428]

The endpoints that will remain under /water/locations will be for things that are independent of CWMS or WQ. /water/locations is the list of all locations (both CWMS and WQ). Basically, on the Go side the API will be broken down into 3 sets, like this:

// Source-independent location data
public.GET("water/locations", handlers.ListLocationSummaries(db))
public.GET("water/locations/basins", handlers.ListDistrictsAndBasins(db))
public.GET("water/locations/search", handlers.ListLocationSearch(db))
public.GET("water/locations/offices", handlers.ListOffices(db))
public.GET("water/locations/offices/:office_id", handlers.GetOffice(db))

// CWMS locations
public.GET("water/cwms/:locationCode/detail", handlers.GetLocationDetail(db))
public.GET("water/cwms/:locationCode/stream-locations", handlers.ListStreamLocations(db))
public.GET("water/cwms/:locationCode/levels/current", handlers.ListLocationLevelsCurrent(db))
public.GET("water/cwms/:locationCode/children", handlers.ListLocationChildren(db))
public.GET("water/cwms/:locationCode/nid", handlers.GetNidDetail(db))

//WQ locations
public.GET("water/wq/:id/samples/counts", handlers.ListWqSampleCounts(db))
public.GET("water/wq/:id/samples/results/:sample_date", handlers.ListWqSampleResults(db))

The endpoints that remain under "/locations" aren't specific to either CWMS or WQ. Make sense?

[brian428]

I should note that on the UI side, for the CWMS endpoints you'll still be passing the ID from the location summary, since for CWMS locations the ID is the same as the location code. I just named it locationCode on the server side so it is clear on the server side that the ID is actually the location code. Just mentioning that in case it wasn't clear.

[mohitb3]

Yep that makes sense. Thanks!