Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Status

ProposedAccepted

Author(s)

Antonella Sgalatta

Updated

2023-11-30

...

  • Better code quality and in turn less likelihood of catastrophic bugs resulting in white screens, which require refreshing the page to be fixed or even worse, wiping the cache (which a lot of users likely don’t do often), resulting in a highly frustrating user experience.

  • Better velocity to deliver new features to end users, since less time is spent implementing fetching for new data or fixing bugs related to data fetching.

  • Hopefully better load times for pages in the app, since it should now be much easier to track down what data is actually required by each page and make sure that we don’t fetch data we don’t actually need, as well as ensure that re-fetching is handled optimally so no recurrent calls are done that aren’t required.

Design Proposal

Alternatives

...

Considered

The Redux documentation includes a thorough comparison between RTK Query and other common alternatives used for data fetching, such as React Query, Apollo and urql (see https://redux-toolkit.js.org/rtk-query/comparison ).

...

In terms of comparing RTK Query with other approaches for side effects handling such as sagas and thunks, as covered in the previous sections, we have already experienced issues with those alternatives which are the main drive for wanting to migrate to RTK Query. The official Redux recommendations also support the migration and advice against using these other approaches for the specific use case of data fetching.

Performance

...

Implications

Using RTK Query will handle caching of the data for us and make sure we only re-fetch the data when the payload or query parameters change, avoiding unnecessary recurrent calls to the API. This should mean better performance for the UI by decreasing load times for pages, and less strain on the API side.

...

  • Currently all of the endpoints are specified in the apiSlice file. If we find that this file gets too bloated and hard to read, there’s there's a way to split the endpoints in different files https://redux-toolkit.js.org/rtk-query/usage/code-splitting.

  • There’s some logic used in the PR in selectFromResult functions that could be abstracted further to reuse it in other components.

Steps to

...

Migrate

My suggestion is that we migrate page by page. Picking any page in the app, the steps to follow would be roughly:

...