angular-query - Some feedback and ideas to fix types in template

[riccardoperra]

@arnoud-dv

We recently released an app to production which has Angular query as state manager. It started out as an experiment but we tried to keep everything up to date as much as possible. So far we have integrated pagination, infinite queries, mutation, routing-dependent queries etc. Everything went smoothly, except for one thing: type narrowing on the template.

There are several problems on WebStorm, even Angular compiler usually doesn't complain, but it looks like we cannot take advantage of inference when using for example @switch (query.status()) or @if (query.data()) / loading / error etc due to the "function call".

I would therefore like to propose to review the signature of the injectQuery function, in order to just use the proxy getters value instead of returning the computed signal. There are adapters like the solid-js one that uses createStore under the hood, https://www.solidjs.com/docs/latest/api#createstore, which creates a proxified signals without necessarily having to call the function.

This allow us to rely directly on official types like the others adapter does. The BaseNarrowing type that exists now works for most of cases, but due to angular template language it seems not working for switch or some if, and at least greatly complicates the types

Inference with current types

(this is on webstorm, which every update has a different broken behavior 🤦). Currently on EAP 2024.1 it's not working again on my Mac, but seems working on Windows (maybe I have a older version). 2023 is still broken since there are some issues on typescript language with angular templates (since 2020, but ok).

Inference with proxy getters

Possible solution

Like I did in that branch. It would seem to be enough to return the value of the signal on the getter. I don't think there's any specific reason why it shouldn't be called instantly. The types at this point become much easier and more manageable

riccardoperra@10c3695#diff-f070d25b07f5d59290303a441b746fa17bfd96cbea48bfbc6dc677d433f3629e

I know this is a breaking change, i'd like to help, but before doing this I would start adding some tests to ensure everything works as usual. The alternative is that we could add a parameter that "enables" this new signature until we are sure it is the best way

[arnoud-dv]

Thank you for the elaborate feedback, much appreciated.

In early versions of this Angular adapter queries returned a single signal with an object and type narrowing was working perfectly. @eneajaho suggested and submitted a PR that split the query signal into separate ones. Depending on the exact application this is potentially much more efficient and overall I do much prefer the developer experience with the split signals. It was a great improvement for Angular Query IMO. Typing narrowing in templates on an object with signals is a huge problem though. As I too use primarily WebStorm I am aware of the especially bad experience there..

Converting the signal functions to getters does indeed solve type narrowing as it becomes simply a discriminated union on an object but it has its own drawbacks. Signals being accessed through a function call from the template is very intentional. We would be "fighting" the framework.

The Angular team is working on improving typing for signals in templates but I don't know yet if these improvements would solve this situation. I'll look into this further and see if the API needs to be changed to solve type narrowing.

[arnoud-dv]

By the way, awesome to read about the positive experience you had with building the app with Angular Query, that's really motivating! Type narrowing in templates does indeed need to be solved though, I will put this at the top of my todo list.