Closed kara-krzystan closed 3 years ago
The current workaround gives us the MVP, but I'm wondering if it counts as an alert, which we're not supposed to use? Can the prompt be forced into a modal somehow, I wonder?
Also if the user blocks geolocation, the app doesn't work at all and the error isn't showing. :( I wonder if we could add latitude and longitude forms that could populate automatically when the geolocation is allowed OR stays empty and accepts input if the user chooses to not allow geolocation????
Additionally, to address the "Violation," I tried to put the geolocation code within both the getAstronomyData and the submitForm functions in various ways, but nothing worked (most likely coder error). If we decide to forego the lat/long form fields, perhaps we could get the geolocation data collection to happen upon the submit click to make that violation go away.
I added a button to request geolocation! @kara-krzystan do you want to see if you can add your geolocation code to a click listener?
Added Geolocation access to button listener. Also added a check mark when geolocation succeeds.
Closing this now, as basic functionality is there. Great work! We may still consider adding input forms for lat/lon if user denies geolocation, this is addressed in Kristin's issue #53.
AstronomyAPI requires a user's longitude/latitude. We are currently requesting only a user's city. Solutions: We can use a 3rd API to translate city ---> long/lat or We can also use the browser geolocation
Browser geolocation best practice is to "Request access based on user gesture" (the user opts in by pushing a "use my location button"). The current geolocation prompt that appears on load will be replaced by this functionality. Info: https://developers.google.com/web/fundamentals/native-hardware/user-location#always_request_access_to_location_on_a_user_gesture
See the sample image they provide to see how this should look