NgRx Entity relationships and navigation

[woeful mulch]

Hi, I find it hard to find a good blog or video about managing entity relationships in NgRx.

For example, a Customer entity could have a one-to-many relationship with Order entities. The Order entity has an order.customer property whose value is the primary key of its parent Customer.
Each Order has related LineItems. A LineItems has a one-to-one relationship with Product. And so it goes.
There are other cardinalities to consider (one-to-zero, one-to-zero-or-many, many-to-many, etc.).

TL;DR: There will be long chains of navigations (Customer <-> Order <-> <-> LineItem <-> Product <-> Supplier). How should these be implemented?

I've found @NgRx/entity, which may suit my needs. Although I am unsure how it exactly works and couldn't find much info about it with entity relations (with explicitly, my question/issue) as an example.

My question; does @NgRx/entity solve the issues I'm having implementing navigations between entities in my app? If so, what would be needed to implement it in an existing app that has no navigations present yet/does not make use of this package yet?
(I already have store/selectors/actions/reducers implemented for most of my entities, but hadn't done the relations between them yet).
(Also, maybe handy to know or maybe irrelevant: I get my data from a normalized (3NF) relational database with a .NET API).

[woeful mulch]

I also found this https://christianlydemann.com/top-5-ngrx-mistakes/

The goal here is to create a single source of truth for all our data entities in the store, so you eg. only need to maintain user information in one place in the store.

As a general rule of thumb, you shouldn’t have big arrays for entity types in the store and instead create an Entity map using NgRx entity. Entity maps are simply key-value pairs with unique entities. Having data organized this way makes reading and updating fast and that is what we want to optimize for.

In that way, we can organize the store to be a single source of truth and instead use selectors to project view models for different use cases. That way, when you update a certain entity in the system, you can be sure that the update is reflected in all other places in the application.

[sonic bison]

I personally wouldn't use ngrx/entity since it's a bit limited.

You can simply save every entity type you get separately and use directives to create a selector by id then easily you can chain them up as you need.
Like this:
*ngIf="user.id | getUserById | async as user"

[woeful mulch]

I think I was kind of overthinking it yeah… after thinking about it and reading this I think I’ll do it like that yeah. Keep entities separated and use selectors.

However something else came to me now, if I show a Customer for example, and I want to show its orders, and I want to get then locally first and do an api request if they aren’t present;
I would use a selector first, and if the orders of specified ids aren’t in the store I dispatch an action to get them right?