Remove Higher Order Components from Editors

[bradenmacdonald]

In src/editors/...

1. Replace injectIntl with useIntl() -> Replace the deprecated injectIntl with the useIntl() hook #2280
2. Replace usage of connect with useSelector() and useDispatch() -> Replace usage of connect with useSelector() and useDispatch() #2312
3. Update the code and tests to get rid of the Internal export pattern:
   Example of exporting (Component)Internal and Component = injectIntl(connect(...)) HOCs, then testing with the Internal one.

frontend-app-authoring/src/editors/containers/ProblemEditor/components/EditProblemView/AnswerWidget/AnswerOption.jsx

Lines 173 to 174 in 5df4cd9

	export const AnswerOptionInternal = AnswerOption; // For testing only
	export default injectIntl(connect(mapStateToProps, mapDispatchToProps)(memo(AnswerOption)));

frontend-app-authoring/src/editors/containers/ProblemEditor/components/EditProblemView/AnswerWidget/AnswerOption.test.jsx

Line 6 in 5df4cd9

import { AnswerOptionInternal as AnswerOption, mapStateToProps } from './AnswerOption';

Once the HOCs (injectIntl, connect) are replaced with hooks, if it's necessary to mock redux state in tests, convert the tests to use initializeMocks from src/testUtils.tsx and pass in initialState to initializeMocks. Or use const { reduxStore } = initializeMocks(); and dispatch changes to the redux store.

[diana-villalvazo-wgu]

Hi @bradenmacdonald quick question regarding Replace usage of connect with useSelector() and useDispatch() i heard that we are planning to move to react-query instead of redux in openedx, with that in mind, Do you think the effort to make connect replacement is worth it? or do you know if it will make easier the transition?

[bradenmacdonald]

@diana-villalvazo-wgu It depends... Replacing connect with useSelector is quite an easy refactor, and could probably even be automated with a codemod, so it can be done very quickly and is a nice modernization that also simplifies the test suite. Whereas changing to react-query is a huge refactor that will be a lot of work. So for example, if your team has interest and availability to work on refactoring parts of the codebase to use React Query later this year, then I'd say it makes sense to skip this for now. But otherwise I think it'll still be useful to do, and also might (?) make the react-query change slightly easier later but I'm not sure.

[diana-villalvazo-wgu]

Thanks Braden, Also fyi for 1. Jacobo is working on it as part of this #2280 if you want to reference it here :)

[diana-villalvazo-wgu]

Also i created #2312 and split it in multiple sub-issues to handle 2.