Let user pick DPS location

[phamleduy04]

          I would love to see this implemented as well. Could it also be implemented for distance as well? There is a specific DPS I would like to go to but its not the closest to me. It would be nice to set an optional min distance as a part of the filter too!

Originally posted by @sudo-chan in #21 (comment)

[phamleduy04]

I don't think this will work based on miles because estimating miles is a good idea. I'm thinking about an interaction picker after fetching the list of DPS locations and u can choose when running the software.

Here is a sneak peek 👀

[phamleduy04]

I need some recommendations before implementing this

Users can pick one or multiple locations in this situation, and there will be an option on config.yml to let people decide if they want to pick a DPS Location or let the app pick itself 👍.

Or, we remove the miles and let users pick themself. After that save it to a file for the next time. If the user wants to "reset" it just deletes the temporary file.

[Syzygianinfern0]

Sounds great! How about this.

• A required config value (dtype int) to choose either (1) based on miles or (2) based on user selection during first deployment. During first deployment, it is saved to a local file. But one concern I have here if the storage on replit is persistent (I actually dont know). So here comes the next bullet.
• An optional config value (dtype List[str]) which lets users to set (2) from above config value to whatever place they want if they know the exact name. Else if they had chosen the location interactively as shown in your sneak peek, the script updates this value in config.yml directly (does this solve the persistent storage issue? I still don't know).

PS: @sudo-chan is my alt account lmao.

I would have put in a PR already in the same time required to write this comment but unfortunately I am entirely unfamiliar with TS/JS 🙈

[phamleduy04]

Thanks for your comment!

To my knowledge, files on replit won't get deleted like heroku. And imo is best when saving that data separately from the main config because it is considered temporary data and their choice might differ when running the software.

I don't think the second bullet is a good idea since the exact name returns from the API might differ from the user's input. Also, I would have to map the location to locationID to filter it out too :D

[Syzygianinfern0]

Nice! If replit can store temp data yes I agree just having the first bullet alone is good enough 👍

Looking forward to it!!

[phamleduy04]

Also, I will need to define "default" behavior when running the application. Which one is better?

• Old mile system, enter an int of miles and then auto-pick all DPS locations based on that
• New system, prompt asking DPS location and letting the user choose it.

And the config structure too:

location:
  # Zipcode of your location (for finding DPS location)
  zipCode: '75067'
  # Choose your DPS location 
  pickDPSLocation: false
  # Filter DPS location by distance from the zip code
  miles: 15
  ...

[Syzygianinfern0]

I suppose defaulting to "miles" based is better as most people would just want to go to their closest one anyways. And highlighting the fact that this feature of custom selection exists in the documentation should be important.

[phamleduy04]

sneak peek 2.0 :). But idk should I include the address on the prompt? Users using replit usually have vertical terminals instead of the horizontal one.

[phamleduy04]

please check on master branch. I didn't implement the "temporary" file yet.