-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
[release-3.0] RxJS #5749
[release-3.0] RxJS #5749
Conversation
The only difference in size is when tree-shaking is off but I don't believe it's big a problem |
a1fee61
to
1b40f35
Compare
Thanks for diving into this! I've long thought it would be nice if folks could bring their own Looks like you might just need to update the |
1b40f35
to
24d724a
Compare
@benjamn yeah, I didn't see the |
@benjamn @jbaxleyiii @hwillson I can fix tests but I need to know if you guys even consider accepting the Pull Request. It seems like tests need to be be refactored a bit (observable related code, no change in the logic of tests). |
I think this is a good idea and will benefit those that already have I like the idea of the Do we have any idea about:
|
I know this is question from January, but anyway, the answer to the following question of yours is simple.
All Angular applications using Apollo. |
Just saw this tweet from @benlesh about reducing the size of RxJS operators (see recent commits here), so I'm even more in favor of switching to RxJS once they release v7. @kamilkisiela Also just wanted to say: we haven't forgotten about this! |
@benjamn I can assist or even create a PR for it. RxJS is fun |
@kamilkisiela It looks like there are some recent betas for v7, like https://www.npmjs.com/package/rxjs/v/7.0.0-beta.5. I know this PR has gotten pretty conflicted (sorry), but I'd be thrilled if you have time to put together an updated version, using the If these changes are as backwards compatible as we hope, this could be just a minor version change for Apollo Client… though I'm also not opposed to releasing AC4 with these changes, if we think that's warranted. |
@benjamn I already rebased and upgraded to rxjs 7 (latest beta) |
the only difference between RxJS Observable and Zen is that RxJS is sync and Zen async or the other way around so it may break things, we will see. |
@kamilkisiela In case this wasn't clear, be sure to rebase against |
this is needed because of apollo client behavior apollographql/apollo-client#5749
this is needed because of apollo client behavior apollographql/apollo-client#5749
this is needed because of apollo client behavior apollographql/apollo-client#5749
this is needed because of apollo client behavior apollographql/apollo-client#5749
this is needed because of apollo client behavior apollographql/apollo-client#5749
Apollo Client currently uses the Observable implementation provided by the zen-observable npm package, since it is small and works well for our needs. Although zen-observable itself is not written in TypeScript, we use the companion package @types/zen-observable to provide types. We are actively considering switching from zen-observable to RxJS (#5749), though it remains to be seen how much of a breaking change that will be (and thus whether it makes sense for a minor or major version update). In the meantime, several issues (most recently #5961) have been opened pointing out that zen-observable effectively does not support importing its code as ECMAScript modules, even though it has a separate entry point (zen-observable/esm.js) that uses ESM syntax. This is a problem the zen-observable package could easily fix by adding a "module" field to its package.json, but @abdonrd tried to propose that change in a PR (as I requested), and has not heard back since June 2020: zenparsing/zen-observable#74 Fortunately, Apollo maintains an npm package called zen-observable-ts, which was originally created to provide TypeScript types, before @types/zen-observable was introduced. This commit revives that wrapper package, so we can make sure both CommonJS and ESM exports are supported, with full TypeScript types, until the zen-observable maintainer gets around to merging that PR. I considered forking zen-observable, but I'm happy with this wrapping strategy, since reusing zen-observable makes it easier to take advantage of any future updates to the zen-observable package. I also considered using https://www.npmjs.com/package/patch-package to apply changes to node_modules/zen-observable/package.json upon installation, but that doesn't really work unless @apollo/client bundles the zen-observable implementation into itself, since otherwise the original (unpatched) zen-observable package will continue to be installed when developers npm install @apollo/client. The patch-package tool is great, but I don't think it's meant for libraries to use. Thankfully, this time around we do not need to hand-write the TypeScript types, since they can be re-exported from @types/zen-observable. I bumped the major version of zen-observable-ts, since the older versions (used by apollo-link) still get more than two million downloads per week. The source code for the zen-observable-ts package can now be found at https://github.com/apollographql/zen-observable-ts, rather than the old https://github.com/apollographql/apollo-link monorepo.
Apollo Client currently uses the Observable implementation provided by the zen-observable npm package, since it is small and works well for our needs. Although zen-observable itself is not written in TypeScript, we use the companion package @types/zen-observable to provide types. We are actively considering switching from zen-observable to RxJS (#5749), though it remains to be seen how much of a breaking change that will be (and thus whether it makes sense for a minor or major version update). In the meantime, several issues (most recently #5961) have been opened pointing out that zen-observable effectively does not support importing its code as ECMAScript modules, even though it has a separate entry point (zen-observable/esm.js) that uses ESM syntax. This is a problem the zen-observable package could easily fix by adding a "module" field to its package.json, but @abdonrd tried to propose that change in a PR (as I requested), and has not heard back since June 2020: zenparsing/zen-observable#74 Fortunately, Apollo maintains an npm package called zen-observable-ts, which was originally created to provide TypeScript types, before @types/zen-observable was introduced. This commit revives that wrapper package, so we can make sure both CommonJS and ESM exports are supported, with full TypeScript types, until the zen-observable maintainer gets around to merging that PR. I considered forking zen-observable, but I'm happy with this wrapping strategy, since reusing zen-observable makes it easier to take advantage of any future updates to the zen-observable package. I also considered using https://www.npmjs.com/package/patch-package to apply changes to node_modules/zen-observable/package.json upon installation, but that doesn't really work unless @apollo/client bundles the zen-observable implementation into itself, since otherwise the original (unpatched) zen-observable package will continue to be installed when developers npm install @apollo/client. The patch-package tool is great, but I don't think it's meant for libraries to use. Thankfully, this time around we do not need to hand-write the TypeScript types, since they can be re-exported from @types/zen-observable. I bumped the major version of zen-observable-ts, since the older versions (used by apollo-link) still get more than two million downloads per week. The source code for the zen-observable-ts package can now be found at https://github.com/apollographql/zen-observable-ts, rather than the old https://github.com/apollographql/apollo-link monorepo.
RxJS v7 was just released (as I found out from #8106) at long last, so by the logic of my comment #5749 (comment) it may be time to take another look at this PR/project. cc @hwillson @jcreighton @brainkim for visibility |
@benjamn hmmm someone took my push rights away, can't update the branch |
@kamilkisiela you should be good now - thanks! |
@benjamn is this still something you'd be willing to merge ? @kamilkisiela are you able to rebase the PR ? or would we need new contributors to complete your work ? |
@benjamn @kamilkisiela ...if there's anything I can do to support you all here, please let me know. FWIW, the changes here look okay. I might recommend using 7.2+, so everything can be imported from |
I just created #9331 in hope to revive this PR and get it merged. I would appreciate any help to finish fixing tests, and opinions about the breaking change that it might be. |
Closing in favor of #9331 |
I know
zen-observable
is tiny butrxjs
can be too.Apollo Client could get rid of
zen-observable
,@types/zen-observable
andsymbol-observable
packages that are maintained but not as actively asrxjs
. Maybe even some day we could fade away fromApolloLink
and move completely towardsrxjs
.Apollo Client application bundle sizes
Sample React app (deps: @apollo/client, graphql, graphql-tag, react, react-dom)
Sample no view app (deps: @apollo/client, graphql, graphql-tag)