DATAP-1208 Convert reducers to RTK slices

[wwhorton]

Redux Toolkit divides redux state into "slices", which make managing state easier and more efficient. Explorer was converted to use slices, but CCDB hadn't yet. This is a PR converting all the reducers to slices, updating tests to accommodate the changes, and refactoring code where necessary, mainly in dispatches. Most of the content of the actions directory was removed since it's handled in the extraReducers piece of the slices, but where it seemed to make more sense to leave them as is, I did.

Removals

• boilerplate action creators
• boilerplate reducer setup
• snapshot tests
• redux-mock-store

Changes

• numerous, but, broadly speaking, all of the reducers are now slices and have been converted in place
• the store was updated to use the newer RTK format
• added testing-library tests instead of snapshot tests
• added test setup using real reducers and actions
• added logic from Complaint Explorer
• split off logic from Query reducer into Filters, Map, and Trends reducers
• added middleware to bring together parameters to query the api
• added middleware logic to only query the aggregations endpoint only when required instead of currently querying both results and aggregations no matter what
• added React strict mode to catch more errors during development
• Fix company typeahead

Testing

• yarn test: All tests should pass
• Since redux touches all parts of the app, it would probably be a good idea to go through manually and make sure that everything looks as it should and works as expected.

Notes

• The names of the tests should probably be updated to reflect the new reducer action names. It didn't occur to me until pretty late in the process, but I don't want to hold up the PR to make those updates when they could be a separate one.
• Something unexpected I learned was that when state updates in actions relied on a return value from enforceValues() they didn't actually update with the new value if it was within a returned object, e.g. { ...state, newValue: enforceValues(x,'y') }. It had to be written in the "state.value = enforceValues(x, 'y')" form. I think this might have something to do with Immer, but it's probably a good idea for all the state updates to take that form. Again, probably ought to be another PR to update that in the places it wasn't necessary for this PR.

Todos

• Go through and prune away tests that are no longer required, and add tests to meet coverage requirements. Because the conversion alone results in an enormous PR I thought it would be a good idea to do this part as a separate PR.
• Optimize the slices and the action directory. Again, to avoid complicating what was already a huge PR, I didn't do this, preferring to set it aside as a separate PR.

Checklist

• Changes are limited to a single goal (no scope creep)
• Code can be automatically merged (no conflicts)
• Code follows the standards laid out in the front end playbook
• Passes all existing automated tests
• New functions include new tests
• New functions are documented (with a description, list of inputs, and expected output)
• Placeholder code is flagged
• Visually tested in supported browsers and devices
• Project documentation has been updated (including the "Unreleased" section of the CHANGELOG)

[cdmh219]

Nothing needed from this comment, just a suggestion. Now that we're on RTK, do you think RTK Query could be a good option for our API calls? Seems like it would eliminate a lot of the custom structure we've put in place to create and make API calls. May be something to look into down the line.

[flacoman91]

Nothing needed from this comment, just a suggestion. Now that we're on RTK, do you think RTK Query could be a good option for our API calls? Seems like it would eliminate a lot of the custom structure we've put in place to create and make API calls. May be something to look into down the line.

Yes, great suggestion. I'm all for anything that reduces custom code and not reinventing the wheel!

[cdmh219]

Also doesn't look like that RTK's createAsyncThunk() is being used for API calls. RTK Query is a separate library and long-term solution that may or may not be a good fit, but createAsyncThunk() could be used immediately, as it is an out-of-the-box solution for properly integrating Redux with API calls. That will also eliminate much of our custom logic. More about this can be found here