Convert MFEs from Redux to React Query

[tonybusa]

After building out the work in this ticket Unit testing and general improvements #409, we recognized that there is an expectation for Open edX to use react query.

While there are still some PRs in flight that are useful, we're acknowledging that the work to replace Redux's connect HOC (Higher-Order Component) with React Redux Hooks useSelector() and useDispatch() involves converting a lot of class components to functional components, which adds complexity just for refactoring Redux, when the end goal is to use React Query.

Furthermore, this will remove the need to update tests multiple times when converting from connect to Redux Hooks, as mentioned in the last paragraph of this ticket.

So this parent ticket is to track the conversion of frontend-app-* from Redux (in any capacity) to React Query, and breaking down that work into sub-issues as much as possible, per repository.

[tonybusa]

I used Claude AI to help create a guide for updating MFEs to React Query. If this is accepted, I would break down the Summary Checklist into sub-issues per repo.

The original AI query asked to analyze a specific MFE but I stripped the specific pieces out of this comment and aimed to provide general tasks that should apply to all MFEs. Below is the revised output:

Migration Guide: Redux to React Query 5 and React Context

Executive Summary

This guide outlines the incremental migration strategy for converting frontend-app-* from Redux (with Redux Toolkit) to React Query 5 for server state management and React Context for client state management.

Key Benefits of Migration:

• Reduced boilerplate code (typically 60-70% less code for data fetching)
• Built-in caching, background refetching, and stale-while-revalidate patterns
• Automatic request deduplication
• Better separation of server state vs. client state
• Improved developer experience with React Query DevTools

---

Current State Analysis

What Gets Migrated

MIGRATE to React Query:

• API data fetching (GET requests)
• Data mutations (POST, PUT, DELETE)
• Cache management for server data
• Loading/error states for API calls
• Background data synchronization

Move to Context/local state:

• UI state (modals, sidebars, form visibility)
• User authentication/session data
• Global application settings
• Complex client-side state that doesn't come from the server

Identifying Redux Slices to Migrate

Look for slices that follow this pattern:

// These patterns indicate server state that should move to React Query:
const slice = createSlice({
  name: 'someFeature',
  initialState: {
    data: null,
    isLoading: false,
    error: null,
  },
  reducers: {},
  extraReducers: (builder) => {
    builder
      .addCase(fetchData.pending, ...)
      .addCase(fetchData.fulfilled, ...)
      .addCase(fetchData.rejected, ...)
  }
});

---

Migration Strategy Overview

Guiding Principles:

1. Migrate one slice/feature at a time
2. Start with the simplest, most isolated features
3. Keep PRs small and focused (one duck/slice per PR)
4. Ensure both systems can coexist during migration
5. Write tests alongside migrations

---

Summary Checklist

OPTIONAL: v4 → v5 Upgrade

NOTE: Not all MFEs will need to upgrade from v4 -> v5, so those sub-issues should reflect that work (skip this step)

• Update @tanstack/react-query to v5
• Run codemod for object syntax
• Update isLoading → isPending
• Update cacheTime → gcTime
• Remove onSuccess/onError from queries
• Update keepPreviousData → placeholderData
• Update useErrorBoundary → throwOnError
• Add initialPageParam to infinite queries
• Update Hydrate → HydrationBoundary
• Run tests and fix issues

Redux → React Query

• Install @tanstack/react-query if not there
• Set up QueryClient with defaults
• Create inventory of slices to migrate
• For each slice (redux-toolkit):
  • Extract API functions
  • Create query keys factory
  • Create custom hooks
  • Update components
  • Comment out Redux code
  • Write/update tests
  • Validation
    • All tests pass
    • Manual QA complete
    • Performance verified
• Clean Up
  • Remove deprecated Redux code
  • Update documentation

[brian-smith-tcril]

KEEP in Redux (or move to Context/local state):

• UI state (modals, sidebars, form visibility)
• User authentication/session data
• Global application settings
• Complex client-side state that doesn't come from the server

I'd like to push back on the "KEEP in Redux" part of this, and instead recommend we only present the "move to Context" option)

[tonybusa]

