摘要：老司機開車從不需要理由喜歡我就來點我吧易杭貼吧新鮮出爐的中文社區前述最近一直在寫一個發貼子的應用，前不久才剛剛完工其實還有很多需要改進的地方。

"老司機開車 從不需要理由 喜歡我 就來點我吧"   
易杭貼吧--新鮮出爐的中文社區 http://tieba.freeedit.cn

最近一直在寫一個發貼子的應用，前不久才剛剛“完工”（其實還有很多需要改進的地方）。
這個應用是仿著上一個版本的百度貼吧來寫的，最初的打算是想要完成百度貼吧的最主要的那部分基本功能，但真正做起來，卻不是一件簡單的事。

這個項目一共用了近二十天的時間，我在這段時間內，既踩了很多的坑，也學到了很多的知識。
踩的坑越多，修復的bug越多，看的東西越多，就越覺得自己知識淺陋。
很多的東西，都是自己用過了之后，才會恍然大悟。看上一百遍，還真的不如自己動手寫一遍。
所以我想將這個應用的構建過程和在這段時間內的心得體會記一記。自己呢，也能在寫的過程中，對應用中的某些問題進行反思。

@-v-@

其實自己從來沒有這么完整地做過一個這樣的項目。
從應用的選題、界面的設計、工具的選擇，到環境的搭建、應用的部署，最后到應用的測試和修復，全部依賴于自己。
我既算是這個應用的“UI設計師”，也算是這個應用的“前端工程師”、“后端工程師”、“數據庫工程師”，以及“項目架構師”。（突然就把自己說得高大上了，哭笑不得~）

不過，自己一個人要演這么多的角色，其中的困難很大。
近二十天的時間里，我不斷地去嘗試打磨作品的細節，希望能做好每一個環節。
但即使到了部署的時候，它也仍然只是個布娃娃。
不過，仍然會使我高興的是，它至少還可以“動”。

這張圖就是這個項目第一次打開時的界面。
當我們不斷往右滑的時候，它又會一頁頁地顯示。到了最后一頁，它又會很調皮地叫我們返回到第一頁，然后點擊進入。
進入以后，就是登錄、注冊之類的。完成了之后，就會直接進入到app里面，然后就可以搜索發帖了。

頁面展示之類的，我就不寫了，同伴們看了，估計也會覺得沒什么意思。
百度貼吧長什么樣子，它也就大概長什么樣子，只是某些地方，我做了更改和精簡（因為實在是沒有那么多時間去寫這些功能，功能項太多了，單靠自己一個人，根本難以在短時間內做完，笑~）。
只需要去玩一玩，就知道效果是怎么樣的了，所以我就直接給地址吧。

演示 --- 易杭貼吧--新鮮出爐的中文社區 http://tieba.freeedit.cn

源碼 --- https://github.com/freeedit/yihang-tieba

（項目結構是怎樣的，以及如何去運行這個項目，見項目源碼地址中的readme文件。）

在這個項目中，我內置了一個彩蛋，大體是長這個樣子的 :

嗯嗯，其實我們可以多試幾次，每次出現的消息是不一樣的，就仿佛有個小機器人在跟我們對話一樣。

其他的效果圖，都存放在項目的result文件夾中，地址是：

freeedit/yihang-tieba/tieba-design/result

最后的最后，放上一個總覽圖。

（寫了一大堆有的沒的，接下來才算是進入正文。）

最初想做一個和QQ一模一樣的聊天工具，但后來又覺得聊天的工具太普遍了，所以就將目標轉到了百度貼吧。
同樣都是和別人一起聊天吹水水，貼吧卻要顯得更好玩一些。（秋名山老司機一枚前來覲見）
自己也很喜歡貼吧那種“搞笑”、“無畏”的吹水環境。所以后來，就敲定主意做一個貼吧出來。

我將項目分成了四個部分來分步驟完成：

1 設計 freeedit/yihang-tieba/tieba-design
2 前端 freeedit/yihang-tieba/tieba-client
3 后端 freeedit/yihang-tieba/tieba-server
4 前后端連接 + 將項目部署給主機

