Electron 文档风格指南
这些是撰写 Electron 文档的指南。
标题
- 每页顶部必须有一个单独的
#级标题。 - 同一页面中的章节必须使用
##级标题。 - 子章节需要根据其嵌套深度增加标题中
#的数量。 - 页面标题必须遵循 APA 标题大小写。
- 所有章节都必须遵循 APA 句子大小写。
以 快速入门 为例
# 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 渲染器）。
- 所有
js和javascript代码块都使用 standard-markdown 进行 lint。 - 对于无序列表，请使用星号而不是连字符。
词语选择
- 描述结果时，使用“will”而不是“would”。
- 倾向于使用“in the ___ process”（在 ___ 过程中）而不是“on”（在）。
API 参考
以下规则仅适用于 API 的文档。
标题和描述
每个模块的 API 文档必须使用 require('electron') 返回的实际对象名称作为其标题（例如 BrowserWindow、autoUpdater 和 session）。
在页面标题正下方，将模块的单行描述添加为 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] ...”（一个 [属性类型] ...）开头
以 Session 和 Cookies 类为例
# 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 原语（例如 string、Promise 或 Object）、自定义 API 结构（如 Electron 的 Cookie）或通配符 any 来表示。
如果参数类型是 Array，请使用 [] 简写，并在方括号内注明数组中值的类型（例如 any[] 或 string[]）。
如果参数类型是 Promise，请用 Promise 解析的内容来参数化类型（例如 Promise<void> 或 Promise<string>）。
如果一个参数可以是多种类型，请用 | 分隔这些类型。
Function 类型参数的描述应清楚说明其调用方式，并列出将传递给它的参数的类型。
平台特定功能
如果某个参数或方法是特定于某些平台的，则这些平台使用空格分隔的斜体列表跟在数据类型后面进行表示。值可以是 macOS、Windows 或 Linux。
* `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 Schema（api-history.schema.json），您可以在 docs 文件夹中找到它。API 历史记录 Schema RFC 包含示例用法和每个 schema 方面的详细解释。
API 历史记录块的目的是描述 API 何时/何地/如何/为何被
- 添加
- 更改（通常是破坏性更改）
- 已弃用
块中列出的每项 API 更改都应包含指向该更改发生所在 PR 的链接，以及可选的简短更改描述。如果适用，请包含 标题 ID，该 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 的发布说明。
- 开发人员可以随时查看破坏性更改文档或链接的 pull request 以获取更多详细信息。
放置
通常，您应该将 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