跳过主要内容
移动 Capacitor

TypeScript API 示例:Capacitor 和 Capgo

探索 TypeScript API 的实用示例,了解 Capacitor 插件和 Capgo 更新的使用方法,掌握类型化接口、监听模式和实现策略。

TypeScript API 示例:Capacitor 和 Capgo

每个坚实的 TypeScript API 示例 每个TypeScript Capacitor示例都以相同的方式开始:使用类型化的插件接口。明确说明方法、选项和Promise结果,并且Web code和原生层共享一个约束,TypeScript实际上会强制执行。

目录

构建强类型Capacitor插件接口

该接口描述了API你的网页code看到的内容。

import { registerPlugin } from ‘@capacitor/core’;

export interface DeviceStatus { 在线: boolean; 电量?: number; }

export interface DevicePlugin {\ngetStatus(): Promise};\nsetLabel(options: { label: string }): Promise<{ saved: boolean }>;\n}

export const Device = registerPlugin(‘Device’);

那些几行代码中有很多东西:

  • 明确的返回类型 让每个结果都可预测。
  • 类型化的选项对象 在编译时捕获缺失或拼写错误的属性。
  • 基于 Promise 的方法 模型本地工作完成异步。
  • 一个通用 registerPlugin 调用 连接 Web API 到本地桥梁的就是它。
  • 接口 文档合同而不增加一个字节的运行时 code。

每个调用站点都得到相同的处理:

const status = await Device.getStatus(); console.log(status.online);

await Device.setLabel({ label: ‘生产环境’ });

替换 { label: 'Production' } 代替 { name: 'Production' } 并且编译器会立即标记它。那样比在手机发布后才发现不匹配要好得多。

接口也是您建模可选值和失败案例的地方。如果一个本机方法不能始终产生电池读数, batteryLevel?: number 告诉每个调用者处理 undefined.

下图展示了类型方法、选项、返回值、桥接定义和编译时检查在一个 Capacitor API 内部如何连接。

一个图表,说明强类型 TypeScript 插件接口的关键优势在于移动开发框架。

核心思想: 类型定义从 web 面向接口流向本机平台逻辑,并且编译时检查在每个调用点都保持警惕。

快速查找 API 设计

元素 目的 Example
方法签名 定义可调用的行为 getStatus()
选项类型 控制输入形状 { label: string }
Promise结果 表示异步工作 Promise<DeviceStatus>
结果接口 定义返回数据 online: boolean

为了更深入的参考,请阅读关于在TypeScript中构建API的指南 . 两种值得保留的习惯:在客户端中排除机密和签名凭证,测试接口在发布之前与每个平台的实现进行交互移动团队同时处理JavaScript、原生code、设备权限和异步平台服务。一个

code 强制 TypeScript 合约 在这些边界上起作用的强制性 TypeScript 合约,类似于共享的检查清单,明确了期望在任何 code 到达 iOS 或 Android 设备之前

一位人正在桌子旁边的笔记本电脑上编码,显示着code,旁边有一个咖啡杯。

一个具体的 TypeScript API 示例, 比较一个返回 Promise<DeviceStatus> 的方法与一个返回

的方法。类型化的版本告诉编辑器和每个审阅者哪些字段存在。未类型化的版本将该发现工作推送到运行时日志、手动测试和最坏情况下,生产事故。

采用信号 TypeScript 已经超出了其前端领域。采用率攀升到35% 的开发者在 2024 年 12% 在 2017 年,和超过 有超过一百万名GitHub贡献者 将其列为2025年主要语言。深入了解TypeScript采用情况的全部发现 如果您想要原始数字。 这条轨迹对移动组织在实际方面有重要意义。招聘、入职和__CAPGO_KEEP_0__审查越来越围绕共享类型进行。加入一个__CAPGO_KEEP_1__项目的人可以阅读一个接口并了解预期的本机行为,而无需跟踪每个实现细节。

That trajectory matters for mobile organizations in practical ways. Hiring, onboarding, and code review increasingly revolve around shared types. Someone joining a Capacitor project can read an interface and understand the expected native behavior without tracing through every implementation.

强类型转移了关键的反馈

,当修复只需要几分钟,而不是紧急发布修复时。对__CAPGO_KEEP_0__团队的好处

跨平台应用通常暴露一个面向Web的Capacitor,它位于几个本机实现之上。TypeScript无法证明每个本机细节都行为一致,但它可以保持您的所有调用在整个应用程序中一致。

Cross-platform apps typically expose one web-facing API that sits on top of several native implementations. TypeScript cannot prove every native detail behaves identically, but it can keep your calls consistent across the entire application.

