Use Immutable Record for accounts in Redux state

[renchap]

This is inspired by #25137, but uses proper Record objects everywhere, in addition to adding types.

Related to #26555 as well

I chose to introduce two new directories, to better organize the code:

• api_types contain the interfaces for the values returned by the Rails API. At some point, we will probably want to generate those using OpenAPI or equivalent
• models contain the type definitions for the objects used in the Redux state, as well as any associated functions. For now, they contain a function to create a model from an API JSON

Notable changes:

• initialState now uses the API JSON types when they are defined
• convertState has been changed to create Record objects on keys they have corresponding models
• Converting a JSON from the API into a Record to be used in the state is all done in one place
• The accounts_counters reducer was merged into the accounts reducer
• accounts reducer and associated actions has been converted into Typescript
• relationships reduced has been converted into Typescript
• makeGetAccount is reimplemented to return a properly typed Record, allowing consumer components to be typed correctly

TODO:

• (maybe) add runtime checks (in dev only?) to ensure we do not have unknown fields in API responses that are dropped when creating the Record

[renchap]

Pushed the current state of my work.

• Object shapes should now be correct, both for the API JSONs and the Immutable <Record>, including computing the various fields that are used. It is all moved in the model
• accounts reducer is written in Typescript, and the actions are correctly typed. I could not use createReducer from RTK as it does not work well with an Immutable state, but it should not be hard to convert later
• ACCOUNT_IMPORT action was not used anywhere, dropping it
• makeGetAccount is reimplemented to return a properly typed Record. It is not yet complete as I need to convert accountsCounter and relationships to Typescript, but this should not be very hard

[renchap]

I dropped accounts_counters entirely in my latest commit, as the only use for this reducer is to be merged back into Account in makeUserSelector, let's store those directly in Account

[punmechanic]

One potential concern with mixing Redux Starter Kit and plain old reducers is that it's not easy to type it safely.

To type an "old-style" reducer, you need to create a discriminant union for Action:

type Action = 
  | { type: "ACTION_NAME"; payload: A[] }
  | { type: "ACTION_NAME_2"; payload: B[] }

With redux starter kit actions, you no longer have access to the string literal used to construct the action, which means you can't construct a discriminant without duplicating the name across files:

// app.ts
export const frobTheWidget = createAction('FROB_WIDGET');

// reducer.ts
type Action = 
  | { type: "FROB_WIDGET", ... }
  | { type: "ACTION_NAME"; payload: A[] }
  | { type: "ACTION_NAME_2"; payload: B[] }

Or by exporting it as a constant:

export const FROB_THE_WIDGET = "FROB_WIDGET";
export const frobTheWidget = createAction(FROB_THE_WIDGET);

You can infer the type of the action struct:

type ActionType = ReturnType<typeof frobTheWidget>

However, the typings of RSK assigns the type string to the type property - which means that the discriminant union approach in a reducer no longer works, since any string is assignable to string:

type Action = 
  | { type: "ACTION_NAME"; payload: A[] }
  | { type: "ACTION_NAME_2"; payload: B[] }
  // TypeScript infers the following to be { type: string }
  | ReturnType<typeof frobTheWidget>

function reduce(state, action: Action) {
   switch (action.type) {
      case frobTheWidget.type:
        // Type is not narrowed; this branch has access to `payload`, which has the type `A[] | B[]`.
        // This is obviously incorrect at runtime
      case "ACTION_NAME":
        // Type narrowed to { type: "ACTION_NAME"; payload: A[] } | { type: string }
        // Therefore accessing payload requires a presence check
   }
}

For the purposes of this PR, this presents in accounts_map.js, relationships.js and timelines.js as of 5352ca1; these reducers cannot be safely typed if they mix RSK actions and POJO actions. I'm not sure what the solution is here, but it'll present a problem if one tried to convert this to TypeScript at a later date.

[renchap]

If the reducers are not converted to Typescript, you can use frobTheWidget.type like in your example.

Once they are converted to Typescript, you can use either:

• createReducer from RTK, if the state has been converted to plain object
• else if(fromTheWidget.match(action)) { … } if the state is still an Immutable object, like I did in this PR with reducers/account.ts

In both cases, all the actions needs to be converted to createAction, but I do not think this is a big issue?

[punmechanic]

Yes, sorry, my comments are not intended to be a criticism. When merging this code into the branch for the PR I noticed the typing issue that might occur, so I wanted to mention it.

[renchap]

No problem, I was only wondering if you saw an issue with the approach I described 😄

I plan to have a go at converting the relationships reducer to Typescript, and all the actions it uses to createAction, before marking this PR as ready.

Also this will probably need to wait for the 4.2 release branch cutoff (hopefully next week) before being merged, we do not really want to merge such a big change just before a release.

[punmechanic]

Aligned! I'll plug away on some other component refactors :)

[github-actions]

This pull request has merge conflicts that must be resolved before it can be merged.

[renchap]

Relationships should now be fully typed.

I also split a few of the commits from this PR into their own PRs, to make it easier to review.

There is a type issue with using createAppAsyncThunk once a reducer starts referencing it, as it creates a circular dependency issue.

I need to check why it does this.

[github-actions]

This pull request has resolved merge conflicts and is ready for review.

[github-actions]

This pull request has merge conflicts that must be resolved before it can be merged.

[github-actions]

This pull request has resolved merge conflicts and is ready for review.