原文地址：https://about.gitlab.com/2017/02/06/vue-big-plan/

GitLab的前端正在变的越来越好。如今我们做了两件大事，我们想与大家分享它们以及我们未来的大计划。

• 如果您使用了GDK(GitLab Development Kit)，请确保已经更新！如果您不知道所讲的是什么，跳过阅读即可
• 请参考此文档查看如何升级GDK
• 如果您在升级的过程中遇到了什么问题，可以参考我们的故障排除指南
• 请随时反馈您发现的其它问题

我们的大前端计划

Vue很棒！不久前我曾写过一篇文章来说明为什么GitLab喜欢Vue。现在这篇文章成为了展示了我们通过Vue和webpack使得GitLab变的更快的这个长期计划的一种方式。我们希望前端开发者能够更加容易的开发GitLab。

生活中的经验告诉我们“重要的事情不是使用什么工具，而是如何使用它们”。也就是说我们选择了Vue，但并不意味着成功。也就是说我们同样可以使用Angular或React以及其它更好的工具。Vue是一种简单的方式。

我们的计划如何使用Vue在一段较长的时间中使得GitLab变的更好、更快以及更简单（的开发）呢？

下面的计划是一项正在进行的工作，非常雄心勃勃，但我相信，这将为开发和性能创造一个更好的前端。 这份文档也是对我们计划在GitLab前端做的事情的参考。

一个更加健康的前端

当我们开始开发GitLab时，我们简单的将jQuary集成在Rails中。它没有想Vue那样合理的改变大图片。较小的图片，我们添加了许多linters，更好的代码覆盖，和许多其他伟大的事情。

1.只重写您需要的

我们并没有完全重写GitLab的前端。（完全重写）将是一个非常糟糕的主意。当然这并不是对于所有人而言都是糟糕的，只是对于一个初创公司而言是一个糟糕的主意。因为这将花费极大的时间和金钱。现在已有的jQuery（尽管有些人说这并不cool）已经通过测试并且工作的非常好。我们没有必要去重写那些效果很好的方法，除非修改后能带来很大的收益。

我们也不会使用Vue实现所有的新功能，您也不需要这样。但是，对于某些UI而言，即使是最简单的Vue的部分也很难找到适用的地方。

下面是一些例子：

1.issue页面（用于展示个人issue），里面用了大量的jQuary。我们现在不会重写它，因为它很好用。我们将使用Vue重写一小部分，用以增强某些功能的实时性。我们现在正在做实时的标题和描述。

2.Phil所写的Issue Boards，是Vue完美的候选。这是一个全新的功能，有着很多无功部分。

3.现在的issue页一次加载了全部的评论，并且增加了大量的事件监听。由于性能的原因，这个页面并不适合Vue。我们将评论变成Vue应用，并使评论的内容和表情选择器等作为组件。我们放大了UX，使您无需等待可以立即看到链接指向的评论。有很多更好的方法展示大量的评论，所以我们需要尽可能的重新考虑。

4.管道页面被重写以用于实时更新的到达。

5.环境是在Vue中编写的。

6.也有很多其他的地方，我们准备使用或者已经使用Vue。由于数量太多就不一一列举。

正如您所看到的，我们没在所有的地方使用Vue。

2.增加webpack

Rails是一个很好的系统，用来抓取您的Ruby库并且在您的应用中构建他们。通过“bundle install”可以安装您在Gemfile中所包含的所有东西。所以为什么前端还要坚持把他们的库放在vender目录下？难道我们还不足以拥有我们自己的库管理系统？自从资源管道第一次出现，JavaScript的生态系统就已经变得十分成熟。现在我们拥有“npm install”，也可以利用更高级的代码构建工具。

通过引入webpack（已经合并并且准备应用），我们获得了很多好处。

1.JavaScript库将不会被直接捆绑在GitLab的源代码或者包含在gem里面。例如，jquery-ui和bootstrap-rails作为一个ruby的gem被引入，我们在gem维护者的帮助下保持JavaScript库的更新。

2.当代码在文件中被共享时，我们可以确保不会重复加载lodash。列如，如果两个文件都需要加载lodash，我们将只加载一次lodash的代码。除了lodash不会被引用多次，在tree shaking的帮助下，只有我们所用到的lodash组件会被引用，而不是引用整个库。

3.我们可以增加hot module replacement使得我们的Vue开发的更快。这是一个开发环境的特性，现在我们在开发的过程中花费了大量的时间用来刷新页面。

 

将有两个不同的构建方式：

• 独立的构建：包含编译器和运行环境
• 运行时构建：由于不包含编译器，因此您需要预编译模板或是手动编写实现方法

3.移除Turbolinks

Turbolinks实现了什么？

我们需要解决的问题

当您的JS被多个页面同时加载时，时间成为了一个很严重的问题。如果您想我们一样使用了gem ‘jquery-turbolinks’，那么$ready这个方法将会在每个页面中加载，即使这些页面没有按照传统的加载方式加载。不通过整个应用引入而在每个页面中编写特定的JavaScript是很痛苦的。我们做了而且做得很好，但是，为什么呢？对于大量需要引用在各个页面中的JS确实没有什么办法。

任何外部的链接都加载的非常快，因此我们需要注意性能。

如果您不注意，您的事件将被多次加载，因此多次启动。 列如以下代码：

$(function(){
  $(document).on('click','.some-element', function(){
    console.log('Click loaded');
  }
});

解决方式

有很多方法可以解决这个问题，有的很好有的很坏。

1不要在$ready的回调中创建时间

2使用下面的方法

	 $(document)
 	 .off('click', '.some-element')
 	 .on('click'...

我管他叫die live方法，在以前的jQuery中人们经常在各种地方写die().live()。这是以前在学校中的jQuery的off().on()。

3.写一个事件管理器作为所有添加事件的委托。

4.移除Turbolinks并且确保在每个页面中只加载您需要的代码。

额外的

当我们移除了Turbolinks之后，我们可以做一些更酷的事情。我们可以让每个页面独立存在。之后，某些页面可以有自己的Vue应用。比如，我们可以使用文件浏览器的Vue应用程序。合并请求也也可以是它自己的应用程序。查看文件的代码也不需要在其他页面中加载，所有页面都是这样。这并不是什么新鲜事，这是web开发的基础。这也不是一个新的范例，我们不会是第一个。.

总结

现在仍在争论是否将整个网站作为一个单一页面的应用程序，但我认为这只能带来更加困难的维护，对于性能和用户而言并没有什么好处。当然，现在是一个很好的机会能够让GitLab变成一个janky应用。例如，简档页面可能非常轻，人们不能直接链接到简档页面; 它应该在我们的项目中加载每一个单独的JavaScript。

这只是GitLab的一小步，确是前端团队的一大步。在未来您将会看到我们的团队带来更多更新更酷的事情。此举便是向这一方向迈出的一步。