LF-5103: Frontload data that is currently loaded on demand

[SayakaOno]

Description

• Call useGoogleMapsLoader in App.jsx to ensure maps can render offline without requiring an initial online visit to the map page
• Add null check for e.response in finances saga (I believe this was the cause of infinite loading on the transactions page)
• Update fieldWorkFailure and fieldWorkLoading reducers to avoid resetting fieldWorkTypes to [], which was preventing field work types from being available offline
• Pre-fetch required data in fetchAllSaga for offline task creation and read-only views:
  • Field work tasks
  • Irrigation tasks
  • Soil amendment tasks
  • Animal movement tasks
  • Finance transactions (read-only)
  • Animals (read-only etc.)
• Configure RTK Query caching at the API level:
  • keepUnusedDataFor: 7 days
  • refetchOnMountOrArgChange: 60 seconds

RTK Query Cache Configuration

Why change the defaults?

With RTK Query's default settings, cached data expires 60 seconds after the component using it unmounts. For example, if you visit the animals page, go offline, navigate away, and return after 60 seconds, the cached data will be gone and you won't see any data while offline. To support offline functionality, we need to adjust the cache configuration.

New Configuration

keepUnusedDataFor: 7 days (docs)

• Retains cached data for 7 days (matching our token lifetime)
• Previously: Cache expired 60 seconds after leaving the component

refetchOnMountOrArgChange: 60 seconds (docs)

• Automatically refetches if the last request was more than 60 seconds ago
• Previously: Only refetched when cache was empty

Impact

Example scenario: You visit the animals page, stay for an hour, navigate away, then immediately return.

• Old behaviour: No refetch (you returned within 60 seconds of leaving, so cache is still valid)
• New behaviour: Refetch happens (the last API call was over 60 seconds ago - an hour - so data is considered stale)

This configuration is applied globally at the API level rather than per-endpoint. This approach:

1. Eliminates the need to configure caching for each individual endpoint required for offline functionality
2. Ensures consistent behaviour for future APIs without additional configuration

Note:
With refetchOnReconnect: true (docs) , queries should automatically refetch when going back online, but I wasn't able to test this successfully. Claude says there are known bugs with this feature in our @reduxjs/toolkit version, which might be the cause. (The newer version have breaking changes. I created a ticket for the upgrade)
The app should work fine without this feature due to the cache configuration, but I'm documenting this for future reference in case we need automatic refetching on reconnection.

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

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?

• 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 ordered translation keys alphabetically (optional: run pnpm i18n to help with this)
• I have added the GNU General Public License to all new files

[kathyavini]

Oh WOW, it's such a delight to see such effective changes in 32 lines!! 😋😍

I love the new cache settings; much better default without the data getting any more stale 👌

Add null check for e.response in finances saga (I believe this was the cause of infinite loading on the transactions page)

❤️

[kathyavini]

Am I missing something, or shouldn't this whole slice be named for types, like fieldWorkTypesSlice, fieldWorkTypesFailure? 😅