文档结构  
翻译进度:已翻译     翻译赏金:0 元 (?)    ¥ 我要打赏
参与翻译: toypipi (10), tony (3)

比较图是 GitHub Desktop 的核心。 它既控制你与分支的交互,又显示你的更改相对于基本分支的影响

很显然它是应用程序中用户界面最复杂的部分,  使用释性动画显示了提交、同步和合并的产生的影响。

GitHub Desktop’s comparison graph

将OS X和Windows独立的代码库融合了统一的设计,因为我们知道他们之间共享代码将是必不可少的。基于图形的复杂,如果将它实施两次会是一个重大的负担。

跨平台代码对我们来说不是全新的:例如,两个代码库都使用git&libgit2。 然而,尊重每个平台惯用共享UI的方式是另外一回事了。

第 1 段(可获 2 积分)

幸运的是,在 Electron 应用中作为一个可重用的 web 组件,比对图已经被原型化。 我们知道我们可以在OS X上的本地Web视图中托管该实现,Windows中的实验也被证明是很有前途的。

我们是这样做的。

共享实现

两个GitHub Desktop实现都将比较图引用为子模块。 这将导入用于比较图和教程的完整HTML/CoffeeScript/SASS源,以及用于测试和构建的脚本。

大部分都不需要运行应用程序,因此一个构建脚本将源代码编译为可分发的、嵌入到应用程序中的HTML/JavaScript/CSS文件。

第 2 段(可获 2 积分)

在OS X平台上,我们在UI中使用Apple的WebView来集成比较图。 在Windows平台上,我们初步探索是使用.NET WebBrowser控件,但发现它并不可行,因此我们将其嵌入到 CefSharp 并使用其ChromiumWebBrowser。  尽管这样会让我们的下载数据的变大。WebView和ChromiumWebBrowser都时派生自WebKit,这让我们对比较图的开发和测试更改变的非常简单。 一般来说,在OS X平台上使用比较图表的工作的人大可不必担心他们是否可以在Windows平台上工作,反之亦然。

共享接口

第 3 段(可获 2 积分)

我们必须在两个平台上考虑比较图的API,但是,由于出现了重大更改,需要在两个地方进行整合。因为重大更改是之前讨论的结果,一个问题是在pull请求中调用它们,并确保熟悉其他平台的人有机会发表评论。

我们还通过有意识地努力保持比较图API狭窄和集中,以管理这种改动。一般的流程是这样的:

  1. 应用程序获取当前和基本分支。
  2. 应用程序请求比较图来绘制比较。
  3. 比较图要求其分支委托(应用程序)每个分支的一批提交。
  4. 应用程序获取这些提交并将其发送到比较图。
  5. 重复步骤3和4,直到比较图填充视图的宽度(加上一点填充)或到达分支点(分支收敛),表明应用程序发送了零条提交。
  6. 如果比较图形尚未找到分支点,则在滚动或调整左边大小时,重复步骤3至5,以显示更多的图形。
第 4 段(可获 2 积分)

比较图还可以绘制单个分支或拉取请求。 这些在效果上有些不同,但总体流程非常相似。

应用程式需要支持一些额外的交互:

  • 当出现新提交时,无论是同步还是提交,应用程序都会将其推送到比较图。
  • 当用户鼠标悬停、选择提交或单击按钮时,比较图表会通知它的交互委托(应用程序)。
  • 按钮执行的操作通常应该是异步的,因此比较图还可以显示一条消息来指示应用程序正在忙什么。 应用程序告诉比较图表要显示的消息,以及何时停止显示它。
  • 应用程序可以更改按钮,例如 当分支已发布到远程时将“发布”按钮更改为“同步”。
第 5 段(可获 2 积分)

由于这两个应用程序都必须实现它们的这一流程,他们也共享它周围的粗糙的架构。 广义上,这包括:

  1. 当某事物已经改变时(例如,用户已经提交),计算表示图形的状态的值。
  2. 比较连续状态。
  3. 通过请求比较图表执行某些操作来解释差异。 例如,如果两个状态涉及不同的分支,则应用程序要求比较图形绘制新的比较(或分支,或拉取请求)。 如果它们涉及相同的分支,但是随着提交发生改变,则应用程序要求比较图以增量方式插入新提交。
第 6 段(可获 2 积分)

非共享实现

虽然总体流程和架构是共享的,但是实现通常是完全不同的。 例如,虽然两个平台都使用WebKit,但桥接API是不一样的。

在OS X上,JavaScriptCore API允许我们在Objective-C / Swift和JavaScript之间传递任意对象,函数和数组。 本地代码可以调用JavaScript对象的方法,JavaScript代码可以调用本地对象的方法,而无需任何特殊处理。 我们还可以定义协议来指定我们的对象的哪些属性应该桥接。

第 7 段(可获 2 积分)

另一方面,CefSharp不桥接数组或函数。 JavaScript对象可以调用本机对象上的方法,但不能调用本机对象的属性。 本机对象不能调用JavaScript对象的方法; 作为替代,你可以访问 ChromeWebBrowser 去评估 JavaScript 来源的字符串。 由于比较图很大程度上是异步的,需要回调和数组,这会在构建时激发一组嵌入到比较图中的JavaScript shims程序。

在加载时,shims将自己设置为比较图的委托。 当比较图要求更多提交时,它会通过一个回调将提交的文件回传。 shims将此回调保存到私有表的一个key中,并调用应用程序传递该key。 一旦应用程序加载了提交,就调用回调,传递相同的key和提交数组。

第 8 段(可获 2 积分)
shims.getCommitsBefore = function (name, sha, callback) {
	callbacks[key(name, sha)] = callback;
	window.native.getCommitsBefore(name, sha);
}

由于CefSharp不桥接数组,这需要将表示提交的应用程序的模型对象序列化为比较图预期的JSON表示。 与OS X上的进程(其中提交对象的数组可以直接桥接)相比,显得稍微不方便,但是其优点是,比较图和应用程序相互隔离,不受期望状态的改变而影响。

第 9 段(可获 2 积分)
Browser.RunJsAsync("shims.didGetCommitsBefore("
	+ ToJson(name) + ", "
	+ ToJson(sha) + ", "
	+ ToJson(commits)
	+ ")");

最后,应用程序调用shims,传递序列化的提交数组,shims将提交转发到比较图。

shims.didGetCommitsBefore = function (name, sha, commits) {
	callbacks[key(name, sha)](commits);
	delete callbacks[key(name, sha)];
}

我们还使用CSS shims来调整比较图的外观,以适应主机平台的外观和感觉。 例如,在Windows上,按钮具有平面的外观,而在OS X上,它们具有轻微的渐变。 同样,Windows上的文本是Segoe UI,但在OS X上是Helvetica Neue。这有助于我们确保平台之间的共享努力不会导致最小公分母体验。

第 10 段(可获 2 积分)

GitHub Desktop’s comparison graph on Windows

前瞻

除了比较图以外,教程和一些共享体系结构,其大部分实现在两个平台上都保持了不同。 我们采用的方法的最大好处是,它使我们能够将GitHub for Mac和GitHub for Windows迭代地聚合到GitHub Desktop中,而不是彻底重写。 这反过来使我们能够在GitHub Desktop上工作时持续更新,而不必将我们的注意力分散。

我们将按照这里迭代的方式继续向前迭代。 关于比较图表还有很多内容,我们想在不同平台之间分享更多。 这里谈论的是1.1版本!

第 11 段(可获 2 积分)

文章评论