Redux sub-reducer pattern for complex / nested data structures

I love the idea of the Redux pattern, the way all reducers are pure and predictable. I love the way they are effectively listeners that act on event notifications received from a central dispatcher, and I really like the way the whole approach simplifies the application and makes code in my Angular app's components only concerned with view related concerns rather than business logic. However, what I am not a big fan of is the normalised data approach. I've seen it recommended so many times for use with the Redux approach. You essentially have any object (read "row from table on server") in memory once and then everywhere else you hold a reference to the locally stored record/object by its unique ID. So, a view state you receive that looks like this

[
  { "id": "Emp1024", "name": "Peter Morris", "address": { "id": "123", "street": "xxx" } },
  { "id": "Emp4096", "name": "Bob Smith", "address": { "id": "254", "street": "yyy" } }
]

Might be flattened out to something like this

{
  "people": {
    "Emp1024": { "name": "Peter Morris", "address": "123" },
    "Emp4096": { "name": "Bob Smith", "address": "254" },
    "_ids": [ "Emp1024", "Emp4096" ]
  },
  "addresses": [
    "123": { "street": "xxx" },
    "254": { "street": "yyy" }
  ]
}

What I do like about this is approach

1. When your reducer has to locate an object to update it, it can find it immediately without having to iterate over the whole array.
2. Only objects (rows) that have their state affected by the dispatched notification will be recreated, the rest will be copied as-is into the new array of objects 

What I don't like about this is

1. API servers don't usually return data in a normalised format, so the client has to normalise data from the server (especially if you don't own the server code and cannot change it).
2. Because the keys of an object can be stored in an indeterminate order we have to maintain an additional property containing an array of the Ids so we know in which order to display them.
3. A local copy of the remote data is cached locally by the client and isn't unloaded.

My preferred approach is to have state per task, like so

  {
    "task1": { .............. },
    "task2": { .............. },
    etc
  }

The state that each task (read "route") works with can be exactly what the server sent to the client. We can clear out unwanted state in the core reducer by only keeping cross-task data whenever the client's route changes (such as user-name, session token etc).

function coreReducer(state: any, action: Action) {
  switch (action.type) {
    case 'ChangeRoute': 
      return { loginInfo: state.loginInfo };
         
    default:
      return state;
  }
}

Of course, normalised data can be cleared down in this way too, when switching between tasks. However, imagine a task such as "Dashboard" onto which users can drop any number of widgets that present server data of all kinds. As these widgets update their data they are unable to relinquish any data they previously loaded, because without reference counting on everything they refer to there is no way to know which rows of data are not being used by any of the other widgets currently on screen. But if our data is nested then each widget contains all of the data it needs at any moment. Some of the same data (addresses, employees, etc) may exist in memory on the client more than once (one per widget) but that data is unloaded when finished with. The use of additional memory means that our memory usage doesn't creep up throughout the day.

To reduce nested (complex) data is quite easy. Using an approach I learned on a Martin Odersky's course it is possible to change an object at the left of a complex data tree without having to replace the entire tree.

Image credit

export const subReduce = (state: any, action: any, reducers: any) => {
  // If we have an original state then copy it, otherwise keep a null state
  let newState = state ? {...state} : null;
  for (const key of Object.keys(reducers)) {
    // Grab the previous member state. If passed state is null the member state is null
    const previousMemberState = state !== null ? state[key] : null;
    const reducer = reducers[key];
    const newMemberState = reducer(previousMemberState, action);

    // Scenarios are
    // 1: No initial state object and new member state is null = keep null state
    // 2: No initial state object and has new member state = new state + set member
    // 3: Has initial state object and member state set = keep state + set member
    // 4: Has initial state object and member state is null = keep state + unset member
    // If we need to set a member to a non null value then we need an instance
    if (newState === null && newMemberState) {
      newState = {};
    }
    if (newState) {
      newState[key] = newMemberState;
    }
  }
  return newState;
}

There is still a reducer per object type, but these reducers are now nested too. They used the subReduce() function to declare their complex child properties.

export const addressReducer = (state: Address = null, action: any) => {
  switch (action.type) {
    case 'address.update':
      return Object.assign({}, state, action.payload);
  }
  return state;
}

export const addressArrayReducer = (state: Address[] = null, action: any) => {
  if (!state) {
    return state;
  }

  return state.map(x => {
    if (x.id === action.payload.id) {
      return addressReducer(x, action);
    } else {
      return x;
    }
  });
}

export const personReducer = (state: Person = null, action: any) => {
  state = subReduce(state, action, {
    addresses: addressArrayReducer
  });
  switch (action.type) {
    case 'person.setName':
      return {
        ...state,
        name: action.payload
      };
  }
  return state;
}

export const rootReducer = {
  person: personReducer
}

Of course, you can use this approach and still use normalised data to benefit from the redundant data-unloading whilst keeping your normalised data.

{
  task1: null,
  task2: null,
  dashboard: {
    widget1: {
      "people": {
        "Emp1024": { "name": "Peter Morris", "address": "123" },
        "Emp4096": { "name": "Bob Smith", "address": "254" },
        "_ids": [ "Emp1024", "Emp4096" ]
      },
      "addresses": [
        "123": { "street": "xxx" },
        "254": { "street": "yyy" }
      ]
    },
    widget2: { /* whatever */ },
    widget3: {
      "people": {
        "Emp1024": { "name": "Peter Morris"},
        "Emp4096": { "name": "Bob Smith"},
        "Emp8192": { "name": "Aled Jones"},
        "_ids": [ "Emp4096", "Emp8192", "Emp1024" ]
      }
    }
  },
}