,和超过

  • 方法输入, 包括必填和可选选项
  • Promise结果, 所以成功数据总是有可预测的形状
  • 事件和监听器, 所以回调函数处理已知的载荷
  • 错误和状态值, 所以fallback路径保持可见

这种结构在集成设备插件或操作服务时会产生回报。它还会帮助团队审查更新自动化,避免由于错误的频道、包标识符或兼容性字段而对大规模用户造成的影响。

为了更深入地了解相关模式,请阅读 我们关于使用OpenAPI生成类型API的指南. It covers how shared definitions reduce the manual drift that normally creeps in between API documentation and application code.

做出商业案例

Strict typing does ask for some upfront investment, especially when older JavaScript code carries inconsistent data shapes. The return shows up over time: smaller refactors, clearer ownership, and far fewer integration surprises.

从风险最大的边界开始:

  1. 定义本地和远程调用的响应接口。
  2. 类型化选项对象和事件负载。
  3. 逐步开启严格编译检查。
  4. 在发布任何更新之前,要求类型检查。

对于企业移动团队来说,这个基础使得在各个平台、发布版本和贡献者之间的维护变得可预测。

Capacitor的ScreenOrientationPlugin是一个很好的 TypeScript API示例 因为它将少量简单的Web方法映射到平台特定的设备行为。公共契约在各个平台上保持一致,而iOS和Android各自处理自己的本地细节。

import { registerPlugin } from ‘@capacitor/core’;

export 类型 OrientationType = | ‘portrait-primary’ | ‘portrait-secondary’ | ‘landscape-primary’ | ‘landscape-secondary’;

export interface OrientationData { type: OrientationType; 角度: number; }

export interface LockOptions { orientation: OrientationType; }

export interface ScreenOrientationPlugin { orientation(): Promise}; lock(options: LockOptions): Promise}; unlock(): Promise}; addListener( eventName: ‘screenOrientationChange’, listenerFunc: (data: OrientationData) =&gt; void, ): Promise&lt;{ remove: () =&gt; Promise} }&gt;; }

export const ScreenOrientation =\n注册插件(‘ScreenOrientation’);

每个签名的快速参考如下:

  • orientation() —异步读取当前方向
  • lock() —— 只接受已知的方向值
  • unlock() —— 将控制权还给正常的设备行为
  • addListener() —— 在方向发生变化时,会触发一个类型化的载荷

由于每个方法都返回一个 Promise,因此您可以使用相同的调用模式对 native 桥和浏览器实现进行调用。无需分支,特殊情况也不需要。

const current = await ScreenOrientation.orientation();

if (current.type.startsWith('landscape')) { console.logAngle: ${current.angle}); }

await ScreenOrientation.lock({orientation: '横屏',});

输入一个拼写错误的值,如 landscape-main 并且编译时就会失败。您可以在几秒钟内修复它 —— 不需要在设备日志中追踪平台特定的运行时错误。

正确输入监听器参数

监听器应享受相同的严格性,如普通方法。避免 any 因为它会隐藏事件载荷和结果之间的区别 orientation() 简化中文

/zh/blog/typescript-api-example/

Live Update

Cloudflare

Capacitor OrientationData GitHub angleCapgo undefined.

code API
SDK CLI
npm Explicit Promise 类型
事件 事件名称
清理 返回可移除的订阅

桥接合约是接口,而不是原生实现。 保持小、可预测和可测试。

有关平台行为、权限和安装步骤,请参阅 Capacitor 屏幕方向插件指南. 在严格的 TypeScript 设置下测试有效调用和拒绝调用是一种值得培养的习惯。这种组合在包装移动应用之前捕捉错误的方法名称、缺失的字段和不兼容的监听器负载。

Capgo 为 Capacitor 团队提供了推送 JavaScript、CSS、配置和资产修复的方式,而无需等待应用商店审查。关键在于将其更新管道视为任何其他类型的 API 边界,例如通道、回滚规则、兼容性检查和回滚决策都保持明确,直到包裹到用户设备之前。

一位手持智能手机的人,展示了横屏和竖屏屏幕方向模式之间的差异。

定义更新协议

首先确定您的自动化接受的值。字面联合可以防止您意外部署到错误的频道,接口使bundle与其所需的原生版本之间的关系自我文档化。

类型 Channel = ‘beta’ | ‘staging’ | ‘production’;

interface UpdateRequest { channel: Channel; bundleVersion: string; minNativeVersion: string; rolloutPercent: number; signed: boolean; }

interface UpdateResult { accepted: boolean; appliedOnNextLaunch: boolean; rollbackEnabled: boolean; }

一个简单的 TypeScript API 示例 验证请求之前将其传递给 Capgo 客户端:

