Fix/fine-tune react-query settings

[kwajiehao]

This PR was reviewed with the staging branch of the backend.

Since changes are being made to the PageSettingsModal in PR #388, this PR should be rebased onto staging after #388 is merged into staging before being reviewed.

Overview

This PR makes 2 major updates to how we use the react-query library in our codebase:

1. Turning off automatic refetching behavior for disable useQuery if changes have been made to local state
2. Performing query cache invalidation of the corresponding useQuery after a mutation

1. Turning off automatic refetching for Disable useQuery if changes to local state are made

Some of the components which we use useQuery in require us to maintain content state to track changes to the content that users have made (for example, in PageSettingsModal, we need to maintain local state to track changes to the page title that the users make).

However, currently, any changes made by the user are reset if the user navigates to another tab/window, and then returns to the CMS. This is reproducible through the following steps:

1. Go to the EditPage layout
2. Type some new content in the editor
3. Navigate to a different tab on your browser
4. Return to the CMS tab. The content that you typed would have disappeared

This is because react-query refetched the page content and overwrote the changes to local state. Therefore, it's important to turn off refetching so we don't lose changes to local state made by the user.

We discussed this problem in depth, and the discussion minutes can be found in the CMS working document here (link). The conclusion was to keep a state variable, hasChanges, for detecting whether there are any changes to the local state from the initial mounted state. If there are changes, then hasChanges should be set to true, and we disable useQuery.

This solution is preferable because in most situations where we maintain local state and track local changes, we already check for changes in state to determine whether we should show a warning modal for users who attempt to navigate away with unsaved changes.

2. Performing query cache invalidation for corresponding useQuery after a mutation

Since the CMS needs to display the latest information to users, we need to ensure that our useQuery functions are not fetching outdated, cached data. Therefore, when we perform any mutations, we should invalidate the cache for the corresponding GET query so that we fetch fresh data the next time.

The alternative to this would be to set cacheTime to be 0 for all useQuery functions. Manual cache invalidation is more fine-grained and allows us to benefit from some degree of caching. Personally I'm open to either approach.

Misc. bugs fixed in this PR

• This PR fixes a bug in parsing the directory file. Now that all base64 encoding and decoding occurs on the backend, there is no longer a need to base64 decode the directory file output before parsing it.
• This PR standardizes the output of our GET API functions to return resp.data instead of just the response from the api call. resp.data is a better choice as we are able to use it in useEffect dependency arrays, whereas the resp object always changes, which will trigger the useEffect every time even if the object data hasn't actually changed.

[gweiying]

Some thoughts:

1. Disabling automatic refetching -

If our primary concern is that the changes are overwritten when a user navigates away from the page, how about instead setting a hasChanges flag, and doing passing { enabled: !hasChanges } to the query, rather than completely disabling refetching? Since one of the largest benefits of using the React Query library is that it automatically handles fetching, caching and updating data, turning off refetching seems to basically invalidate most of the benefits of the React Query library and not much different from a simple once-off API call on upon page load.

2. Performing query cache invalidation for corresponding useQuery after a mutation -

Makes sense. Should we create a separate file to import the queryClient object so that we don't have to instantiate a new object on every class?

[kwajiehao]

Some thoughts:

1. Disabling automatic refetching -

If our primary concern is that the changes are overwritten when a user navigates away from the page, how about instead setting a hasChanges flag, and doing passing { enabled: !hasChanges } to the query, rather than completely disabling refetching? Since one of the largest benefits of using the React Query library is that it automatically handles fetching, caching and updating data, turning off refetching seems to basically invalidate most of the benefits of the React Query library and not much different from a simple once-off API call on upon page load.

Is there any situation where we do want to have refetching for EditPages for example? The proposed changes affect only refetching so caching and other functionality are still maintained. For components where it makes sense, such as the Folders layout, we have allowed the default refetching settings.

Alternatively, we can set enabled to be false, and fetch the data manually using refetch

Updated description with conclusions from our meeting

2. Performing query cache invalidation for corresponding useQuery after a mutation -

Makes sense. Should we create a separate file to import the queryClient object so that we don't have to instantiate a new object on every class?

Sure, we can put it in a context and call the context - how does that sound?

[kwajiehao]

1. Performing query cache invalidation for corresponding useQuery after a mutation -

Makes sense. Should we create a separate file to import the queryClient object so that we don't have to instantiate a new object on every class?

@gweiying upon further research, useQueryClient returns the current queryClient instance so we're not actually creating a new object (useQueryClient documentation)

[alexanderleegs]

lgtm!

Outdated

[gweiying]

to remove

[alexanderleegs]

6ad1ba3

[gweiying]

to add successToast

[alexanderleegs]

ba2f930

[gweiying]

lgtm! thanks for making all the adjustments