Platform: In examples is there a reason to using object to store entities v's Map?

[michaeljohnbennett]

I'm submitting a...

[X] Documentation issue or request

What is the current behavior?

In the current examples or generally in documentation we see the use of holding entities in the state objects using an object model like

From books/reducers/books.ts

export interface State {
  ids: string[];
  entities: { [id: string]: Book };
  selectedBookId: string | null;
}

There is also a lot of object assign code to then go in and add/amend this object using filters etc.

Expected behavior:

Would there be any benefit to using the Map interface in Typescript instead? It's a much cleaner API and the objects can be easily cloned into a new one each time we transition state. In most other caching API I have used in java (Infinispan for example) we back with hashmaps as it makes life a lot easier.

Couldn't we use something like:

export interface State {
  ids: string[];
  entities:  Map<string, Book>;
  selectedBookId: string | null;
}

And then finding/removing/updating is all done via the api calls has/delete/set. Plus it has iterator vbehaviour etc if really needed to map out the entries to an object array of entities. It would make the reducer code much easier to work with in my opinion.

Reasons for Object based storage?

Is there a performance or other reason why best practices are for the object style usage above?

[MikeRyanDev]

The reason is that you can't serialize and deserialize Maps. Serialization is important for most state hydration techniques, including server-side rendering and local storage syncing.

[Judp0m]

+1 to be able to use Map instead of {[key: Key]: Value}