Lf 4671 migrate weather board saga to rtk query

[gursimran-singh]

Description

This PR migrates the functionality to RTK query by extending the main API and removes the dependency on saga and slice.

Jira link:https://lite-farm.atlassian.net/browse/LF-4671

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

Login with the account and on the home page correct weather is shown.

• Passes test case
• UI components visually reviewed on desktop view
• UI components visually reviewed on mobile view
• Other (please explain)

Checklist:

• I have commented my code, particularly in hard-to-understand areas
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• The precommit and linting ran successfully
• I have added or updated language tags for text that's part of the UI
• I have added "MISSING" for all new language tags to languages I don't speak
• I have added the GNU General Public License to all new files

[Duncan-Brain]

Thanks so much @gursimran-singh I think it looks great to me!

If you are interested in continuing on WeatherBoard we would love to obscure the api call a little more and move it to the backend https://lite-farm.atlassian.net/browse/LF-4281

[kathyavini]

This is so cool Gursimran!!

Thank you for delving into so much uncharted territory and getting us started with the separate files for new endpoints (actually I think we should have started doing this earlier 😅), migrating off of slice + saga (🎉!!) and using RTK Query to interface with an external API. It's great! ☺️

Everything functions well, and my only comments are about how to keep the weatherApi.ts a little bit more parallel to the existing RTK Query endpoints in terms of types and structure. I think a consistent structure will help us a lot with keeping things readable at a glance as you pick up more and more endpoints.

Awesome job -- so exciting to see the great migration underway 😁

[kathyavini]

I'm pretty sure we'd like to keep all the endpoint definitions within store/api/ instead of keeping them near their calling component. But I'll double-check with @antsgar when she returns!

[kathyavini]

I know it's only called only in a JS file, but since all our API endpoints will be written in TS, it would be great to keep type safety. In this case, the return type can be inferred, but the parameters cannot so at least those could be typed explicitly:

interface WeatherQueryArgs {
  lat: number;
  lon: number;
  measurement: string;
}

BUT to keep consistency with all our other RTK query endpoints and for the clearest documentation, it would actually be ideal if we could keep this format and type both return and params:

getWeather: build.query<WeatherData, WeatherQueryArgs>({

[kathyavini]

RTK Query manages its own fetching so it would be cleaner and more like the other endpoints to use query instead of queryFn and you wouldn't need axios or the error handling (try/catch) as that is all built-in (unless there is a particularly reason it's necessary to use axios for this endpoint)

query: ({ lat, lon, measurement }) => {
  const apikey = import.meta.env.VITE_WEATHER_API_KEY;
  const params = new URLSearchParams({
    lat: String(lat),
   // ...
  });

  return `https://api.openweathermap.org/data/2.5/weather?${params.toString()}`;
},

We haven't used it yet in app, but I think the best RTK Query pattern for the returned data would then be transformResponse:

transformResponse: (response: any /* optional to type their API response */) => {
 const weatherPayload = {
   humidity: `${response.main?.humidity}%`,
  // ...
 };

 return weatherPayload;