async function publishUpdate( request: UpdateRequest, ): Promise { if (!request.signed || request.rolloutPercent &lt; 0 || request.rolloutPercent &gt; 100) { throw new Error(‘不安全的更新请求’); }

return capgo.publish(request);

具体的客户端方法名称在 Capgo SDK 版本之间发生变化,因此将其包装在自己的接口后。这种隔离在每次升级时都会发挥作用,并且防止了供应商特定细节在代码库中泄露。

保护频道和兼容性

选择频道不应随意。生产发布需要比实验性beta版本更严格的检查,尤其是当web包调用native能力时,这些能力在早期app版本中不存在。

function 可以部署(\nrequest: UpdateRequest,\ninstalledNativeVersion: string,\n): boolean {\nreturn request.signed &amp;&amp;\ninstalledNativeVersion &gt;= request.minNativeVersion;\n}

不要用平常的字符串来比较版本。引入一个合适的语义版本库以 1.10.0 排序后 1.9.0在任何频道发布之前,需要进行检查:

  1. 确认包是签名的。
  2. 验证目标频道与意图相符。
  3. 比较native和bundle兼容性范围。
  4. 首先发布给受限的受众。
  5. 监控失败信号并保持回滚准备就绪。

一个类型化的更新管道将发布策略转化为code,让审查者和CI可以实际检查。

Capgo的差异性交付和频道控制很好地融入了该模式,且其设备级可观察性使团队能够在事后追踪采用或失败信号。有关事件仪表板的另一方面,请参见 Capgo的自定义事件跟踪指南.

签名密钥和管理员凭据应放在服务器或CI系统,而不是在已发布的应用程序中。下次启动时应用更新,测试回滚使用故意拒绝的包,并以类型化结果记录每个决策。这种结合保持了快速交付与有条不紊的移动发布控制兼容。

类型化监听器使异步API变得容易信任。无论回调跟踪屏幕方向还是Capgo更新事件,它都应在每个平台上接收相同的payload形状——并且编译器应负责强制执行。

interface UpdateEvent { version: string; channel: 'beta' | 'production'; available: boolean; }

类型 Listener = (payload: T) =&gt; void;

interface UpdateService { addListener( event: ‘updateAvailable’, callback: Listener }, ): Promise&lt;{ remove: () =&gt; Promise} }&gt;;\nremoveAllListeners(): Promise; }

此 TypeScript API示例 将事件名称固定到一个literal,并将回调函数绑定到一个类型化的payload。您的编辑器可以自动完成 version 免费提供,并且编译器会拒绝任何期望的数据不相关的回调函数。它的设置很小,但每次API发生变化时都会有回报

想亲眼看看吗?看看教程:

安全注册监听器

在组件内部,保持订阅句柄的引用,以便清除时保持明确。同样的模式可以在Angular生命周期钩子、React效果和Vue挂载钩子中使用,甚至不需要任何修改

let orientationHandle: { remove: () =&gt; Promise} } | undefined;

async function start() { orientationHandle = await ScreenOrientation.addListener( ‘screenOrientationChange’, ({ type, angle }) => { console.log(type, angle); }, ); }

async function stop() { await orientationHandle?.remove(); orientationHandle = undefined; }

当屏幕消失时运行清除操作,不仅仅是当整个应用关闭时。忽略它,导航会将回调函数留在native事件源上。这样会导致重复工作和过时的状态更新,很难追踪

每个框架都给你一个钩子

  • Angular —— 从中清除 ngOnDestroy
  • React —— 从中返回一个异步安全的清除函数 useEffect
  • Vue —— 移除订阅 onBeforeUnmount

每 addListener 每次调用都应有一个匹配的移除路径。

选择合适的清除方法

当一个组件拥有一个订阅时,返回的句柄是正确的调用。 removeAllListeners() 当一个服务持有多个监听器并且正在被完全重置时,

async function resetUpdates(service: UpdateService) { await service.removeAllListeners(); }

不要从共享组件中触发广泛方法,而其他屏幕仍然依赖于该服务。 当拥有权是本地的,应坚持使用单独的 remove() 处理.

情况 建议行动
一个组件订阅 调用 handle.remove()
context: Appflow 迁移步骤2 调用 removeAllListeners()
服务关闭 重复注册
守卫初始化 未知载荷

在使用之前验证。对于 Capgo 通知,保持更新载荷与设备事件分开。然后在单独测试注册、传递和清理 — Capgo 个性化事件跟踪指南 有关集成方面的更多信息。

在发布之前,检查以下三点:卸载确实移除了处理程序,拒绝的承诺被捕获,且没有回调可以更新被销毁的组件。这种纪律使得反应性 Capacitor 应用程序在 Angular、React 和 Vue 中保持响应式。

