跳转到主要内容

Electron 文档风格指南

这是撰写 Electron 文档的指南。

标题

  • 每页顶部必须有一个 # 级别的标题。
  • 同一页面内的章节必须使用 ## 级别的标题。
  • 子章节需要根据嵌套深度增加标题中的 # 数量。
  • 页面标题必须遵循 APA 标题大写规则
  • 所有章节必须遵循 APA 句子大写规则

Quick Start 为例

# Quick Start

...

## Main process

...

## Renderer process

...

## Run your app

...

### Run as a distribution

...

### Manually downloaded Electron binary

...

对于 API 参考,此规则有例外。

Markdown 规则

此存储库使用 markdownlint 包来强制执行一致的 Markdown 样式。有关具体规则,请参阅根目录中的 .markdownlint.json 文件。

有几条风格指南未包含在 linter 规则中

  • 在代码块中,请使用 sh 而不是 cmd(因为语法高亮器)。
  • 为了提高可读性,请尽量将行长度保持在 80 到 100 个字符之间。
  • 列表嵌套层数不要超过 2 层(由于 markdown 渲染器的限制)。
  • 所有 jsjavascript 代码块均使用 standard-markdown 进行 lint。
  • 无序列表请使用星号 (*) 而非连字符 (-)。

词语选择

  • 描述结果时,请使用“will”(将)而非“would”(会)。
  • 优先使用“in the ___ process”(在 ___ 过程中)而非“on”。

API 参考

以下规则仅适用于 API 文档。

标题和描述

每个模块的 API 文档必须使用 require('electron') 返回的实际对象名称作为标题(例如 BrowserWindowautoUpdatersession)。

在页面标题正下方,添加对该模块的单行描述,格式为 Markdown 引用(以 > 开头)。

session 模块为例

# session

> Manage browser sessions, cookies, cache, proxy settings, etc.

模块方法和事件

对于非类模块,其方法和事件必须列在 ## Methods## Events 章节下。

autoUpdater 为例

# autoUpdater

## Events

### Event: 'error'

## Methods

### `autoUpdater.setFeedURL(url[, requestHeaders])`

  • API 类或作为模块一部分的类必须列在 ## Class: TheClassName 章节下。
  • 一个页面可以包含多个类。
  • 构造函数必须使用 ### 级别的标题列出。
  • 静态方法必须列在 ### Static Methods 章节下。
  • 实例方法必须列在 ### Instance Methods 章节下。
  • 所有有返回值的方法,其描述必须以“Returns [TYPE] - [Return description]”(返回 [类型] - [返回值描述])开头。
    • 如果方法返回一个 Object,其结构可以使用冒号后跟换行符,然后使用与函数参数相同的样式列出属性的无序列表来指定。
  • 实例事件必须列在 ### Instance Events 章节下。
  • 实例属性必须列在 ### Instance Properties 章节下。
    • 实例属性必须以“A [Property Type] ...”(一个 [属性类型] ...)开头。

SessionCookies 类为例

# session

## Methods

### session.fromPartition(partition)

## Static Properties

### session.defaultSession

## Class: Session

### Instance Events

#### Event: 'will-download'

### Instance Methods

#### `ses.getCacheSize()`

### Instance Properties

#### `ses.cookies`

## Class: Cookies

### Instance Methods

#### `cookies.get(filter, callback)`

方法及其参数

方法章节必须遵循以下格式

### `objectName.methodName(required[, optional]))`

* `required` string - A parameter description.
* `optional` Integer (optional) - Another parameter description.

...

标题级别

标题可以是 ####### 级别,具体取决于方法属于模块还是类。

函数签名

对于模块,objectName 是模块的名称。对于类,它必须是该类实例的名称,并且不得与模块的名称相同。

例如,session 模块下的 Session 类的这些方法必须使用 ses 作为 objectName

可选参数用方括号 [] 括起来表示,如果此可选参数跟在另一个参数之后,则还需要包含表示必需逗号的逗号。

required[, optional]

参数描述

有关每个参数的更详细信息将在方法下方的无序列表中说明。参数类型表示为 JavaScript 原生类型(例如 stringPromiseObject)、自定义 API 结构,例如 Electron 的 Cookie,或通配符 any

如果参数类型为 Array,请使用 [] 简写,并在其中包含数组元素的类型(例如 any[]string[])。

如果参数类型为 Promise,请使用参数化类型指定 Promise 的解析值(例如 Promise<void>Promise<string>)。

如果参数可以是多种类型,请用 | 分隔这些类型。

Function 类型参数的描述应清楚说明其调用方式,并列出将传递给它的参数的类型。

平台特定的功能

