美女应用开发笔记1:前后端框架、开发工具、技术的选择：Vue or Nuxt,Firebase or Wilddog,ElementUI or MD

METADATA


title: 【91kanmm开发笔记】前后端框架、开发工具、技术的选择：Vue/Nuxt?Firebase/Wilddog?ElementUI/MDL?
date: 2018-05-07 22:10
tags: [前端,91kanmm开发笔记]
categories: 技术

本文主要介绍了在应用开始开发之前的一些准备工作，包括前端开发模式（传统网页开发or单页应用）、开发框架（主要在Vue和Nuxt之间）的选择，后端BaaS平台选择（Firebase or Wilddog野狗云），UI框架（elementUI or Material Design Lite）的选择等等。

在上一篇文章中简单介绍了一下倒腾 91kanmm 这个应用的缘起和一些想法。讲道理应该整理一下应用的整体架构和表现形式，最好是能出一版原型。考虑到自己对画原型一窍不通，应用本身也没有复杂的结构或交互，本着“先上一版能用的再说”的原则就直接进入开发阶段。

这个时候需要面对的第一个问题便是技术、框架的选择。自己本身就是前端，Vue是工作中用到比较多的一个框架。它的社区活跃，文档详细，有着大量基于其开发的插件和框架，而且整个团队都使用该框架开发，踩到坑了也能快速询问小伙伴。因此在前端框架上就选择了比较熟悉的Vue。

[update 2018-05-08 08:00]

网站内容自然是靠爬虫去爬了。人生苦短快用Python，这里我果断选择了Python作为开发语言，因为有非常非常多基于Python实现的爬虫、数据分析等各种只有想不到没有搜不到的模块。简单的爬虫无非就是Requests模块发送请求获取到网页的代码，BeautifulSoup模块解析前端代码提取出需要的信息。这里遇到的问题主要是：

1、我把爬虫放在了搬瓦工的VPS上，然而这个VPS在之前的文章中有说到作死开飞机IP被ban了，这样就导致了不能成功访问到国内的一些网站（？？？这个墙难道还是双向的吗）。想到的一个的办法就是挂代理了hhhhh，Requests有提供相应的代理功能，配置一下即可，我最后选择了直接在本地电脑上跑脚本爬了点数据下来。

2、短时间内高频率地去请求某个网站可能导致网站负载太大或是直接禁了爬虫的IP。关于这个我在爬虫的时候每请求一页就让程序随机睡眠一段时间，大家都是程序员不要互相为难ORZ。当然关于这个问题比较常用的解决办法是建立一个代理IP池，在请求同一个网站的时候不断地更换代理IP来逃过网站的一些反爬虫策略比如限制IP的访问频次。

后台方面，网站主要是输出图片和一些文字描述，图片都是以外链的形式加载，而且初期对并发量没有要求，所以我选择了使用第三方提供的BaaS服务。之前的关于介绍PWA的文章中有提到谷歌的Firebase，在91kanmm中也选择它作为数据存储、读取的工具。

这里不得不说一下毕竟是谷歌出品的产品，文档、开源项目非常完善，提供了简洁的RESTFUL API，而且无论是Python还是Vue都有相应的模块封装了该API，可以说是非常完美了：直接爬虫爬下数据发送给Firebase存储，在Vue中读取Firebase的数据展示即可；模块还实现了分页的功能，已经足够满足简单应用的后台需求。

在UI框架方面，有这么几个选择：饿了么出品的elementUI，谷歌出品的基于material design的MDL，Twitter推出的Bootstrap。他们都是非常优秀的UI框架并且封装了常用的组件，通过这些封装好的组件和布局能在没有产品、设计的情况下快速开发出一套样式美观的应用。

elementUI在团队中是作为后台UI框架使用的，看各类demo或分享也更多地将其作为一款后台的UI框架来使用；Bootstrap是老牌的UI框架了，还记得在大二的时候就用它来实现过响应式页面。

最后选择了基于material design实现的一款UI框架：mdui，相比于其他两个框架，mdui遵循了一套文档非常完善的设计规范，我可以根据这套规范选择页面的配色而不至于犯一些~~对于设计来说~~常识性的错误；规范中对于动画、交互方式的一些说明也很有意思，比如水波特效、通过阴影来表示不同元素之间的关系；框架中的各个组件都是符合规范所声明的，因此就算我不懂设计也能开发出风格统一的页面hhhh。

不过在实际开发中我请教并参考了设计师的意见，修改了卡片组件的样式并降低了它的阴影，毕竟参考现在几款比较流行的图片/导购类应用如小红书、花瓣，已经很少用到这么重的阴影了。

[update 2018-05-09 21:00]

框架和技术都选好那就可以进入开发阶段了。设想中是开设四个板块：豆瓣美女、美女写真、美女视频和暂定的一个模块，先进入开发的是豆瓣美女模块。整体的布局参照小红书，做图片展示的瀑布流布局，对于瀑布流布局的实现在之后的文章中会有说明。

在使用Vue开发前端页面的时候遇到几个小问题：

