🧹 4.0 cleanups

[martinbonnin]

This is a list of changes that we can't do right now but should do in the next major release. This list is mostly a braindump and is missing a lot of context. This is not about new features but rather a list of small cleanups to do.

If you see anything that doesn't make any sense, it's probably because it doesn't. Feel free to comment and we'll dive into it.

Potential Breaking Changes/cleanups

• Remove suspend from the ApolloStore APIs Offer a non-suspend version
• Validation of operation directives Enforce validation of operation directives #4518
• Switch jvm-defaults to "all" (thus requiring Java8, which we require already anyways)
• Remove antlr
• move deferredMergedFragments and variables outside of CustomScalarAdapter
• Make apollo-ast's com.apollographql.apollo3.ast.introspection.* classes non public to reduce the API surface (including the json serializers) as they are probably not useful to end-users
• Enable KDoc again
• Add schemaPackageName/packageName to the Gradle configuration.
• ApolloCall execute / toFlow / exception handling improvements
• introduce HasDirective interface
• Rename dispose to close and implement okio.Closeable on NetworkTransport, HttpEngine, ApolloStore - That makes it difficult as it is a breaking change to add methods on interfaces.
• Remove Fragment.readDataFromCache
• Capitalize the generated class name for enums, to be consistent with other generated types
• Validate operation directives [Compiler] Validate operation directives #2673
• Deprecate ApolloCompositeException with Error level and use suppressed exceptions instead
• Make ApolloMetadata internal (it's ultimately not internal because needed by plugins)
• Enforce opt-in the kotlin_labs linking
• Rename Foo.type to Foo.__type to avoid nameclashes (or just leave it like this because we can detect the case. See 'type' is a reserved enum value name #4293)
• Rewrite the buffered adapters to not use JsonReader anymore
• Cleanup the JsonReader API and distinguish between the buffer/non buffered case.
• Generate the customScalarAdapters?
• Make the field merging validation more strict (see Add a flag to disable fieldsCanMerge validation on disjoint types #4342 (review))
• Use scalar instead of customScalar API cleanup: use "scalar" instead of "custom scalar" #3815
• Refactor shapes()
• Move httpInfo and others outside of executionContext
• Improve the Java ergonomics of HttpKt
• (To be considered): pass the variant name to the lambda for createAllAndroidVariantServices (see this comment) (or deprecate the function?)
• Rename WsProtocol.Factory to WsProtocol.Builder
• Remove IdlingResource. See this comment from OkHttp for instance, and this article about how to avoid them with Compose.
• Remove circular dependencies between Gradle projects
• extract HttpEngine and WebSocketEngine to a common module
• Remove our own runTest
• Remove Gradle defaultService

[eduardb]

Just saw this, and "Remove Fragment.readDataFromCache" from the list grabbed my attention. Would this also imply removing ApolloStore.readFragment()? I am interested in this because our app relies heavily on being able to query for fragments from the store (and watch them, but that's its own can of worms 😁). Thanks!

[martinbonnin]

It's a technicality mostly. Fragment.readDataFromCache will be removed but all the functionality will be exposed as Executable.readDataFromCache. If you take a look at the source, both of them are present already, but one is deprecated because not really needed.
AFAIK, it should be source compatible so you shouldn't need to change anything.

[dsvensson]

Is there any target date for when 4.0 is to be released?

[BoD]

@dsvensson Our current target is this month. We recommend you start looking at the latest beta if you haven't done so yet, feedback is super appreciated!

[bignimbus]

As we are in the RC stage for 4.0, we're going to close this and open a different Issue with just the "unchecked" items 🚀

[github-actions]

Do you have any feedback for the maintainers? Please tell us by taking a one-minute survey. Your responses will help us understand Apollo Kotlin usage and allow us to serve you better.