小部分的設計圖存放在這里: （還有一大部分被我失誤給刪掉了）

freeedit/yihang-tieba/tieba-design

首先在阿里矢量圖標庫中，選取了近80個svg圖，再用icomoon將它們打包成能引入stylus的字體文件。
（暈死，我誤刪的部分，就包括了它，導致我下一次想替一個圖標，重新打包成新的字體文件都不行）

接著，我便開始設計底部的五個小圖標。本來打算用AI畫幾個矢量圖，但電腦上沒裝，再加上很久沒用過了，不知道還會不會用，就直接用PS來畫了。
PS來畫的時候，總感覺，CC2014以后，對矢量圖層進行交并補運算好像不一樣了，不知道是不是自己的錯覺。合并多個矢量圖層，總不會出現自己想要的效果（也許是自己還沒摸透PS吧）。最后呢，就只能做位圖了。

做完了這些，我才來開始畫應用的圖標。一個簡簡單單的吧字，放在一個圓角矩形中，上下兩個缺口，底色用#3388ff，搞定！

在上圖最右邊的吧字圖標，是用來給PWA圖標配的。
第二個圖標，是用來做用戶默認的頭像的。
其他幾個就是應用圖標和底欄圖標了。
（為了給用戶一種圖標在往上升騰的感覺，我故意將幾個線條樣式的圖標下面，開了個口子。用戶可能看著就會很難受，就想要把它下面那根線條補全，然后他就可能會按下去。）

另外呢，考慮到網絡可能會出現問題，圖片地址找不到，所以也準備了一個默認的圖片背景圖。

freeedit/yihang-tieba/tieba-client

最開始想用sass寫的，但是后來感覺stylus更簡潔，更干凈，看上去更好看，然后就選它來處理CSS了。
決定用stylus之后，就想找個和stylus一樣縮進式語法的html預處理器。正好，Jade和它真的是絕配。兩個都長得一模一樣的，用起來也方便。
我很慶幸自己選了stylue+pug的組合，要不然，這個應用可能需要一個月才能搞定呢。

到這兒呢，我的強迫癥就犯了。有了CSS和HTML的預處理器，怎么著，JS也要上個“預處理器”吧。
當時瘋狂地想要用TS，其原因并不是因為它很酷（當然，酷也算它的一方面），而是想三劍客不能只有兩劍客（babel不算劍客，它頂多是瓶萬金油，個人愚見），這樣打架不利索。
（還有一個最最重要的原因，說出來，你們可能會笑死我，它那atom file-icons圖標賊好看，綠色偏青色，比JS那個屎黃色好看多了。）
各位看官笑一笑就行了，飄過飄過...

回歸理智。。。

vue對ts的支持好像還不怎么好，vue-loader是可以用，但用著用著，有些文件引不進來。啊！請原諒我的無知，我真不知道為什么會這樣。
最后，因為搞不定了，還是只要兩個劍客就夠了，三個劍客容易吵架。再加上從未用過TS，不好掌控大局啊。一旦TS出了BUG，我就得哭暈在廁所，果斷放棄好了。強迫癥之類的東西，身為一名前端化緣人，果然還是不該有啊。

最終使用到的一套前端工具，就是這樣的：

template: pug
style: stylus
script: babel
database: indexDB

pug stylus babel
vue2 vuex axios+vue-axios vue-router vue-loader
better-scroll flexible animate
webpack express webpack-pwa-manifest
indexDB localStorage

  "dependencies": {
    "better-scroll": "^0.1.15",
    "flexible": "",
    "animate": "",
    "axios": "^0.16.2",
    "vue": "^2.2.6",
    "vue-axios": "^2.0.2",
    "vue-router": "^2.3.1",
    "vuex": "^2.3.1"
  },
  "devDependencies": {
    "babel-preset-stage-2": "^6.22.0",
    "eslint": "^3.19.0",
    "eslint-config-standard": "^6.2.1",
    "express": "^4.14.1",
    "pug": "^2.0.0-rc.1",
    "stylus": "^0.54.5",
    "vue-loader": "^11.3.4",
    "webpack": "^2.3.3",
    "webpack-pwa-manifest": "^2.1.4"
  }

