Issue

Results renders dates with the prior year instead of current year:

This relates to #31 (this bug prevented results from displaying due to wrong year).

Task

Either we wait until NASA fixes their data or we take some action to render the correct year in the meantime.

We need to explicitly define width and height values to resolve this unintended behavior.

We could either dynamically set width and height attributes based on user window size or set a fixed value (i.e.,width="150px" height="150px") to resolve this issue.

Task

Address the following security alerts:

• https://github.com/kylejb/space-station-tracker/security/dependabot/9
• https://github.com/kylejb/space-station-tracker/security/dependabot/10
• https://github.com/kylejb/space-station-tracker/security/dependabot/11
• https://github.com/kylejb/space-station-tracker/security/dependabot/12
• https://github.com/kylejb/space-station-tracker/security/dependabot/13
• https://github.com/kylejb/space-station-tracker/security/dependabot/14
• https://github.com/kylejb/space-station-tracker/security/dependabot/15
• https://github.com/kylejb/space-station-tracker/security/dependabot/16
• https://github.com/kylejb/space-station-tracker/security/dependabot/18
• https://github.com/kylejb/space-station-tracker/security/dependabot/19

Describe the bug
Unable to search.

To Reproduce
Steps to reproduce the behavior:

1. Search for any US-based zipcode

Actual behavior
Page goes black on search due to unhandled error.

Screenshots

Expected Behavior
We expect to see search results alongside the globe.

Proposal

I'd like to change the UI experience by limiting user selection to a single SightingCard on every onClick rather than allowing multiple selections. I think this will improve the UI experience while mitigating for edge cases while improving the user experience.

For example:

• users will no longer be required to close prior selections.
• increase search results.

Details

Is your feature request related to a problem? Please describe.

If many sighting cards are selected without closing prior selections, content may overflow.

Example:

• If we had more results here, it would no longer be apparent due to all the selections made:
  

Describe the solution you'd like

• End-user can only select a single SightingCard at a time.
• If a current card has been selected when another selection is made, the new selection will open the recently selected card and close the prior selection.
• End-user should also be able to close a card without having to making a new selection by clicking on the currently selected card to close.
  • this feature currently exists and am flagging to ensure this is preserved.

Describe the bug
When the ISS enters and exits from the same cardinal direction, the compass component does not render the appropriate visualizations. The screenshot below exemplifies the issue:

Expected behavior

This screenshot shows how the component works when it does render:

Desktop (please complete the following information):

• OS: macOS
• Browser: Firefox
• Version: 95.0.2

What

When I enter a zip code, I consistently do not see results for sighting opportunities.

Why

• NASA bug: their data for 2022 is broken; it's providing the correct month, day, and time, but the year is hardcoded to 2021.

How

• Add logic to manually handle this edge case in order to enable services.
• Fix/improve internal filtering logic to make handling such edge cases easier in the future.

What

• Extend the tracker functionality to provide users with local viewing opportunities.

How

• Process international postcodes to provide nearest sighting opportunity, if any are available.

Challenge

• 3rd party APIs have been inconsistent in handling zipcodes/postcodes; this is worth keeping an eye on and reassessing another approach (e.g., extend proxy-server to a full-fledged backend service for support).

---

Acceptance Criteria:

• Extend service for international users above all else.
• We should deal with refactoring and consolidating the logic that supports this functionality separately.

Follow-on to #67

---

Task

We need to remove the following hardcoded approach.

Note
For more context, see this comment.