fix(search): Repeat city searching now working

[kuck1]

Pull Request type

Please check the type of change your PR introduces:

• Bugfix
• Feature
• Code style update (formatting, renaming)
• Refactoring (no functional changes, no API changes)
• Build-related changes
• Documentation content changes
• Other (please describe):

What is the current behavior?

If you search for city X and then city Y and then back to X there might be an issue where the search doesn't go through. This has really low user impact, but it came up in my last PR so I decided to look into it.

Issue Number: N/A

What is the new behavior?

• The new behavior is you can repeatedly search back and forth between duplicate cities and it will load.

Does this introduce a breaking change?

• Yes
• No

Other information

Before:

Screen.Recording.2024-02-29.at.6.17.09.AM.mov

After:

Screen.Recording.2024-02-29.at.6.18.23.AM.mov

Technical approach

After it became clear that this was repeated cities causing the issue I looked for why the trigger is not called to search again in that case. The search box is working great, but there seemed to be some caching happening with the geo lookup. It turns out that tan stack's useQuery function has the onSuccess callback that we use but it is only called when new data is fetched. Existing searches apparently are cached by default for 5 minutes and don't trigger a new query. As a result, repeat cities were not triggering onSuccess which is where we set up the parameters to do the final important search.

This is a confusing way tan stack designed this that was widely misunderstood according to stack overflow, so they are deprecating onSuccess in the next major version. I think there are some guides on how to migrate beyond this by using the caching system but that seems to be the scope of another bigger ticket. For now, if we turn the caching off, then onSuccess will be triggered every time and the search will happen as expected.

Official docs mentioning the deprecation

Stackoverflow post discussing the deprecations and work arounds

[alwaysmeticulous]

🤖 No test run has been triggered as your Meticulous project has been deactivated (since you haven't viewed any test results in a while). Click here to reactivate.

_{Last updated for commit ddabf07. This comment will update as new commits are pushed.}

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
inreach-app	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Mar 6, 2024 5:16pm

[github-actions]

📦 Next.js Bundle Analysis for @weareinreach/app

This analysis was generated by the Next.js Bundle Analysis action. 🤖

This PR introduced no changes to the JavaScript bundle! 🙌

[sonarcloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarCloud

[JoeKarow]

Good find! I made a slight change moving the onSuccess callback in to a useEffect. We will be upgrading to tRPC v11/TanStack Query v5 in the near future, which fully deprecates the onSuccess callback - so we should try and refactor those out when we come across them for now.

[kuck1]

Good find! I made a slight change moving the onSuccess callback in to a useEffect. We will be upgrading to tRPC v11/TanStack Query v5 in the near future, which fully deprecates the onSuccess callback - so we should try and refactor those out when we come across them for now.

Awesome, sounds great!

[kuck1]

Makes sense