1、因为mdui封装了一些对dom的获取、操作方法，因此使用这些方法的生命周期应该是在mounted而不是created中，因为在created阶段元素还没生成。

2、因为要做滚动加载，判断页面滚动到底部的方法为：


let scrollTop = window.pageYOffset;//滚动高度
let clientHeight = document.documentElement.clientHeight;//窗口高度
let scrollHeight = document.documentElement.scrollHeight;//整个文档高度
if (scrollTop + clientHeight === scrollHeight) {
    console.log('滚动到底部');
}

因此如果需要在页面触底之前加载数据只需要判断：


let threshold = 0;  //需要提前加载的距离
if ((scrollTop + clientHeight + threshold) > scrollHeight) {
    console.log('触发加载');
}

3、event bus的使用。在Vue的文档中提到：

If you've never built a large-scale SPA and jump right into Vuex, it may feel verbose and daunting. That's perfectly normal - if your app is simple, you will most likely be fine without Vuex. A simple global event bus may be all you need.

想一想确实是这么个道理，我只需要持久化存储一些非常简单的信息，比如当前页面的名字，那vueX对我来说确实是杀鸡用牛刀了。一个简单的event bus就足够满足这些需求。

在main.js中声明event bus并绑定到实例中：


/*将Event Bus绑定到实例中*/
const EventBus = new Vue();
Object.defineProperties(Vue.prototype, {
  $bus: {
    get: function () {
      return EventBus;
    }
  }
});

页面中触发event bus的变化：


//触发变化
this.$bus.$emit('currentPage', pageName);

页面中监听event bus的变化：


//监听变化
this.$bus.$on('currentPage', ($event) => {
    this.currentActiveName = $event;
    console.log($event);
});

4、关于返回页面保留之前的浏览记录：

当用户切换tab去别的页面又切回来的时候，比较理想而且符合习惯的方式是保留之前的浏览数据和浏览位置。这里我采取的是使用Vue的keep-alive组件。实现上是在vue-router的配置文件中设置Router的mode属性为history，将App.vue文件中router-view组件包在keep-alive中，这样对于在keep-alive中的组件会被缓存下来。如此操作解决了页面缓存的问题，对于有些页面需要缓存，有些页面不需要缓存（这是一个非常常见的需求），那就要把keep-alive做成可配置的。在路由文件中需要缓存的页面增加


meta: {
    keepAlive: true
}

用以标识该页面需要缓存，在App.vue中增加对router-view的判断，只有被标识了keepAlive: true的页面才被放入keep-alive组件中：


<keep-alive>
    <router-view v-if="$route.meta.keepAlive"></router-view>
</keep-alive>
<router-view v-if="!$route.meta.keepAlive"></router-view>

如此一来就可以实现页面的缓存了。

但是问题到现在还没有解决，因为虽然页面被缓存了但是浏览位置并没有保留。当用户浏览到某个位置切换tab再切回来时虽然页面还是之前的页面但是滚动位置却是在头部。这个问题之前有碰到过类似的，直接暴力地存储下来当用户返回的时候返回到存储的位置就可以了。因为页面被缓存了所以生命周期中的钩子也不会像正常页面一样被调用，这里需要用到的是activated和deactivated两个钩子。官方文档中说明：

当组件在 <keep-alive> 内被切换，它的 activated 和 deactivated这两个生命周期钩子函数将会被对应执行。

5、SPA的SEO问题：

SPA的SEO不友好一直是个问题，特别是对于91kanmm这种以内容输出为主、靠流量生存的网站，SEO简直就是致命伤。

在网站第一版开发上线之后两周内搜索引擎都没有收录网站的任何信息，这就坚定了我要改变这种情况的想法。SPA的浏览模式确实能带来非常好的用户体验，因此并没有打算将网页的浏览模式改为传统的页面跳转。搜一下vue SEO，SPA SEO这类的问题，发现有这么几种解决方案：

针对搜索引擎爬虫特别输出一套网页代码

使用SSR(server side rendering)服务端渲染

都看到SSR了，和Vue关联搜索自然能注意到nuxt这个框架。这可以说是解决SEO问题最简单粗暴的方法了，于是毫不犹豫地看文档准备用nuxt重构代码。使用nuxt的一些坑在之后也会整理一篇文章出来。

这就是在开发前和开发中的一些想法，整理出来的同时也挖了两个坑：整理瀑布流、页面布局方面的一些想法，使用nuxt重构代码的一些坑。

而对于标题中的疑问也有了这些结论：在Vue和Nuxt之间选择了nuxt作为前端框架，因为它基于vue实现，即使重构代码也不会有很大的工作量，最重要的是它能解决SEO问题；在Firebase和Wilddog野狗云之间选择了Wilddog野狗云，这个就没什么好讨论的了纯粹是因为谷歌在墙内水土不服只能使用替代品，不过野狗云的免费套餐有诸多限制，现在已经着手开始采用KOA+Mongodb写一套简单的后台了~~这又是一个坑~~；在各种UI框架中选择了基于Material Design设计规范实现的mdui，因为谷歌大法好！

啊这篇写了这么多天的博客终于完结了！