New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(angular-query): added observable support #6726
base: main
Are you sure you want to change the base?
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎ 1 Ignored Deployment
|
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit 26de580:
|
53df354
to
3cca2ec
Compare
☁️ Nx Cloud ReportCI is running/has finished running commands for commit 26de580. As they complete they will appear below. Click to see the status, the terminal output, and the build insights. 📂 See all runs for this CI Pipeline Execution ✅ Successfully ran 1 targetSent with 💌 from NxCloud. |
3cca2ec
to
38ca649
Compare
38ca649
to
451c131
Compare
chore(angular-query): fix knip issues feat(angular-query): throw errors when the observable breaks
451c131
to
26de580
Compare
First thoughts: Can we do this via an overload on I'm not convinced we should accept values coming in from the observable after the first one. This behaviour is quite different from the other adapters where a value is received once. Didn't delve deep into this yet but I can imagine APIs aren't designed for this and a few bugs may result from this too. It also needs quite a lot of code (bundle size) for something that won't be used very much. We may choose to support it but I don't think If we could simplify this a bit with an overload and support a single value emission only it will be a great addition. |
Maybe we can rename it to
On the That being said, we could try and just support observables only on the new inject function but I believe it's name would be confusing to say the least. However, given Angular's normal behaviour, the http client should just return a response once and it should just finalize. That's why I'm thinking this new function wouldn't bring too much value. Can't wait for feedback on all this. Thanks! |
I've added a
query$
property on the options of the query. It's a function that accepts acontext
just like thequeryFn
prop does and it returns an observable. It automatically unsubscribe to the observable if the abort signal is called.@arnoud-dv how does this look?