freeedit/yihang-tieba/tieba-server

后端倒是沒什么可說的（后端的哥哥姐姐們別生氣，我說的是自己寫的后端，笑~），無非就是用koa搭了個后臺，搞一搞跨域問題（以后如果有時間呢，再弄一個token驗證一下），然后用mongoose連一下mongodb，寫一寫schema，做一下limit、skip、populate之類的分頁、關聯查詢，再加上那一套簡單的curd操作，沒了。

哦，對了，我寫了一個很扯淡的代理方式。
在應用中的直播那一項，我自己搞不定，不知道怎么做直播，然后又想填補它的空缺。
重要的是，百度貼吧里面弄一個直播...這個...總感覺有點跑題的味道。（這不是發水貼的地方，直播間也能水貼？）
當然，最最重要的還是，自己搞不定直播這個功能。
然后，我就用了個“知道”，來頂替“直播”的位置。（主要是因為，自己經常去貼吧里面搜貼子看，找一些以前別人問過的問題，畢竟有些問題在別的地方找不到答案，或者回答得不好...）

然后我就需要給用戶實時提示，這個地方，我代理的是360問答頁面上請求的接口。
最后用戶需要獲取到相應的信息，這個地方，我代理的是百度知道的頁面，然后把頁面上的數據抓下來，形成json文件返回給用戶。

恩恩，360問答的實時提示+百度知道的頁面信息，這就是傳說中的搜索，自己都被自己搞的笑死了，不過還別說，辦法雖然有點那啥，但效果還不錯誒，至少用來做一個DEMO，足夠了。

  "dependencies": {
    "cheerio": "^1.0.0-rc.1",
    "iconv-lite": "^0.4.17",
    "koa": "^2.2.0",
    "koa-router": "^7.1.1",
    "koa-static": "^3.0.0",
    "md5": "^2.2.1",
    "moment": "^2.18.1",
    "mongoose": "^4.9.3"
  },
  "devDependencies": {
    "cross-env": "^4.0.0",
    "nodemon": "^1.11.0"
  }

其實吧，數據在連接時是最麻煩的了。
因為數據請求需要時間，頁面需要等待請求完成，完成之后呢，又得渲染頁面，渲染頁面的同時呢，又要處理沒有數據或數據有問題的情況，而且，這些數據可能還需要存儲在vuex中，如果要長期存起來，還要用localStorage或indexDB，賊麻煩。
稍不注意，就會出bug，而且寫著寫著，腦袋就有點不夠用了。當數據的請求在一個頁面里面放多了，那不同的請求之間還可能存在關聯性，繞來繞去的，自己都不知道自己在干嘛。

幸好，我提前將每個vue文件都分離開來，成了幾個獨立的文件：

xxx-component
  index.vue      // 組件的入口
  template.pug   // html
  style.styl     // css
  script.js      // script
  data.json      // 組件中使用到的靜態數據

對每個文件的寫法，也都做了個模板出來。我每次需要寫組件的時候，復制一份模板，改一改就好了。
另外呢，該抽離的地方，我都抽離了，實在是抽不了，或者我搞不定的，就沒去動它。

為了完成這個應用，我連續抽了好幾個庫文件出來。（readme中有寫）
跨域庫、indexDB庫、常用的功能函數庫、mongoose的Promise版curd庫

這些文件最終都被上傳到了我的個人工具庫中。 詳見
freeedit/lib-mini-libs-collection

項目的文件其實打包后也挺大的（904kb），比較手機耗流量。
為了讓項目具有離線存儲的能力，減少流量的消耗。
所以我在項目中用webpack插件配了一個manifest.js文件出來，這就要求需要使用Https。
但不知是域名方面還是其他什么原因，即使是在我加了https證書之后，也無法訪問https，所以最終就只能暫時用http先替著。
如果瀏覽器上面顯示不安全字樣，及瀏覽器中顯示某某WARN信息，那應該就是HTTPS造成的。