KEEP in Redux (or move to Context/local state):

• UI state (modals, sidebars, form visibility)
• User authentication/session data
• Global application settings
• Complex client-side state that doesn't come from the server

I'd like to push back on the "KEEP in Redux" part of this, and instead recommend we only present the "move to Context" option)

Updated. I'm curious about where to create the context files - do we want to encapsulate them as much as possible? Or should we create a parent context folder and name the per component?

Looking at an example that was merged: openedx/frontend-app-authoring#2398 it looks like we want to keep it tightly coupled within the component folder.

[tonybusa]

Repository Name	Repository Link	Redux Installed	Redux Extensions	React Query Installed	React Query Version
Authn	https://github.com/openedx/frontend-app-authn	TRUE	"redux-saga": "1.4.2"	FALSE
Authoring	https://github.com/openedx/frontend-app-authoring	TRUE	"@reduxjs/toolkit": "1.9.7"	TRUE	"@tanstack/react-query": "5.90.10"
Account	https://github.com/openedx/frontend-app-account	TRUE	"redux-saga": "1.4.2"	FALSE
Admin-portal	https://github.com/openedx/frontend-app-admin-portal	TRUE		TRUE	"@tanstack/react-query": "4.36.1"
Ora-grading	https://github.com/openedx/frontend-app-ora-grading	TRUE	"redux-beacon": "^2.1.0"	FALSE
Communications	https://github.com/openedx/frontend-app-communications	TRUE		FALSE
Enterprise-public-catalog	https://github.com/openedx/frontend-app-enterprise-public-catalog	TRUE		FALSE
Learner-record	https://github.com/openedx/frontend-app-learner-record	TRUE		FALSE
Profile	https://github.com/openedx/frontend-app-profile	TRUE	"redux-saga": "1.4.2"	FALSE
Special-exams	https://github.com/openedx/frontend-lib-special-exams	TRUE	"@reduxjs/toolkit": "^1.5.1"	FALSE
Discussions	https://github.com/openedx/frontend-app-discussions	TRUE	"@reduxjs/toolkit": "1.9.7"	FALSE
Learning	https://github.com/openedx/frontend-app-learning	TRUE	"@reduxjs/toolkit": "1.9.7"	FALSE
Gradebook	https://github.com/openedx/frontend-app-gradebook	TRUE	"@reduxjs/toolkit": "^1.5.1", "redux-beacon": "^2.1.0"	FALSE
Ora	https://github.com/openedx/frontend-app-ora	TRUE	"@reduxjs/toolkit": "^1.9.7"	TRUE	"@tanstack/react-query": "^4.29.25"
Learner-dashboard	https://github.com/openedx/frontend-app-learner-dashboard	TRUE	"@reduxjs/toolkit": "^2.0.0"	FALSE

Here's a list of possible Redux dependencies to look out for:

Package Name	Version
react-redux	7.2.9
redux	4.2.1
redux-devtools-extension	2.13.9
redux-form	8.3.10
redux-logger	3.0.6
redux-mock-store	1.5.5
@redux-devtools/extension	^3.3.0
@reduxjs/toolkit	1.9.7
redux-thunk	2.4.2
redux-beacon	^2.1.0
reselect	^4.1.5

[arbrandes]

@tonybusa,

I'm curious about where to create the context files - do we want to encapsulate them as much as possible? Or should we create a parent context folder and name the per component?

The main selling point of Context is to avoid prop drilling. Only taking that into consideration, we can create multiple contexts so that each is defined at the top-most level where a particular property is required (encapsulated, as you say). As long as we follow some sort of pattern (even a simple one: contexts get their own file), we should be fine. I don't think we need a dedicated "all contexts go here" directory.

Plus, React Query and its dedicated QueryContext will handle most server-side state, so I don't actually foresee needing all that many different Contexts. And those that do come up will likely be due to a specific need of a part of the app. Exactly like that EditorContext you point to.

(When will we actually need Context? I expect mostly to manage implicit dependencies of data fetched at initialization, and, occasionally, for pure client-side state management, potentially with Reducers if the state is very complicated).