Okay, this is still a draft PR because I can see comments in the Cyrillic alphabet ;) but I had a rough read through!

I like that all the main pieces of the solution seem to be there, and that you were able to use the API to get the required data. What was the reason to fetch locations by ID? We should not need to do two API calls for something that can be a database join and, if it's just one or two fields that are missing it's much better if we add it to the API payload - you can open a ticket in https://github.com/falling-fruit/falling-fruit-api and stub out the data for now. Either Ethan will add it, or I'll be able to have a go myself.

Instead of changing state.list and state.location (which hold data needed the list page and location page respectively), it's going to be much better for maintainability if you define a new slice, state.activity, and keep the state there: it will look like

const { changes, isLoading, offset } = useSelector(state.activity)

in the component. The async / promise chaining code should also go there, and ideally your component will mostly be rendering and doing UI code.

We would also benefit if the organization of the changes follows a few other conventions in the code base:

• the effect of first changes being loaded after the initial URL load goes in the src/components/connect folder, see src/components/connect/ConnectTypes.js
• styles go in the same module as the component being styled
• utils go in src/utils

Can you have a look at existing usages of state.type.typesAccess and compare to how you've used it currently? It's a class, with methods for accessing the data, so the rest of the code base shouldn't need to access state.type.typesAccess.localizedTypes.