EntityQuery's UI Query select function return types do not include the id key

[adekau]

I'm submitting a...

[ ] Regression (a behavior that used to work and stopped working in a new release)
[x] Bug report  
[ ] Performance issue
[ ] Feature request
[ ] Documentation issue or request
[ ] Support request
[ ] Other... Please describe:

Current behavior

If I have an EntityState<UI, TIdKey>, for the ui property of a class extending EntityQuery the functions selectAll(), selectMany(), etc. return Observable<UI[]>.

Expected behavior

The actual emission of the observable is the intersection of the UI entity and the id key: (UI & { [idKey]: TIdKey })[].

Minimal reproduction of the problem with instructions

https://stackblitz.com/edit/angular-ivy-3pza2f?file=src/app/app.component.ts

Notice that MovieUI only includes two properties (note, somethingElse) but the ui.selectAll() which returns a list of objects implementing this interface. The actual output (also console.logged) includes 3 properties: name, note, somethingElse where name is the idKey of the entity store.

What is the motivation / use case for changing the behavior?

The function returns additional properties not on the UI interface, and should be typed accordingly.

Environment

Angular version: 10.1.1


Browser:
- [x] Chrome (desktop) version 85
- [ ] Chrome (Android) version XX
- [ ] Chrome (iOS) version XX
- [x] Firefox version 80
- [ ] Safari (desktop) version XX
- [ ] Safari (iOS) version XX
- [ ] IE version XX
- [ ] Edge version XX
 
For Tooling issues:
- Node version: 12.18.3  
- Platform:  Windows 

Others:
- Akita version: 5.2.3

[NetanelBasal]

Akita doesn't know anything about the types. You should add it to the interface.

[NetanelBasal]

export interface MovieUI {
  name: string;
  note: string;
  somethingElse: boolean;
}

[adekau]

I don't follow "Akita doesn't know anything about the types".

It appears it's explicitly returning the concatenation of the idKey and your UI object on UI creation:
https://github.com/datorama/akita/blob/3cc0d3f239e6917c54021ba0c54a536185c61ee5/libs/akita/src/lib/entityStore.ts#L633-L640
If I'm looking at the right spot.

The intersection can be determined statically, I don't see why not add it to the return type for EntityUIQuery.

[NetanelBasal]

I don't understand what you mean. The return type is MovieUI. You're welcome to create PR and show your solution.

[adekau]

Sure, I can look into the code and make a PR when I have some time.

General idea is that: yes we can add the id key to the interface MovieUI and that solves the problem. But we shouldn't need to do this because it's a property that is tacked on by Akita's EntityUIQuery class methods (selectAll, etc).

If MovieUI is

export interface MovieUI {
  name: string; // <-- id key
  note: string;
  somethingElse: boolean;
}

Then that is equivalent to MovieUI without name on it but tacked on in the return type of these Query functions through a type intersection, MovieUI & { name: string }. The difference is where this definition comes from. In your suggestion, the user has to know that Akita is going to add the id key to the return of UI Entity query functions and accordingly add it to the UI Entity interface. It's then the responsibility of the user to know implementation details of Akita itself. Rather, in my opinion, it makes sense to intersect the user's type with additional properties Akita adds in its implementation.

[lilas78]

Can you have any solution to this point ? I can't do either any intersection between a EntityUIQuery and a EntityQuery because the UIEntity doesn't expose its internal 'id' property which is the link with the corresponding Entity object.