本文描述的主题会随着 SDK 的演进而修订。

JavaScript SDK 已经有超过 5 年的历史了。在这期间，开发者的使用场景与生态有了翻天覆地的变化。面对变化，我们做对了一些改进，也仍然有很多问题需要解决。

总结起来，现阶段，JavaScript SDK 提供的价值，也就是我们优先考虑的事项是：

• 让开发者更轻松的接入我们的服务：
  • 支持更多的主流运行环境，保证平台间以及与其他平台 SDK 的一致性。
  • 对复杂功能的封装，尤其是 File、第三方登录、LiveQuery 这些 Rest API 抽象比较简单客户端逻辑重的功能。
• 良好的开发体验：
  • 符合直觉与社区习惯的 API 与用法。
  • 完善的 API 文档与智能提示，与其他工具的集成。
  • 提供对开发者与技术支持有帮助的异常，方便的 debug 方案。
• 通过设计或封装帮助开发者避免一些可能的问题。

在接下来的一段时间里，我们要解决下面这些问题：

「离线可用」是 Progress Web App 非常重要的特性之一。我们计划探索如何支持离线应用的各种常见需求。第一步我们会尝试支持浏览器中对数据离线的读、写与查询的支持。

我们收到很多用户在客户端或云引擎中同时访问两个 LeanCloud app 的数据的需求。现在基于 namespace 的模块化实现方式让这个特性很难实现。

SDK 目前已经支持了浏览器（包括了Electron/CocosCreator/Egret/Laya）、Node.js（包括了Electron）、微信小程序/小游戏、React Native 等运行环境。

随着各个「小程序」与跨平台方案的全面开花，我们收到了更多的平台支持的反馈。因此我们计划对目前多平台支持的实现方式进行重构，让兼容更多平台的变的更加标准化，更加容易。

目前 SDK 的定义文件是单独维护的，我们经常会收到 TypeScript 用户关于定义错误或者不精确的反馈。SDK 本身有很多 bug 也是通过引用类型系统能在开发阶段避免的。因此我们计划将 SDK 迁移到 TypeScript。

在小程序与 React Native 环境（尤其是真机）中调试SDK 的问题一直非常困难。我们计划在「重构多平台支持实现方式」的基础上调查可能的解决方案。

在过去的几年里，JavaScript SDK 的演进一直以一种堆积木加打补丁的方式来进行的。一方面越来越多的功能的加入让代码量变大，哪怕你只需要使用最基本的数据存储功能你也需要同时加载 File、Leaderboard 的代码。另一方面出于向前兼容的考量我们很少移除功能，因此依然存在大量的兼容性代码。

代码的体积直接影响浏览器中的页面加载时间，v4.0.0 SDK 的 av-min.js 的体积相比 v1.0.0 增加了 50%。我们会分两个方向来解决上面的问题：

• 提供 ES module 引入方式。 目前主流的工具对于基于 ES module 的 tree shaking 的支持已经成熟。这将允许开发者只打包用到的模块。
• 移除 legacy/非核心 功能。 包括但不限于内置的 Promise polyfill，Backbone 对象兼容，Object 的 validate 机制等。

我们会在不引入不兼容改动的前提下对目前多平台支持的实现方式进行重构，将平台差异的部分抽象为依赖并提供配置的能力，从而支持各类已知或未知的运行环境。

在这个版本中，我们会完成以下变动：

• 迁移到 TypeScript。
• 将核心模块与功能模块拆分。在此基础上：
  • 支持多应用。
  • 提供 ES module 形式的模块。
• 移除 legacy/非核心 功能。

因为涉及到整个代码结构的重构，v4.x 中的很多可访问的内部 API 以及未定义的行为可能会发生变化。我们会在 v5.0 发布之后继续维护 v4.x 一年（严重的 bug 修复与安全更新）。

在 v5.0 发布之后，我们会着手「离线支持」的开发。我们目前还没有办法评估「离线支持」功能可能会对 API 产生的影响，如果我们不得不引入不向前兼容的 API 改动，这个功能将会发布为 v6，并且停止 v5.x 的维护（v4.x 的维护不受影响）。