一名专业的软件开发人员在双屏幕设置中工作,同时戴着耳机,正在处理 code。

一个经过精心构建的 TypeScript API 示例 以意图描述的名称开始。使用动词作为方法,名词作为接口,并坚持一致的后缀,如 Options, Result,和 Event。清晰的名称可以减少入职时间,因为开发人员可以在不打开实现的情况下理解契约。

保持公共接口小。通过专注的方法暴露能力,而不是将松散相关的操作dump到一个单独的对象上。

  • getStatus() 读取状态。
  • updateConfig(options) 更改配置。
  • addListener(event, callback) 订阅变化。

精确控制输入输出类型。

当参数可能会增长时,使用命名选项接口:

interface 发布选项 { channel: ‘beta’ | ‘production’; rolloutPercent: number; }

interface PublishResult { 版本:string; 是否接受:boolean; }

async function publish( options: PublishOptions, ): Promise {\nreturn client.publish(options);\n}

泛型在API包裹不同载荷时,需要保留其特定类型时才有用:

interface ApiResponse {\ndata: T;\nrequestId: string;\n}

async 函数请求(path: string): Promise&lt;ApiResponse>&gt; { return fetchJson&lt;ApiResponse&gt;(path); }但不要仅仅为了看起来灵活而添加泛型。泛型应该表达输入和输出之间的真实关系 —— 否则,一个具体的接口更容易阅读和维护。

使无效状态难以表示

特别是在原生、网络和更新边界处。在合同旁边记录行为。涵盖权限、单位、拒绝的承诺、可选字段以及方法是否立即应用还是在下一次启动时应用。内联注释应该解释决策,而不是重复方法名称。

组织__CAPGO_KEEP_0__的变化

重新组织Code以适应变化

关注点

推荐位置 公共接口
__CAPGO_KEEP_0__方法 types.ts
API client.ts
原生适配器 platform/
兼容性测试 tests/

对于破坏性插件更改,引入新的主要接口或兼容层,暂时保留过时的方法,并记录迁移步骤。 了解更多关于API版本策略 context: Capgo营销网站。角色:短UI标签或导航项。见于:组件比较/ComparisonPage.astro。消息键`compare_rank_link_aria`(比较rank链接aria)。

Run strict type checks and contract tests in CI before shipping. For Capgo workflows, verify channel values, native compatibility, signed bundles, and rollback behavior as typed release rules — this keeps fast updates under control as teams, platforms, and integrations grow.

如何处理动态原生结果?

如何用类型动态原生结果? any leak into your code when a native method hands back unpredictable data. Instead, spell out the fields you can count on, mark genuinely optional values with ?泄漏到你的__CAPGO_KEEP_0__中,当原生方法返回不可预测的数据时。相反,明确你可以依赖的字段,标记真正的可选值为,并在边界处对不确定的输入进行清洁处理,以便下游任何东西都不会接触它。

interface NativeResult { success: boolean; value?: string; }

异步函数 readValue(): Promise const result = await NativePlugin.read(); return { success: Boolean(result.success), value: typeof result.value === ‘string’ ? result.value : undefined, };

这项方法会让你的调用者安全地处理不确定性,通过在类型本身中明确表示不确定性。 在TypeScript中构建API.

如何避免未处理的拒绝?

异步回调函数需要通过设计来防御。将失败捕获在监听器内部,而不是依赖事件系统来静默地吞噬拒绝的承诺。

const handleUpdate = (event: UpdateEvent): void => { void applyUpdate(event).catch((error: unknown) => { console.error(‘Update failed’, error); }); };

保持订阅引用并在组件卸载时移除它。这样可以防止重复回调和过时的状态更新 —— 监听器生命周期部分详细介绍了这一点。

每个异步监听器都需要错误路径和清除路径。

如何保护Capgo更新?

签名密钥和管理凭证始终在你的服务器或CI系统上。客户端只应接收签名的包并使用类型化的结果显示状态 —— 但绝不用于创建签名。

在发布之前,设置单独的通道联合体,运行兼容性检查,配置滚动限制,并规划回滚路径。 Capgo 处理签名交付、渠道控制、下一版应用和回滚保护的Capacitor和Electron应用。他们的文档展示了如何通过类型化的发布流程来优化你的更新管道。

实时更新的Capacitor应用

当web层bug处于活跃状态时,通过Capgo将修复推送给用户,而不是等待几天的应用商店审批。用户在后台接收更新,而原生变化仍在正常审批路径中。

最新博客

Capgo为您提供创建真正专业的移动应用所需的最佳见解。