Describing upgrade to 2.0 from 1.x as simple or quick is not always accurate

[elmarsto]

I've recently had to upgrade from 1.2.x to 2.0 and the documentation suggests this is a quick change. While I profoundly appreciate all the hard work that has gone into this product, I also can't help but notice this description of the upgrade path is (sometimes) misleading. It can be a real toothpull if:

• You make extensive use of third-party middleware, which must either now be hacked into the chain or discarded
• You (like most folks) use React Storybook with the Apollo add-on, which no longer works [although that is clearly a matter I'll be bringing up with them instead of here! Still: workflow is significantly disrupted]
• You make use of mockNetworkInterface from apollo-test-utils (which itself seems unable to upgrade?)
• You have a bunch of custom mocking-related code
• You integrated with Redux, and used that integration for more than just logging

At minimum, one has to work through (in my case, hundreds) of files, altering them such that gql is imported from graphql-tag instead of react-apollo.

Not unrelatedly: AFAICT, literally half a dozen new packages to manage in package.json. I appreciate the Reasons of Modularity which motivated this move, but, as above, there is a lot of reworking that has to be done, especially on large projects.

Can't wait to see where we go with 2.0. On continue -- but also, let's not minimize the scope of the upgrade. My whole workday just got sunk into this.

[Panoplos]

Agree. This was not a trivial upgrade. I have a special network interface that uses Socket Cluster that required a complete rewrite around Link, and the docs did not help at all with this. I had to look at the default implementations' code for guides.

Also, discarding Redux has introduced several new issues with race conditions that are hard to debug due to lack of visibility in the form of state-change logging. This is the entire reason we use Redux, and it is now completely gone. (For instance, I perform a reset on the cache in a redux post-reducer logic when a user logs out, which immediately propogates react updates down the component stack before Redux has a chance to update, where before this would have been queued in the Redux event manager behind the updated account login status.)

I am also noticing that query responses are slightly slower and there is a debounce issue with loading being set to false when no data is present...

[jbaxleyiii]

@liz-mars I'm so sorry to hear the upgrade path wasn't as easy as I hoped it would be for you. Part of the language around the upgrade was formed by the fact that nearly all application usage would stay the same. This certainly didn't take into account third party libraries into account which should have been considered and noted.

With that being said, I hope a single workday of upgrade will prove to be worth it as we continue to make AC smaller, faster, and more powerful with the 2.0 line.

@Panoplos sorry to hear about your experience as well! What can we document better to help with this and others who may run into it?

If either of you would like to add some comments to the redux integration issue please do! I'd love to know what is missing now and how we can provide it!