search

apollographql / apollo-feature-requests

🧑‍🚀 Apollo Client Feature Requests | (no 🐛 please).
Other
130 stars 7 forks source link

RxJS support #375

Open hwillson opened 2 years ago

hwillson commented 2 years ago

This is a tracking issue for allowing ApolloClient and ApolloLink to use alternate Observable implementations, without bundling a default implementation (currently zen-observable-ts).

Thanks to @PowerKiKi for getting this work started twice (and sorry for the long wait):

Related issues:

Other considerations:

PowerKiKi commented 2 years ago

Do this mean that you confirm your interest in this work, and that I can continue working on apollographql/apollo-client#9331 ?

hwillson commented 2 years ago

@PowerKiKi yes definitely. Thanks for all of your help with this!

PowerKiKi commented 2 years ago

Could you please provide a hint on how to handle Concast, as detailed in the PR, and specifically whether it might acceptable to break some/all compatibility of this specific class ?

benjamn commented 2 years ago

@PowerKiKi You're welcome to change the public interface of Concast, since it should be an internal-only API. The bigger issue is the other Observable subclass, ObservableQuery, since it's a public API, but I think we can take measures to retain backwards compatibility when switching the base class to the RxJS Observable implementation (like providing some of the methods that are no longer inherited). Hopefully we can later remove those compatibility measures in AC4.

Sorry for the delayed response!

PowerKiKi commented 5 months ago

@jerelmiller could you share the internal status of this work ? is it still something you are considering in the foreseeable future ? or were resources redirected to other developments ?

I can see that the previous, aborted, PR is part of the future v4. Is it still accurate ?

v2.0.0 was released in 2017 , v3.0.0 in 2020. Does that mean that a v4 may happen in 2024-2025 ?

PS: since this issue was created, rxjs became the reference for the new-ish Observable proposal, and Chrome seems to already be working on a prototype implementation. So that probably further solidify rxjs position as the de-facto observable implementation.

jerelmiller commented 5 months ago

@PowerKiKi we are still in the early stages of v4 planning but we ARE planning on a v4 release this year 🙂. We've talked about it as a team and are all in favor of making the switch to RxJS. I don't have a timeline quite yet, other than to say we are targeting a new major this year. It certainly is time for one 🙂

since this issue was created, rxjs became the reference for the new-ish Observable proposal, and Chrome seems to already be working on a prototype implementation. So that probably further solidify rxjs position as the de-facto observable implementation.

I did see this! This is super cool and glad we might finally have a built-in primitive. If I remember right, I think I saw that rxjs will over time become more of the "utilities on top of observable" once there is broad browser support? (perhaps a Ben Lesh tweet? Or maybe I'm imagining things 😅). But either way, this is good signal that this change would be a positive one for the library.