Provide better Jetpack Compose support

[martinbonnin]

Considerations

• With Jetpack compose getting more and more traction, should we offer better support of Jetpack Compose in our Kotlin client.
• With Jetpack compose getting more and more traction, should we move our tutorial to Jetpack Compose?
• Which existing users can we speak with who already are using Jetpack Compose with our Kotlin client, what has their experience been so far?

[sonatard]

With Jetpack compose getting more and more traction, should we move our tutorial to Jetpack Compose?

It sounds great.

Which existing users can we speak with who already are using Jetpack Compose with our Kotlin client, what has their experience been so far?

We created a declarative interface like apollo-web. because apollo-kotlin doesn't have it. It would be hard for all developers to do that. And not yet able to handle all the options of the Apollo web. I would be very happy if you could officially support a declarative interface like apollo web in apollo kotlin. And it would have a great impact on the spread of Jetpack Compose and GraphQL on Android.

context(ApolloClient)
@Composable
fun UserProfile() {
    val (data, loading, error) = apollo.query(q = UserProfileQuery())
    when {
        loading -> Spinner()
        error != null -> ErrorDialog(error = error)
        else -> Text(text = data.viewer.name)
    }
}

function UserProfile() {
  const { data, loading, error } = useQuery(UserProfileDocument);
  if (loading) {
    return <Spinner />;
  }
  if (error) {
    return <ErrorDialog error={error}/>;
  }
  return <div>data.viewer.name</div>;
};

If this can be achieved, Web and Android development will feel very close.

[BoD]

Thanks @sonatard for the feedback! This looks interesting!
The exact syntax for the Kotlin code would have to be a bit different, right? (I'm confused by the when there). Unless I'm missing something!

(The "Compose-ification" of the tutorial is in progress).

[sonatard]

@BoD

The exact syntax for the Kotlin code would have to be a bit different, right? (I'm confused by the when there). Unless I'm missing something!

What seems to be the difference when ? I didn't build it, so I could be wrong.

(The "Compose-ification" of the tutorial is apollographql/apollo-kotlin-tutorial#38).

👍

[BoD]

I think a possible syntax for what you suggest could resemble something like:

val result by apollo.query(q = UserProfileQuery())
when (result) {
    Loading -> Spinner()
    is Error -> ErrorDialog(error = result.error)
    is Data -> Text(text = result.data.viewer.name)
}

[sonatard]

I used this when expiression!

https://kotlinlang.org/docs/control-flow.html#when-expression

But Kotlin would be better represented by an algebraic data type with a sealed interface as you wrote 👍

[sonatard]

Hi. We are looking forward to the development of the Compose Extension. Let me introduce an option that we value when writing Jetpack Compose.

It is the skip option for useQuery. By using this, you can suppress the execution of the query without using Effect.
https://www.apollographql.com/docs/react/api/react/hooks/#params

In React, it is mentioned that using Effect recklessly can cause problems.

https://react.dev/learn/you-might-not-need-an-effect

We like that using the skip option allows us to write more declarative code.

// Effect version
val (fetch, data, loading, error) = apollo.lazyQuery<XXXQuery>()
LaunchedEffect(key1 = value) {
        if (value != null) {
            fetch(value)
        }
}

In our wrapper, using the skip option enables the following refactoring:

// skip version
val (data, loading, error) = apollo.query(skip = value == null, q = XXXQuery)

[martinbonnin]

@sonatard if the query is not executed, there still need to be an initial state right? Is it going to be loading? Something else?

[sonatard]

Our wrapper is if skip is true, data=null loading=false error=null. I think apollo-web behaves in the same way. But I haven't confirmed it.

[martinbonnin]

data=null loading=false error=null

Gotcha 👍 That's an interesting one as we're usually trying to model either data != null or error != null. Will need to let that sink in a bit but thanks for the feature request 👍

[sonatard]

@BoD @martinbonnin Thank you for releasing the Jetpack Compose support!

For mutations, we have prepared a wrapper like the following.
It is an interface aligned with Apollo Web's mutations.
https://www.apollographql.com/docs/react/data/mutations/

Is there any plan to support mutations? or should we implement this individually?

context(ApolloClient)
@Composable
fun FavoriteButton() {
    val (favoriteProductMutation, data, loading, error) = apollo.mutation<FavoriteProductMutation.Data>()
    when {
        error != null -> {
            ErrorDialog(error = error)
        }
        loading -> {
            Spinner()
        }
        else -> {
            Button(onClick = {
                favoriteProductMutation()
            }) {
                Text(text = "fav")
            }
        }
    }
}

[BoD]

Hi! This is interesting, thanks for sharing.

At the moment, the toState() that was introduced in compose-support can be used for mutations. It returns a nullable ApolloResponse which is initially null (loading), and has .exception and .errors for the error cases, as well as .data for the success case. So in essence it is similar to what you describe (minus the destructuring syntax).

The interesting difference is the returned lambda that executes the mutation. Not 100% sure about this one, the pattern is a bit unfamiliar to me (wondering if maybe it's a common JS pattern). In toState() the call executes the operation immediately. But in your example this looks useful indeed.

That's good food for thoughts!

In the meantime, if you are starting to use the compose-support, feedback is very welcome!