如果某个参数或方法是特定于某个平台的,则这些平台使用空格分隔的斜体列表跟在数据类型之后进行标识。值可以是 macOSWindowsLinux

* `animate` boolean (optional) _macOS_ _Windows_ - Animate the thing.

事件

事件章节必须遵循以下格式

### Event: 'wake-up'

Returns:

* `time` string

...

标题可以是 ####### 级别,具体取决于事件属于模块还是类。

事件的参数遵循与方法相同的规则。

属性

属性章节必须遵循以下格式

### session.defaultSession

...

标题可以是 ####### 级别,具体取决于属性属于模块还是类。

API 历史

“API 历史”块是封装在 HTML 注释中的 YAML 代码块,应直接放在类或方法的 Markdown 标头之后,如下所示

#### `win.setTrafficLightPosition(position)` _macOS_

<!--
```YAML history
added:
- pr-url: https://github.com/electron/electron/pull/22533
changes:
- pr-url: https://github.com/electron/electron/pull/26789
description: "Made `trafficLightPosition` option work for `customButtonOnHover` window."
deprecated:
- pr-url: https://github.com/electron/electron/pull/37094
breaking-changes-header: deprecated-browserwindowsettrafficlightpositionposition
```
-->

* `position` [Point](structures/point.md)

Set a custom position for the traffic light buttons. Can only be used with `titleBarStyle` set to `hidden`.

它应遵循 API 历史 JSON Schemaapi-history.schema.json),您可以在 docs 文件夹中找到它。 API 历史 Schema RFC 包含示例用法和每个 Schema 部分的详细说明。

API 历史块的目的是描述 API 何时/何地/如何/为何被

  • 添加
  • 更改(通常是重大更改)
  • 已弃用

块中列出的每个 API 更改都应包含指向该更改 PR 的链接,以及可选的更改简短描述。如果适用,请包含 标题 ID重大更改文档中。

API 历史 lint 脚本lint:api-history)会根据 Schema 验证 Electron 文档中的 API 历史块,并执行一些其他检查。您可以查看其 测试以获取更多详细信息。

有几条风格指南未包含在 lint 脚本中

格式

始终遵循此格式

API HEADER                  |  #### `win.flashFrame(flag)`
BLANK LINE |
HTML COMMENT OPENING TAG | <!--
API HISTORY OPENING TAG | ```YAML history
API HISTORY | added:
| - pr-url: https://github.com/electron/electron/pull/22533
API HISTORY CLOSING TAG | ```
HTML COMMENT CLOSING TAG | -->
BLANK LINE |

YAML

  • 使用两个空格进行缩进。
  • 不要使用注释。

描述

  • 始终将描述用双引号括起来(例如“example”)。
  • 以与应用程序开发者相关的方式描述更改,并使其大写、带标点符号且为过去时。
    • 有关示例,请参阅 Clerk
  • 保持描述简洁。
    • 理想情况下,描述应与其在重大更改文档中的相应标题匹配。
    • 尽可能优先使用相关 PR 的发布说明。
    • 开发人员始终可以查看重大更改文档或链接的拉取请求以获取更多详细信息。

位置

通常,您应将 API 历史块直接放在类或方法的 Markdown 标头之后。但是,在某些情况下,这会存在歧义

Chromium 升级

有时,重大更改与任何现有 API 都无关。在这种情况下,不添加 API 历史也是可以的。

影响多个 API 的更改

有时,重大更改会涉及多个 API。在这种情况下,请将 API 历史块放在涉及的每个 API 的顶级 Markdown 标头下。

# contextBridge

<!--
```YAML history
changes:
- pr-url: https://github.com/electron/electron/pull/40330
description: "`ipcRenderer` can no longer be sent over the `contextBridge`"
breaking-changes-header: behavior-changed-ipcrenderer-can-no-longer-be-sent-over-the-contextbridge
```
-->

> Create a safe, bi-directional, synchronous bridge across isolated contexts
# ipcRenderer

<!--
```YAML history
changes:
- pr-url: https://github.com/electron/electron/pull/40330
description: "`ipcRenderer` can no longer be sent over the `contextBridge`"
breaking-changes-header: behavior-changed-ipcrenderer-can-no-longer-be-sent-over-the-contextbridge
```
-->

Process: [Renderer](../glossary.md#renderer-process)

请注意,没有在以下位置添加 API 历史块

  • contextBridge.exposeInMainWorld(apiKey, api)

因为该函数未被更改,只改变了它的使用方式

  contextBridge.exposeInMainWorld('app', {
- ipcRenderer,
+ onEvent: (cb) => ipcRenderer.on('foo', (e, ...args) => cb(args))
})

文档翻译

请参阅 electron/i18n