Release 3.0.0 #2892
Release 3.0.0 #2892
Conversation
Since there was no way to make `walkTree` behavior consistent with modern versions of React, it was deprecated in `react-apollo` 2.4.1.
We've been transitioning to use the default prettier standards across all Apollo repo's, so this will get us closer (the only non-default settings are now single quotes and trailing commas).
Preact is a great library, but it has fallen behind React in terms of functionality and compatibility with React's public API. Preact X is intended to help address this, but we're a bit concerned that it will also end up lagging behind other important areas of React functionality. To help simplify the React Apollo codebase, testing, and make sure we aren't held back from implementing new React features shortly after they're available, we're removing all Preact support for `react-apollo` 3.0.
The React Apollo `ROADMAP` is no longer tracked in this repository. We now create new github issues and/or release branches + PR's to track roadmaps, for specific releases, as needed.
This commit updates `react-apollo` to use React's new Context API internally, across the board.
Since we've been running with them disabled for quite some time, let's get rid of them.
|
The CJS and UMD tests will be left failing here for a bit; the testing infrastructure is being revamped as part of this work (e.g. |
|
Is there any help needed with react hooks integration or writing docs for react-apollo hooks? I’ve been using this library a lot and would be really interested in finding a way to contribute |
* Create useApolloClient.ts * Update index.ts * Import react, duh * Add semi (👀) * Throw on old React * Fix typecheck * chore(deps): update dependency @types/enzyme to v3.9.1 * chore(deps): update dependency react-testing-library to v6.0.2 * chore(deps): update dependency rollup to v1.7.0 * chore(deps): update dependency rollup-plugin-replace to v2.1.1 * chore(deps): update dependency typescript to v3.3.4000 * Adjust `useApolloClient` to return the `client` only We don't necessarily want to expose the entire `ApolloContext`. * Changelog updates
|
@mattfwood Please have a look at the trojanowski/react-apollo-hooks#93 |
|
Hi guys. |
This commit removes the use of deprecated React lifecycle methods (`componentWillMount`, `componentWillUpdate`, `componentWillReceiveProps`) from the `Query`, `Mutation` and `Subscription` Apollo components. This is a stepping stone towards more extensive `react-apollo` refactoring, as we move away from using React classes internally (making future React Hook use / integration easier).
|
@sessionboy We don't have a release date to share yet, but RA 3.0 is a priority. We're taking this opportunity to do a lot of housecleaning / preparing for the future, so it will take some time. That being said, we're talking weeks, not years 🙂. |
There are some advantages to using a linter with Typescript, but they aren't really something we're interested in using with React Apollo. Since tslint is being deprecated and reborn as an eslint add-on, we're going to stop using it altogether. We might consider bringing eslint into the project at some point in the future, but for now we're not interested in imposing additional rules or guidelines on potential contributors.
We might re-introduce dangerjs into the project at some point in the future (especially for missing `CHANGELOG` entries and/or tests), but for now we're not using it so let's get rid of it.
- Adjust `prepare-package.sh` to reflect current `package.json` - Remove `test-examples.sh` config and calls, since we are no longer testing examples (and will be moving the example apps out)
Probot is like a bottle of tequila. Sure, it sounds like a lot of fun and when you're in the middle of it, it is! But when the tequila aftermath happens, it hurts. Except in Probot's case you're not just hurting yourself, you're hurting OSS community members.
We poured one out for Apollo Bot a while back, so let's get rid of the leftover config.
This is the first major step towards our planned RA 3.0 restructuring goals. This commit introduces lerna and a new monorepo structure into the project, splitting existing core functionality up into the following separate packages: - @apollo/react-common - @apollo/react-components - @apollo/react-hoc - @apollo/react-hooks - @apollo/react-testing All existing code has been split up and moved into the packages they best align with, and each package now has full passing tests. As we introduce Hooks into the project, the contents of these packages will change, so the current location of certain functionality is not set in stone.
|
@hwillson what? |
|
@vladshcherbin |
|
@bwlt so in every project with react-apollo I'll need to copy-paste a function or add another package just to make HOCs work? You can find it in redux, recompose exactly for the same reason - they are needed for users who use HOCs. Unbelievable, how new updates ruin experience for old users. First, apollo-server unusable, now apollo-client. Guess it's time to search for alternatives. 🤦♂ |
|
@vladshcherbin We are talking about a new major release, not a minor. Libraries always end up dropping some methods and implementing new ones. Saying that you need an alternative because upgrading to 3.0.0 is too much hassle, because you need to use another library, seems unfair. Example: Ruby on Rails decided to drop Form helpers to create HTML because they felt it would make the framework more agnostic, and gave more options to the users. The users still could use it, if they added another package. It is not an unreasonable decision, even if it made upgrading a little more complicated. After all you have an option. To not upgrade to 3.0.0. And I'm not saying that you are not entitled to think that it does not fit your needs and to search for alternatives, but the light you put it under seems unfair. No need for facepalm. |
|
wow quite strong emotions here about such a small and basic, yet powerful, function. I don't think it's Apollo's job to provide you with a general hoc composition util. Nor that they have to carry that baggage forever onward because they included it before ;) OTOH, if it's such a pain, maybe deprecating it first and removing it later may be smoother sailing :) |
|
Exactly, first HOCs are removed from all examples and can be found only in API section, replaced with render props hype. Now hooks come and a small helper function a few bytes is removed (it's actually not removed and used in tests). All of this is a big fu for old users who used apollo since long time ago. If HOCs are not welcome anymore, remove it altogether and tell users to migrate to render props or hooks or find other libraries with HOC support. I'm not the only one who noticed this - apollographql/apollo-client#3253. I'm just tired of such things as apollo is bringing lots of pain lately, starting from server where I'm forced to use old version for > 1 year just because v2 api sucks (most upvoted issue). Now apollo-client and suggestion to stay on v2 forever. Take redux as an example, hooks were added there too, was |
|
You can also see the reaction to HOC removal from docs - apollographql/apollo-client#3253 (comment), it clearly shows how users appreciate this changes. |
|
It's worth noting that a Firstly, many users use HOCs with decorators instead of composition. If you're using decorators you don't need compose at all. Secondly, even if you're not using decorators you still don't need compose. And of course if you are within the subset of users whose teams avoid use of decorators and use HOCs enough that writing I might even say that including It's also worth noting that redux's |
|
@vladshcherbin this is an open source project, the Apollo maintainers are not your paid slaves, and are not obliged to maintain old code forever, so stop whinging.
The source is there if you have the talent to use it. |
|
@dantman in case of decorators those are only usable on classes right? I think that's definitely against the grain of recent class-less movement :) Otherwise agree. |
|
@patroza Yeah, but that's a recent movement that's grown in tandem with hooks. When HOCs were introduced many things could only be done with class components so most components were classes and there was no issue with using decorators. ^_^ And even if you tried to avoid classes by using recompose to manage state, all you ended up doing was wrapping your "class free" component in several layers of class based wrapper components. Making a codebase without any class components only really became viable when hooks were introduced. |
|
@dantman I don't use decorators and don't have another libraries which have @mikl with such toxic attitude as paid slaves, please don't mention me in any of your messages, thanks. The only reason a new issue about bringing back |
|
@vladshcherbin the toxic attitude is yours: complaining that the people who've created the open source software you've profited from (presumably without paying) are not doing it the way you want. That is treating them like slaves. |
|
@mikl treating like a slave by just asking the reason it was removed? Okay, man, sure. I've added you to black list, please don't waste your time by replying to me. Thanks and have a nice day 👋 |
|
I use compose from redux whenever I need it, but I would also be happy to switch to just using the lodash function if redux and all other relevant HOC libraries decided to drop their own implementations.. generally agree that it’s unintuitive for so many HOC libraries to ship and maintain their own versions of a very basic and identical function. |
|
@vladshcherbin The reason why the slave comment was brought up wasn’t because you asked the reason why it was removed. You complained about it having been removed.[1] You’re correct in that the removal causes us developers some additional pain (having to retool our libraries). Nevertheless, we developers live by the grace and generosity of other people’s (unpaid) contributions and it’s not right to impose our will on others. 1: |
|
GraphQL, React, and JavaScript in general represent rapidly evolving ecosystems and I appreciate the diversity of opinions because it helps us find the strongest strategy. There is an open-source solution to this problem however: simply fork the repo and add back Tooling can even make re-releasing/rebasing automatic, and other users can even contribute other tools that promote a HoC-based strategy. The fork would also represent an active PR against this repo, to help the community find/discuss this strategy (even if it's closed). In fact, the best place to continue this discussion is in that PR/issue. Specifically for whether hooks are hype worth investing into, thankfully the React team itself addresses this question directly. I can tell you from months of using hooks/ |
|
@vladshcherbin Hey man, this is just not the way to submit your feedback and criticism in the open source community. It is perfectly ok to have strong opinions, but you cannot come here with the attitude like that. You could have submitted the same concerns without making it sound like apollo team owes you anything. Just be respectful and nice dude. |
|
@vladshcherbin Take a deep breath and compose yourself. |
|
I just want to point out about that the I'll give you good reason why it should not be in this repo.
|
|
Sorry, this might be a dumb question. Since this MR is merged, can I assume that 3.0.0 with hooks support is already published to the public? The reason I am asking is that I see nowhere, including the official doc, mentioned anything about version 3.0 nor hooks support. The newest version I see in the official doc is 2.5. Cheers |
|
@kinyat And when will v3 be released?? |
|
@vladshcherbin I enjoyed your rant, it reminded me of some of previous employess who I couldn't wait to get away from :D |
This PR (and the
release-3.0.0branch) will be used to track allreact-apollo3.0.0 work. The main focus of React Apollo 3.0 is to better align with current day React, and do some spring cleaning on the codebase. This means:react-apollodeprecated API elementsThe current (non-deprecated)react-apolloAPI will stay the same, but this release will include breaking changes (mostly around dependencies). For example, use of >= React 16.8 will be required, and we're dropping Preact support.As we progress on this, the number of breaking changes are growing. The core functionality of the existing HOC and Component approaches is not changing however, and there will be a super easy migration path (that will likely only involve renaming your imports).