Apollo Kotlin中关于isLast属性的深度解析与最佳实践

背景介绍

在Apollo Kotlin的响应处理机制中，ApolloResponse类包含一个名为isLast的属性，用于标识当前响应是否为数据流的最后一个元素。这个属性在4.x版本中的实际行为与文档描述存在差异，特别是在CacheAndNetwork策略下的表现值得深入探讨。

核心问题分析

原始文档中提到："例如，CacheAndNetwork获取策略在失败时不会发出网络项"。但在4.x版本的实现中，这个描述已不再准确。通过分析FetchPolicyInterceptors源码可以发现，该策略会先尝试从缓存读取，无论成功与否都会继续执行网络请求。

技术实现细节

在CacheAndNetwork策略下：

1. 首先尝试从缓存获取数据
2. 无论缓存是否命中，都会继续执行网络请求
3. 最终可能产生多个响应（缓存命中/未命中 + 网络结果）

这与早期版本的行为有显著不同，开发者需要注意这种变化对应用逻辑的影响。

实际应用场景

一个典型的使用场景是在UI渲染时避免"闪烁"现象。当使用CacheAndNetwork策略时：

1. 初始状态显示加载中
2. 若缓存未命中，可能先收到错误响应
3. 随后收到网络成功响应

通过检查isLast属性，开发者可以决定是否跳过中间的错误状态，直接等待最终结果。但需要注意，这种用法存在一定风险，因为：

• 某些自定义拦截器可能无法准确判断是否为最后一项
• 未来GraphQL特性（如@defer）可能影响最终判断

改进方案与最佳实践

核心开发团队建议采用更健壮的实现方式：

fun <D : Operation.Data> ApolloCall<D>.safeFlow(): Flow<Either<ApolloOperationError, D>> {
  return flow {
    var hasEmitted = false
    var errorResponse: ApolloResponse<D>? = null
    toFlow().collect { 
      if (it.exception != null) {
        errorResponse = it
      } else {
        hasEmitted = true
        emit(it)
      }
    }
    if (!hasEmitted) {
      errorResponse?.let { emit(it) }
    }
  }.map { either { parseResponse(it) } }
}

这种实现方式：

1. 不依赖容易出错的isLast属性
2. 仅在流结束时才考虑发出错误响应
3. 能正确处理各种获取策略下的响应序列

未来演进方向

Apollo Kotlin团队正在考虑完全弃用isLast属性，因为：

1. 其唯一内部用途是确保观察者在发出最终项前订阅存储
2. 维护正确的isLast状态实现较为复杂
3. 存在更优雅的替代方案

结论

对于Apollo Kotlin开发者，建议：

1. 避免直接依赖isLast属性实现关键逻辑
2. 采用基于流终止检测的替代方案
3. 关注未来版本中可能的相关API变更

通过理解响应流的本质行为而非依赖特定标记，可以构建更健壮、可维护的GraphQL客户端实现。