（這個項目沒有做SSR優化，一是這個應用沒有做的必要，這樣會加重服務器的負擔，二是自己對這方面不熟，還在起步階段）
（可能接下來，我需要認認真真全面學習一下SSR和PWA ServiceWorker了）

vue computed中的函數好像不能用async+await（用的時候才發現它會失效），但我當時死腦筋，跳不過去，還是后來在其他地方用定時查詢來搞定的。
不知道還有沒有什么別的方法，讓computed之中能用async異步獲取數據。（雖然我明白，這件事情不該由computed來做）

不知道mongoose的populate()函數中，繼續嵌套多個同級的populate，怎么寫的。（populate的地方之中，又有多個需要populate的地方）

比如獲取文章，然后呢需要populate("floor")，在floor之中，又需要populate("ff")和populate commit數組每一個對象中的一個叫uid的屬性。不知道該怎么寫，求問。

const postSchema = new Schema({
  bar: {
    type: Schema.ObjectId,
    ref: "bar",
    index: true
  }
  lz: {
    type: Schema.ObjectId,
    required: true,
    ref: "user",
    index: true
  }
  floor: [{
    type: Schema.ObjectId,
    ref: "floor",
    index: true
  }]
})

const floorSchema = new Schema({
  ff: {
    type: Schema.ObjectId,
    required: true,
    ref: "user"
  },
  commit: [{
    uid: {
      type: Schema.ObjectId,
      ref: "user",
    }
  }]
})

...
還有好幾個問題，一時之間想不起來了。
有知道的哥哥姐姐們，替我解一解。

學軟件三年，從電腦打字開始，到影視后期處理，再到游戲編程，最后...我選擇了前端作為自己的長期學習目標。
因為，我看到了前端的未來。
現在的網頁，已經在逐漸向app轉型了，真的很希望有一天，看到它取代桌面的樣子。
當我們的桌面本身就是一個瀏覽器的時候，輸入任何命令，都能從網絡上獲取到我想要的東西。我們不需要再去裝WPS、迅雷應用了，因為它們已經變成了網頁。
當我們打開這些網頁的時候，長的和本地應用一樣。而且它們也能像應用一樣，被我們安裝在電腦上，頁面外沒有瀏覽器外殼，桌面最下端也沒有什么開始按鈕，只有一個搜索框，簡單到了極點，這該是多么的棒啊。
我想，這就是我希望的未來前端。而且前端已經在向這方向靠攏了，我想要為它的發展出一份力。

很慶幸，自己沒有一來就學習前端。
最開始，我是奔后期處理去的，也就是PS、AI、AU、AE、MAYA、ZBrush那一套。
這也算是培養了自己的設計美感（哈哈~歪路子美感）。
可能很多人覺得，幾個小圖標，一張PSD圖，沒什么好設計的，照著做都可以做出來的，但如果沒有別人的作為參考，就很不容易了。（特別是要融情于“景”）
而且，PS的很多概念，和HTML+CSS的布局概念很像，圖層、蒙版、背景陰影、漸變、打組，等等這些，都與HTML+CSS不謀而合，就像是天生為它們設計的。
就是因為早期形成了某些說不出來的概念，所以才能在這個作品中，嘗試著把設計的空缺給補上。

在做這個項目的時候，我體會到了大項目的來之不易。
知易行難，即使是一個看上去并不復雜的應用，要真的做好，也并不是一件簡單的事。
嘗試去做的項目越大，就越覺得自己了解得過于泛泛。
想要做得精細，還是得需要時間不斷地去琢磨。

原文地址：http://blog.freeedit.cn/2017/06/12/Yihang-Tieba-Introduction/

易杭 : http://blog.freeedit.cn/about/ 2017/6/12 10:07 8906字