request payload怎么发_做了一个个人博客，但不知道怎么介绍
整個三月份，我大概做了一些事；
- 給阿里云服務(wù)器有續(xù)費(fèi)了一年（整整去年漲了200RMB），完成了node、nginx、mongo配置
- 給個人域名續(xù)費(fèi)了一年（做個個人站點(diǎn)）
- 蘋果降價,購入了iMac（整體感覺寫文檔時比macbook爽）
- 基于個人的React組件庫，做了個通用管理后臺，并完善了React組件庫
- 用React SSR方案做了我的個人網(wǎng)站
- ......其他的一些事，比如股票竟然沒漲。kao
回到正題，寫這篇文章是想跟記錄和分享下搭建個人網(wǎng)站項(xiàng)目的過程。發(fā)了大概三個周末，外加15個的20:00 ~ 22:30 。
我想大概可以按下面幾點(diǎn)來開始
王佳欣的小站?www.shuxia123.com2019.03.31 13:41:30 先上線了....
一：個人網(wǎng)站定位，為什么想做呢？
網(wǎng)站以前端總結(jié)文章為主。寫一些技術(shù)總結(jié)；一些讀后感；嘗試翻譯英文文檔；轉(zhuǎn)載一些覺得不錯的文章(會先取得作者同意)。
展示目前正在做的一些開源項(xiàng)目，代碼還是托管在github上。
展示一些比較有趣的demo。
為什么想做呢？因?yàn)橐庾R到時間很快，工作很忙，而離開學(xué)校后漸漸沒有了寫日記的習(xí)慣，每當(dāng)年尾月末常常不得憶，需要有一個可以放"東西"的地方。
還有也是最重要的，就是最近我真的很閑....
第二：技術(shù)選型的問題，為什么用React SSR?
技術(shù)選型的話大概是這樣的。
確定站點(diǎn)以響應(yīng)式的形式展示。
服務(wù)器：nginx，用了阿里云windows server 2008，為什么不用linux？其實(shí)本來想用，無奈很久以前有一些數(shù)據(jù)用的SqlServer數(shù)據(jù)庫。
服務(wù)端語言選型：Koa2.0 + Mongoddb
前端工程化，webpack4.0，實(shí)現(xiàn)：React + Redux + React-Router
發(fā)布：本地git push，服務(wù)器git pull 完成發(fā)布
采用SSR的原因是，考慮到要適配PC端和移動端，如果采用前后端分離的方案的話，會造成首次訪問首屏的問題，這個問題在移動端，我們可通過添加Loading、占位符等方案處理，但是在PC端下屏幕比較大，問題會成倍放大，因?yàn)榭紤]做SSR服務(wù)端渲染。SEO？這個個人網(wǎng)站倒無所謂。
為什么用React呢？因?yàn)槲业腞eact組件庫，自動16年用在公司幾個項(xiàng)目上后，就很少再去優(yōu)化了，18年年底升級到React16版本，我想借此機(jī)會看下它有什么問題，也看它還有什么欠缺，完善一下。
還有呢？我喜歡React，喜歡它組件分離；喜歡它的高階組件式的裝飾增強(qiáng)組件，實(shí)現(xiàn)依賴反轉(zhuǎn)很好擴(kuò)展；喜歡函數(shù)組件簡潔的寫法；喜歡它每個大版本都站在應(yīng)用者的角度，給人很大的驚喜。
第三：服務(wù)端開發(fā)，接口怎么做才規(guī)范？
這次服務(wù)端的選型是，Koa2 + Mongodb。當(dāng)然考慮過用關(guān)系型數(shù)據(jù)如MySql，畢竟更加熟悉，后面做了份表結(jié)構(gòu)設(shè)計，發(fā)現(xiàn)其實(shí)挺簡單的，基本上，可以不用到關(guān)聯(lián)等操作。因此還是用Mongodb，我也想借此機(jī)會，看下以后擴(kuò)展起來，文檔型數(shù)據(jù)庫，是否會難以下手。
如果說網(wǎng)站的前端頁面是作品的長相，那么服務(wù)端開發(fā)和接口應(yīng)該就是“柜子的背后了”。喬布斯他爸教導(dǎo)喬布斯，做為一名木匠，柜子的背面也是作品的一部分。所以，在這上面也發(fā)了比較多的精力。接口規(guī)范；數(shù)據(jù)返回規(guī)范；狀態(tài)碼規(guī)范等等。把以往和服務(wù)端人員配合時，疑惑的問題都考慮了進(jìn)去。
接口規(guī)范方面采用了restful的規(guī)范，嚴(yán)格采用get、post、put、delete。這個在后續(xù)前端api層開發(fā)可以非常簡潔；
// api接口允許的options有：[get、post、put、delete] // 地址：http://www.shuxia123.com/services/classifies// 前端api層非常簡單如下 import Base from './base'; class Classifies extends Base {constructor () {// 構(gòu)造函數(shù)聲明實(shí)體super('classifies');}fetch (param) {return this.request({});}fetchOne (id) {return this.request({ id });}create (param) {return this.request({ data: param, method: 'post' });}edit (id, param) {return this.request({ id, data: param, method: 'put' });}remove (id) {return this.request({ id, method: 'delete' });} }export default new Classifies();數(shù)據(jù)返回規(guī)范；如下
{"meta": {"code": 0,"msg": ""},"response": [{"id": 0,"name": "所有","path": "","total": 2}] } // meta放狀態(tài)信息，錯誤信息等 // response放數(shù)據(jù)信息狀態(tài)碼規(guī)范，制定了一些統(tǒng)一的狀態(tài)碼，這樣前端開發(fā)的時候，可以根據(jù)狀態(tài)碼做信息提示。
.......
第四：接口測試
這次個人網(wǎng)站的搭建，我決定采取的方式是，先搭建服務(wù)端，開發(fā)好對應(yīng)接口；然后，再開發(fā)前端頁面。然后進(jìn)行最后的聯(lián)調(diào)。
考慮到，為了最大程度的提高后續(xù)前端接口調(diào)用調(diào)試的效率。因此，對接口進(jìn)行了完成測試。
首先，分好模塊，比如，文章模塊、demo模塊、開源模塊、用戶模塊；
然后，選好測試工具，我用的是postman進(jìn)行測試，在里面建好集合，按模塊進(jìn)行各個模塊的測試。
我建立的測試集合大概是這樣的，覆蓋了所有主要的接口。
第五：后臺系統(tǒng)開發(fā)
基于：React + Redex，組件庫用自己的組件庫。
其實(shí)，能做這個開源代碼非常多，antd、ele、等等，甚至有很多git提供了完整的方案。
我呢，出于想完善下我的組件庫的原因，做了一個決定，用我的組件庫進(jìn)行開發(fā)。壞處是，可能要發(fā)更多的時間寫代碼；好處是，我給組件庫做了一些完善，比如，表單驗(yàn)證，比如，文檔編輯器，比如，照片編輯器等等。
后臺也是需要好好設(shè)計，我見過很多工作很久好幾年的開發(fā)者，寫出來的后臺異常難用，這個在我這里是不能存在的，所以，也發(fā)了比較大的精力進(jìn)行開發(fā)。結(jié)果比較滿意，非常簡潔，好用。好吧，可能我比較挑哈。
可以展示下界面（考慮后期開源哈）
第六：前端頁面開發(fā)
這次的前端頁面都是自己做的（連logo都是用css寫的，畢竟ps技術(shù)不善于），風(fēng)格也比較符合我。有借鑒了一些網(wǎng)站。比如詳情頁，是看了airbnb(大愛airbnb的體驗(yàn))的頁面。
然后就是具體開發(fā)了，這個也比較擅長，因?yàn)橐脖容^簡單，所以就不深入了。
更多的時間是發(fā)在在服務(wù)端渲染后，和react首次掛載時，如何考慮性能，避免不必要的請求浪費(fèi)。
第七：用戶體驗(yàn)
做了比較多的考慮。
loading采用什么形式？
試過了很多l(xiāng)oading效果后，決定采用骨架圖，好處是再數(shù)據(jù)沒有出來前可以用骨架圖占住和數(shù)據(jù)一致的圖案，這樣比采用普通的loading造成的視覺沖突小。
因?yàn)楸镜氐慕涌谡埱筇炝?#xff0c;造成了閃屏，骨架圖沒出現(xiàn)的情況。為了能體現(xiàn)出骨架圖的效果，在前端對接口層做了統(tǒng)一的處理，既接口請求小于600ms的，等待到了600ms后再resolve這樣效果比較同意。為什么是600ms？試了很多次，覺得它很合適。等真實(shí)到線上后，可能需要再調(diào)優(yōu)一次。
圖片加載，怎么優(yōu)化？
圖片怎么加載呢？一般的做法是懶加載可視區(qū)域的圖片。但這次我想做一些不一樣的，因?yàn)檫@次服務(wù)端是自己開發(fā)，圖片上傳存儲也是自己開發(fā)，所以可以完全按照我的想法進(jìn)行。
比如：3241234_w_500_h_300.jpg，對應(yīng)的存儲的預(yù)覽圖未：3241234_w_500_h_300_preview.jpg。
這樣在服務(wù)端渲染時，可以通過正則替換的形式，替換文檔內(nèi)的圖片路徑優(yōu)先加載預(yù)覽圖。
以往做懶加載，大概可以保證用戶的需求。這次我的做法是，在上傳圖片的時候同時保持兩張圖片，一張原尺寸，一張寬度20px的小圖片，同時存儲是命名采用“時間戳_w_[width]_h_[height].[ext]”，這樣我從圖片名稱就可以利用正則匹配出圖片的寬度高度，在加載時，采用先加載20px小圖（按原圖尺寸展示），這樣可以做到模糊加載的效果。最終效果也比較符合我的想法。
路由間切換要不要做過渡動畫？
原本有考慮，PC端因?yàn)槠聊槐容^大，實(shí)現(xiàn)后發(fā)現(xiàn)，動畫動畫很大，因此放棄，移動端做了漸入的效果。
怎么提高閱讀體驗(yàn)？
文章原本用了統(tǒng)一的背景，后來發(fā)現(xiàn)很死板，因此直接用封面預(yù)覽圖(20px)做模糊背景，實(shí)現(xiàn)起來效果還是很不錯的。
因?yàn)?#xff0c;文章大部分會涉及到代碼展示，所以支持在服務(wù)端渲染的時候支持了下代碼高亮顯示。
預(yù)覽圖加載時，為了讓用戶看到預(yù)覽圖的時候，不會覺得沒有在加載，因此，做了0.1 ->0.5透明度的animation動畫。
滾動條滾動時，讓背景和導(dǎo)航欄都變得更模糊(根據(jù)滾動范圍做0.35->0.8的透明度遞增)，讓內(nèi)容更突顯，突出主要內(nèi)容。
第八：講講其他的
接下來打算做PWA，做離線狀態(tài)下的緩存，因此，會利用阿里云的https部署https服務(wù)。這是后話了。
另外，部署方面，目前主要通過git push的推代碼，服務(wù)器 git pull拉取代碼進(jìn)行發(fā)布。接下來需要考慮如何優(yōu)化這個流程。
服務(wù)器運(yùn)維方面的知識也需要加強(qiáng)下，畢竟大概三四年沒用過windows系統(tǒng)了。
目前小實(shí)驗(yàn)室和開源項(xiàng)目兩個模塊，只簡單的實(shí)現(xiàn)了鏈接的存儲，沒有實(shí)現(xiàn)項(xiàng)目的結(jié)算，后續(xù)時間充足的話會逐步完善這兩塊。
體驗(yàn)完善，這個版本制作了很基本的體驗(yàn)考慮，接下來會根據(jù)用戶的反饋，逐步做更好的用戶體驗(yàn)優(yōu)化。
說一些最近的感想，最近有在看機(jī)會，有沒通過的，也有通過后我婉拒的。
說下沒通過的吧，暴露了我一個很大的問題，因?yàn)楸旧硎情}南人說以口音有點(diǎn)重；然后是，復(fù)述和表述能力不強(qiáng)，很多時候，沒辦法把我的想法很完整清晰的傳遞給對方，尤其是復(fù)述技術(shù)原理這種抽象畫的話題。這方面我的確要加強(qiáng)。
我婉拒的，無非兩點(diǎn)；第一，有的面試官會講很多他們自己的技術(shù)團(tuán)隊(duì)、產(chǎn)品，很能講，讓你覺得好像很強(qiáng)，然后你回家打開他們的官網(wǎng)、產(chǎn)品，或者他們的git源碼，體驗(yàn)非常rubbish，最后覺得如果你進(jìn)入了，可能沒辦法適應(yīng)他們的無規(guī)范，便罷了，在我看來產(chǎn)品體驗(yàn)很重要，我們應(yīng)該對用戶負(fù)責(zé)。第二，給的崗位不太合適的，我目前還比較有技術(shù)激情，所以，我比較偏向開發(fā)崗位比重較大的崗位，因?yàn)樵趶B門所以多小廠，小廠很多需要你去發(fā)很多精力去處理其他的事情。
總之，寫好代碼吧。
王佳欣的小站?www.shuxia123.com總結(jié)
以上是生活随笔為你收集整理的request payload怎么发_做了一个个人博客，但不知道怎么介绍的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 简述arm linux内核启动流程,Li
- 下一篇： linux下开启dhcp服务器配置,Ce