做者:周全css
社交魔方平台是京东的 SNS 活动搭建平台,其内置了不少模板,每个模板都有一个模板 JSON 用于生成表单,运营同窗、商家配置了这个表单后就能够生成活动页面了。 模板 JSON 是标准的结构化数据,包含名称、类型、控件类型、校验器、默认值等等字段。以往都是采用手写 JSON 的方式,这是很是低效的,并且容易出错。针对其结构化数据的特色能够用 GUI 的方式去编辑,咱们基于 Electron 参考 Github Desktop 客户端 的架构编写了一个 编辑器,经过填写表单的方式生成 JSON。因此在这里记录下这个 Electron 编辑器开发过程当中能够记录的点和从 Github Desktop 客户端代码中值得学习的点。html
Electron是由Github开发,用HTML,CSS和JavaScript来构建跨平台桌面应用程序的一个开源库。 Electron经过将Chromium和Node.js合并到同一个运行时环境中,并将其打包为Mac,Windows和Linux系统下的应用来实现这一目的。前端
上面是来自 Electron 官方的介绍。基于 Electron 平台,咱们可使用熟悉的前端技术栈来开发桌面应用。Electron 运行 package.json 的 main 脚本的进程被称为主进程(如下简称main)。 在主进程中运行的脚本经过建立 web 页面来展现用户界面(如下简称 renderer)。 一个 Electron 应用老是有且只有一个主进程。main 用于建立应用,建立浏览器窗口,它就是一个完全的 Node 进程,获取不到 DOM, BOM 这些接口。在 main 建立的浏览器窗口中运行的就是 renderer 进程,它既能够获取 DOM, BOM 这些接口,也可使用 Node 的 API。两类进程之间能够经过 Electron 提供的 IPC 接口通讯。node
咱们了解到 Electron 分为两类进程,main 和 renderer。因此搭建开发环境时不能像普通的前端应用同样一个 webpack 配置搞定。而且咱们想要实现react
那么就须要两个 webpack 配置文件。webpack
一个用于开发环境 -- webpack.dev.ts
。git
// webpack.dev.ts
const mainConfig = merge({}, base.mainConfig, config, {
watch: true
})
const rendererConfig = merge({}, base.rendererConfig, config, {
module: {
rules: [
{
test: /\.css$/,
use: ['style-loader', 'css-loader'],
},
{
test: /\.styl$/,
use: ['style-loader', 'css-loader', 'stylus-loader'],
}
]
},
devServer: {
contentBase: path.join(__dirname, base.outputDir),
port: 8000,
hot: true,
inline: true,
historyApiFallback: true,
writeToDisk: true
},
})
module.exports = [rendererConfig, mainConfig]
复制代码
另外一个用于生产环境 -- webpack.prod.ts
。github
const config: webpack.Configuration = {
mode: 'production',
devtool: 'source-map',
}
const mainConfig = merge({}, base.mainConfig, config)
const rendererConfig = merge({}, base.rendererConfig, config, {
module: {
rules: [
{
test: /\.css$/,
use: [MiniCssExtractPlugin.loader, 'css-loader'],
},
{
test: /\.styl$/,
use: [MiniCssExtractPlugin.loader, 'css-loader', 'stylus-loader'],
}
]
},
plugins: [
new MiniCssExtractPlugin({ filename: 'renderer.css' }),
new BundleAnalyzerPlugin({
analyzerMode: 'static',
openAnalyzer: false,
reportFilename: 'renderer.report.html',
}),
],
})
module.exports = [mainConfig, rendererConfig]
复制代码
这里参考了 Desktop 使用 Typescript 编写 webpack 配置文件。配合 interface 能够实现 webpack 配置文件的编辑器自动补全。具体使用方法可参考 webpack 文档 webpack.js.org/configurati…web
每个配置文件导出一个数组,分别是 main, renderer 的配置对象。sql
使用 webpack-dev-server 启动能实现 renderer 的热更新,main 则是使用 webpack 的 watch 模式。
{
"compile:dev": "webpack-dev-server --config scripts/webpack.dev.ts"
}
复制代码
使用 nodemon 监听 main 编译后的产物,nodemon 监听到改动则从新运行 electron .
重启应用,这样间接实现了 main 的 livereload。
Nodemon is a utility that will monitor for any changes in your source and automatically restart your server.
{
"app": "electron .",
"app:watch": "nodemon --watch 'dest/main.js' --exec npm run app",
}
复制代码
这样就实现了一键启动开发环境,且可以监听代码变化,从新启动应用。
Tips: 开源社区有更好的 electron-webpack, HMR for both renderer and main processes
生产环境则使用 webpack 顺序编译 main 和 renderer。编译完成后使用 electron-builder 打包。这样就实现了一键打包。
因为工具链的缺失实现不了一键发布,就只能打包后手动发布了(后面详细说明)。
下面就是完整的 scripts。
{
"scripts": {
"start": "run-p -c compile:dev typecheck:watch app:watch",
"dist": "npm run compile:prod && electron-builder build --win --mac",
"compile:dev": "webpack-dev-server --config scripts/webpack.dev.ts",
"compile:prod": "npm run clean && webpack --config scripts/webpack.prod.ts",
"app": "electron .",
"app:watch": "nodemon --watch 'dest/main.js' --exec npm run app",
"clean": "rimraf dest dist",
"typecheck": "tsc --noEmit",
"typecheck:watch": "tsc --noEmit --watch",
"lint": "eslint src --ext .ts,.js --fix",
"release:patch": "standard-version --release-as patch && git push --follow-tags origin master && npm run dist",
"release:minor": "standard-version --release-as minor && git push --follow-tags origin master && npm run dist",
"release:major": "standard-version --release-as major && git push --follow-tags origin master && npm run dist",
"repush": "git push --follow-tags origin master && npm run dist"
},
}
复制代码
src
├── lib
│ ├── cube
│ ├── databases
│ ├── enviroment
│ ├── files
│ ├── local-storage
│ ├── log
│ ├── shell
│ ├── stores
│ ├── update
│ ├── validator
│ └── watcher
├── main
│ ├── app-window.ts
│ ├── event-bus.ts
│ ├── index.ts
│ ├── keyboard
│ └── menu
├── models
│ ├── popup.ts
│ └── project.ts
└── renderer
├── App.tsx
├── assets
├── components
├── index.html
├── index.tsx
├── pages
└── types
复制代码
在目录结构上模仿了 Desktop。main 目录存放 main 进程相关代码,包括应用入口,窗口建立,菜单,快捷键等等;而 renderer 目录则是整个 UI 渲染层的代码。lib 目录则是一些和 UI 无关也和 main 无强相关的业务逻辑代码。models 则存放一些领域模型。
在这个 React 中项目中没有使用 css-modules 这类方案。而是使用 BEM 这类能造成命名空间的规范来实现模块化,这样作的好处是可以比较好的对样式进行覆盖。
在文件的组织方式上采用一个独立的 React 组件搭配一个独立的样式文件,这样在重构的时候,咱们想要修改一个组件的样式只须要找到对应的样式文件进行修改便可,提升重构的效率。
stylesheets
├── common.styl
├── components
│ ├── editor.styl
│ ├── empty-guide.styl
│ ├── find-in-page.styl
│ ├── reindex.styl
│ ├── sidebar.styl
│ ├── source-viewer.styl
│ └── upload.styl
├── index.styl
└── reset.styl
复制代码
进程间通讯(IPC,InterProcess Communication)是指在不一样进程之间传播或交换信息。
Electron 的 main 进程和 renderer 进程的通讯是经过 Electron 提供的 ipcMain
和 ipcRenderer
来实现的。
在 main 中向某一个窗口 renderer 发送消息可使用 window.webContents.send
。 在 main 端监听 renderer 消息可使用 ipcMain.on
。
// 在主进程中.
const { ipcMain } = require('electron')
ipcMain.on('asynchronous-message', (event, arg) => {
console.log(arg) // prints "ping"
event.reply('asynchronous-reply', 'pong')
})
ipcMain.on('synchronous-message', (event, arg) => {
console.log(arg) // prints "ping"
event.returnValue = 'pong'
})
复制代码
回复同步消息可使用 event.returnValue
。同步消息的返回值能够直接读取。 回复异步消息可使用 event.reply
。那么在 renderer 就要监听回复的 channel 获得返回值。
//在渲染器进程 (网页) 中。
const { ipcRenderer } = require('electron')
console.log(ipcRenderer.sendSync('synchronous-message', 'ping')) // prints "pong"
ipcRenderer.on('asynchronous-reply', (event, arg) => {
console.log(arg) // prints "pong"
})
ipcRenderer.send('asynchronous-message', 'ping')
复制代码
能够看到 renderer 可使用 ipcRenderer.send
向主进程发送异步消息。用 ipcRenderer.sendSync
发送同步消息。
数据持久化可选的方案有不少,好比 electron-store等基于 JSON 文件实现的存储方案。对于更复杂的应用场景还可使用 lowdb,nedb ,sqlite
等。
最初我使用的是 electron-store
, 而且一直有一个执念是对磁盘的读写只能在 main 进程进行,renderer 进程只负责渲染界面。因此在最初设计的是在 renderer 进程渲染数据或者更新数据的时候都须要经过 IPC 到 main 进程来完成最终的磁盘读写。除去读写正常的状况,还要考虑读写磁盘的异常,这样致使数据流异常的绕。并且还须要本身维护 ID 的生成。借鉴了 Desktop 的代码后,重构了数据持久化部分,也采用了 Dexie,它是对浏览器标准数据库 indexedDB 的一个封装。从它的 Readme 能够看到它主要解决了indexedDB 的三个问题:
import Dexie from 'dexie';
export interface IDatabaseProject {
id?: number;
name: string;
filePath: string;
}
export class ProjectsDatabase extends Dexie {
public projects: Dexie.Table<IDatabaseProject, number>;
constructor() {
super('ProjectsDatabase');
this.version(1).stores({
projects: '++id,&name,&filePath',
});
this.projects = this.table('projects');
}
}
复制代码
继承 Dexie 来实现咱们本身的数据库类,在构造函数中声明数据库的版本,表的 schema 等等。具体能够参考 Dexie 官方文档。
一些 UI 状态的标志位存储(好比某个弹窗是否显示过),咱们通常会把这种标志位存储到 localStorage
中。 在查看 Desktop 的源码过程当中,发现他们对 number
, boolean
类型的数据的 get, set 进行了简单的封装。使用起来很是方便,这里贴一下对于 boolean
型数据的处理。
export function getBoolean(key: string): boolean | undefined
export function getBoolean(key: string, defaultValue: boolean): boolean
export function getBoolean(
key: string,
defaultValue?: boolean
): boolean | undefined {
const value = localStorage.getItem(key)
if (value === null) {
return defaultValue
}
if (value === '1' || value === 'true') {
return true
}
if (value === '0' || value === 'false') {
return false
}
return defaultValue
}
export function setBoolean(key: string, value: boolean) {
localStorage.setItem(key, value ? '1' : '0')
}
复制代码
通常状况下,在编辑器中咱们编辑的内容实际上是编辑器读取磁盘文件到内存中的副本。因此说若是磁盘的文件发生了改动,好比 Git 切换分支形成文件变更,抑或是删除了磁盘文件,重命名等等都会形成内存版本和磁盘版本的不一致,即磁盘版本领先于内存版本,这个时候就可能产生冲突。解决这个问题很简单,可使用 fs.watch/watchFile 监听当前编辑的文件,一旦发生变化,就从新读取磁盘版本,更新内存版原本实现同步。可是 fs.watch 这个 API 在工程上不是能够开箱即用的,有许多兼容问题和一些 bug。好比说
Node.js fs.watch:
Node.js fs.watchFile:
上面列举的点来自 chokidar,它是一个 Node 模块,提供了开箱可用的监听文件变化的能力。只须要监听 add
, unlink
, change
等事件读取最新版本的文本到编辑器就能够实现磁盘/编辑器版本的同步了。
Desktop 的 contextmenu
(右键菜单)的实现基于原生 IPC 的,比较绕。
首先咱们须要知道的是 Menu
类是 main process only
的。
在须要 contextmenu
的 JSX.Element
上绑定 onContextMenu
事件。构造对象数组 Array<MenuItem>
, 而且为每一个 MenuItem 对象绑定触发事件,再经过 IPC 将对象传递至 main 进程,值得一提的是这个时候将 MenuItem 数组赋值给了一个全局对象,暂存起来。在 main 进程构造出真正的 MenuItem 实例,绑定 MenuItem 的点击事件,触发 MenuItem 点击事件的时候记录 MenuItem 的 序列号 index,再将 index 经过 event.sender.send 将 index 传递到 renderer 进程。renderer 进程拿到 index 以后根据以前保存的全局对象取出单个 MenuItem, 执行绑定的事件。
onContextMenu => showContextualMenu (暂存MenuItems,ipcRenderer.send) => icpMain => menu.popup() => MenuItem.onClick(index) => event.sernder.send(index) => MenuItem.action()
复制代码
因此在个人应用中使用了 remote 对象屏蔽上述复杂的 IPC 通讯。在 renderer 进程完成 Menu 的构造展现和事件的绑定触发。
import { remote } from 'electron';
const { MenuItem, dialog, getCurrentWindow, Menu } = remote;
const onContextMenu = (project: Project) => {
const menu = new Menu();
const menus = [
new MenuItem({
label: '在终端中打开',
visible: __DARWIN__,
click() {
const accessor = new FileAccessor(project.filePath);
accessor.openInTerminal();
},
}),
new MenuItem({
label: '在 vscode 中打开',
click() {
const accessor = new FileAccessor(project.filePath);
accessor.openInVscode();
},
}),
];
menus.forEach(menu.append);
menu.popup({ window: getCurrentWindow() });
};
复制代码
完善的日志不管是开发环境仍是生产环境都是很是重要的,大体记录 UI 状态迁移背后的数据变更,流程的分支走向,能很好的辅助开发。
参考 Desktop,他们的日志基于日志库:winston。
在 main 进程和 renderer 进程都提供了全局 log 对象,接口都是一致的。分别是 debug
, info
, warn
, error
。在 renderer 进程,简单的封装了 window.console
对象上的 debug
, info
, warn
, error
方法,日志打印到浏览器控制台的时候也经过 IPC 传递到 main 进程,由 main 进程统一管理。
main 进程接收了来自 renderer 进程的日志信息和 main 进程自身的日志信息。设置了两个 transports
。winston.transports.Console
和 winston.transports.DailyRotateFile
分别用于将日志信息打印在终端控制台和存储在磁盘文件。DailyRotateFile 以天为单位,设置了最多存储 14 天的上限。
在 main 进程和 renderer 进程启动时分别引入日志安装模块。由于 log 方法都是暴露在全局,所以只须要在进程启动时引入一次便可。同时在 TS 环境中还须要添加 log 方法的类型声明。
开源世界已经有很是完善的打包和发布的工具 -- electron-builder。它集多平台打包,签名,自动更新,发布到Github等平台等等功能于一身。
鉴于这个工具只能在内网使用,不能发布到 Github 并且也没有没有苹果开发者工具没法进行签名,只能利用 electron-builder
在本机打包,发布的话只能使用手动打包上传了,用户也只能手动下载安装包覆盖安装,不能像 VSCODE 这样实现自动更新。
既然不能自动更新,那么新版本下发后,如何通知到用户去下载新版本安装包更新呢? 从用户这一端来看,在应用每次启动的时候能够作一次请求,查询是否有版本更新,或者是在应用菜单栏提供入口,让用户手动触发更新查询。查询到服务端的最新版本后,使用 sermver 比较本机版本是否低于服务器版本,若是是就下发通知给用户,提示用户去下载更新。
在有限的条件下怎么实现这个功能呢?
实现这个功能必需的三个元素:服务端标识着最新版本的可读文件;托管各个版本安装包的云空间;应用代码中的更新逻辑。
服务端标识着最新版本的可读文件:每次打包时都会更新 package.json
,因此咱们直接把 package.json
上传到某个不带鉴权的 CDN 就能够,更新的时候就请求这个文件。
托管各个版本安装包的云空间:这个可使用云盘,云盘能够生成分享连接,把这个连接手动拷贝到 Gitlab 该版本的 tag 的 Notes 中。
应用代码中的更新逻辑:
import got from 'got';
import semver from 'semver';
import { app, remote, BrowserWindow } from 'electron';
const realApp = app || remote.app;
const currentVersion = realApp.getVersion();
export async function checkForUpdates(window: BrowserWindow, silent: boolean = false) {
const url = `http://yourcdn/package.json?t=${Date.now()}`;
try {
const response = await got(url);
const pkg = JSON.parse(response.body);
log.debug('检查更新,云端版本:', pkg.version);
log.debug('当前版本', currentVersion);
if (semver.lt(currentVersion, pkg.version)) {
window.webContents.send('update-available', pkg.version);
} else {
window.webContents.send('update-not-available', silent);
}
} catch (error) {
window.webContents.send('update-error', silent);
}
}
复制代码
分别在应用主进程启动、用户点击应用菜单检查更新
时调用这个方法,从而通知 UI 进程下发通知。咱们指望应用主进程启动时的更新是在失败或者无更新时是静默的,不用打扰用户,因此在 IPC 管道能够提供一个 silent
参数。检测到更新后就能够通知用户,用户点击更新后就能够跳转到最新版本的 Gitlab tags ,引导用户下载最新版本进行手动安装。
开发 Electron 应用中 renderer 端也是使用 Chrome devtools 来调试的。对于 React, Mobx 这类框的 devtools 扩展也能够经过 electron-devtools-installer
来安装。应用窗口建立以后调用electron-devtools-installer
进行 mobx
、react
等扩展的安装。
const { default: installExtension, MOBX_DEVTOOLS, REACT_DEVELOPER_TOOLS } = require('electron-devtools-installer');
const extensions = [REACT_DEVELOPER_TOOLS, MOBX_DEVTOOLS];
for (const extension of extensions) {
try {
installExtension(extension);
} catch (e) {
// log.error(e);
}
}
复制代码
对于桌面应用,一个常见的需求就是关闭后从新打开,须要恢复到上次打开时的窗口大小,位置。实现这个比较简单,监听窗口的 resize 事件,把窗口信息记录到当前用户的应用数据文件夹, 即 app.getPath(appData)
。下次启动应用建立窗口时读取这个文件设置窗口信息便可。开源社区已经有对这个功能封装好的库:electron-window-state
const windowStateKeeper = require('electron-window-state');
let win;
app.on('ready', function () {
let mainWindowState = windowStateKeeper({
defaultWidth: 1000,
defaultHeight: 800
});
win = new BrowserWindow({
'x': mainWindowState.x,
'y': mainWindowState.y,
'width': mainWindowState.width,
'height': mainWindowState.height
});
mainWindowState.manage(win);
});
复制代码
只须要提供缺省窗口大小,剩余的事情 electron-window-state
都帮咱们搞定了。
若是你以为这篇内容对你有价值,请点赞,并关注咱们的官网和咱们的微信公众号(WecTeam),每周都有优质文章推送: