hackforla / 311-data

Empowering Neighborhood Associations to improve the analysis of their initiatives using 311 data
https://hackforla.github.io/311-data/
GNU General Public License v3.0
62 stars 63 forks source link

Update request type strings to match database #428

Closed jmensch1 closed 4 years ago

jmensch1 commented 4 years ago

The request type strings we're displaying in the UI don't always match the requesttype field in the database. For example, we're using 'Dead Animal' in the UI, but the actual string in the database is 'Dead Animal Removal'. As a result, when you search for that request type, you don't get back any data.

These are all the cases where the strings are different:

UI string / DB string Dead Animal / Dead Animal Removal Single Streetlight / Single Streetlight Issue Multiple Streetlight / Multiple Streetlight Issue E-Waste / Electronic Waste Graffiti / Graffiti Removal Illegal Dumping / Illegal Dumping Pickup

The easy way to handle this would be just to change the strings we're displaying in the UI to match the DB strings.

But if we want to preserve the different strings in the UI, we could modify the REQUEST_TYPES constant so that it distinguishes between the UI string and the DB string.

export const REQUEST_TYPES = [
  {
     type: 'Dead Animal Removal',   // the DB string 
     display: 'Dead Animal',        // the UI string
     ...
  }
  ...
}

Then we could modify the components that use the request types (the RequestTypeSelector, Legend, and a bunch of the charts) to use the display string for presentation, and the type for requesting data from the backend.

P.S. the database also includes 'Report Water Waste'. Are we using that on the frontend?

sellnat77 commented 4 years ago

We could serve this blob from the backend too Or we could also do a one-off select distinct but if we pull it from the backend it will adapt to changes

Reason being....we only have access to 13 types of requests but it rumored that there are a ton of different types we just dont have access to yet

jmensch1 commented 4 years ago

Oh yeah, that could be good. Like a metadata endpoint we could hit when the app loads up. Could include the list of NCs as well, which are currently hard-coded into the frontend.