Node學習筆記2(簡短視頻學習)

1. node編寫代碼及實現遍歷文件
1.node.js雖然是寫js的，可是是運行在操做系統級別的平臺，除了前端和js語法上是同樣的，其餘東西都是不同的。它是操做系統級別的平臺，因此能夠操做底層的接口。
2.node對ES6支持很好，因此放心用。
3.node是基於CommonJS規範的語法，import是基於ES6的，最好不要混用，因此node代碼就用CommonJS規範
4.遍歷文件的node代碼，重點考察遞歸思想

2. 爲何學node、node版本升級及NVM
1.學node主要不是爲了後端，是爲了有前端的工程化思想。
2.在作項目打包的時候，wepack會依賴一些node的api來提升本身的打包效率。
3.正常狀況下電腦只能安裝一個node版本，nvm容許電腦安裝不一樣node版本，切換

3. 模塊化差別及圖片上傳服務器的過程
1.CommonJS是JS的一種規範，Node就是根據此規範的，其目標主要是在瀏覽器以外的環境構建JS生態系統；AMD也具有模塊化思想，比CommonJS更適合前端，由於AMD異步加載模塊，而CommonJS同步加載模塊；CMD和AMD相近，也都是異步加載模塊，最大區別是對依賴模塊的執行時機處理不一樣，AMD依賴前置，js能夠方便知道依賴模塊是誰，當即加載，CMD就近依賴，用的時候才require，須要把模塊變成字符串解析一遍才知道依賴的模塊。
2.AMD耦合小一點，調用的require不須要了解其實現；ES6的import是靜態引入，CommonJS是動態引入，因此import不能嵌套在邏輯語句（並且ES6的模塊要求可以編譯時就識別，不能有運行時才計算的代碼);webpack要求用exoport和import，由於能夠靜態分析。
3.高版本圖片上傳思路：input事件監聽，圖片選擇後觸發onchange事件，高版本瀏覽器有FileReader對象，調用FileReader.readAsDataURL獲取文件base64的字符串，就能夠用img標籤的src存儲該字符串，實現預覽圖片功能。點擊保存後，後端經過form表單存到服務器便可。
4.全瀏覽器兼容的圖片預覽，也是利用input框的type='file'，用onchange執行，可是沒有FileReader.readAsDataURL，直接讓input以表單形式提交給服務器後端，後端存儲完，返回一個圖片url，接着一樣利用img的src。這時點保存不用再上傳圖片了，而是保存其餘表單項。

4. token及node框架中的MVC
1.localStotage易受XSS攻擊（跨站腳本攻擊）,替代Cookie尚不成熟，無壽命，需手動刪除。
2.sessionStorage也是存儲在客戶端，可是不做爲http一部分（即每次與服務器鏈接不會自動攜帶，減小沒必要要的帶寬損失）。sessionStorage引入「瀏覽器窗口」的概念，即同源同學口，始終存在，打開其餘窗口才是不一樣sessionStorage，關閉瀏覽器時自動銷燬。
3.Cookie有其餘沒有的域和路徑的概念，經過設置可使不一樣路徑Cookie不能互相訪問，且Cookie容許的大小較小。Web Storage（也是存儲在客戶端）支持事件通知機制，能夠將數據更新的通知發送給監聽者
4.MVC模式，Model模型，View視圖，Controller控制器負責把Model和View的內容整合並返回給用戶。MVC大體就是客戶端操做視圖數據V給服務器，而後服務器經過C接收並進行相應業務處理M，而後返回給C，C生成視圖V返回給用戶；
MVP將MVC的C更名爲Presenter，使V和C基本不發生聯繫，都經由P來進行雙向通信，邏輯基本都部署在P。(感受咱們常說的MVC可能其實時MVP，而後聽說MVC應該是V->C->M->回到V自成三角循環，用戶和V互動)
MVVM是Model，View，ViewModel，訪問時被修改的Model直接反應給View，View被修改的時候也反應數據給Model，中間協調的就是ViewModel。即VM把M數據同步到V上顯示，把V的修改同步反應給M（前端上M一般指的是JS對象，V就是頁面顯示的內容）；
5.後端代碼講究MVC,Model負責數據處理，好比數據庫處理SQL（有些框架也叫Service），View是視圖展現，數據展現，C是調用M取數據，整合V。MVP通常指前端的，可是其實如今說的MVC其實大多指的是MVP（P能和M、V互動，可是M和V不直接互動）。M數據層，V視圖層，C控制層。
6.React更傾向於MVC，Vue則MVVM。由於React沒有VM層，其改變數據後頁面變化，是須要手動控制set state變化；而Vue則能經過VM層自動處理數據改變後的View和Model，能自動感知。C層控制層須要咱們手動控制，VM層自動感知並做出改變。

5. 工程化的按需加載及Git衝突解決
1.NoSQL數據庫：鍵值數據庫、列存儲數據庫、文檔型數據庫、圖形數據庫
2.MongoDB文檔型數據庫，數據靈活,能夠修改結構，好比人的信息，不用爲了多存儲人的其餘信息而從新設計數據庫；結構化、關係型數據庫例如MySQL一般用於結構關係通常不變更的場景，好比學校信息儲存等。
3.Vue不存在C層，數據M層，數據改變後，VM自動就感知了，視圖層V就是模板。平時數據的操做就是M層的。
4.Less底層的編譯是經過JS編譯的，sass底層的編譯是Ruby，二者最大差別也就這點，其餘的也就差很少是一些語法差別了；stylus比較小巧，這三個比較經常使用。之前對CSS編寫基本就是須要一個頁面對應一套，編寫修改不易；如今使用這3個，能夠在CSS裏面定義變量，能夠經過修改變量的值，就直接修改了頁面風格，極大提升開發效率。通常只用其中一個就行，畢竟功能上都是差很少的。
5.過去常靠命名空間解決CSS衝突問題（即在.css文件中使用不一樣的名字命名class等），如今有不少代替方法解決此問題。好比Vue的<template scope=xxx>,經過scope指定做用CSS只做用於XXX組件（文件），其底層經過webpack的css-loader配置參數module：true去實現文件引入樣式做用域設定（只在當前文件有效）
6.工程上的按需加載，異步組件。原理是webpack如今支持require.ensure
（能夠去看看Webpack的Code Splitting實現按需加載https://www.jianshu.com/p/b3b8fb8a2336）和import語法（這個能夠異步加載文件）。Vue自己就包含了按需加載的異步組件，只須要作一些相對應配置便可，可是好比React等要按需加載就須要引入一些額外的庫，好比reloadable.js（稍微查了一下，React應該也是CommonJS規範，那require是同步加載的）。
7.git上的衝突解決，複習git指令。線上git分支不必定能識別本地分支，可能須要用到git setOrigin設置對應關係。最後發佈時利用webpack打包master分支，發佈到CDN。能夠本身去了解下git-flow工做模式。
GitFlow詳解教程：
https://blog.csdn.net/xingbaozhen1210/article/details/81386269
簡單介紹 git-flow 流程：
https://www.jianshu.com/p/019c2053485e

6. 設計模式及node中的npm
1.觀察者模式和發佈訂閱一個類型的：解決模塊之間耦合、調用問題，經過事件監聽，來實現代碼間通訊；前端對工廠模式用的很少（SSM經常使用），即返回一個類型的實例，常和單例類掛鉤。經過觀察者模式，事件觸發代碼之間的通訊，巧妙解耦。
2.組合、繼承：將幾個模塊組合一塊兒。組合優於繼承，繼承父類子類設計複雜。
3.模塊module自己就是單例的。
（複習一下ES6，CommonJS加載模塊後，若是有緩存了，是不會再次加載的，後面只會從緩存中直接取第一次加載的結果。ES6 重複import模塊只會加載一次.）
4.npm install xxx安裝時默認會安裝最新版本。npm的package.lock、yarn.lock版本鎖，好比當地安裝 xx1.0版本，那麼將項目放到線上時，線上npm install xx時，就會參考項目的版本鎖，避免線上和本地的版本差別問題。注：npm早期版本沒有lock。

 

7. webpack後端環境的搭建及typescript
1.webpack：建議官方閱讀文檔guides->concepts->API->configuration->(LOADERS、PLUGINS，須要用到時候看)
2.webpack3和4差別極大，4已經徹底重構，性能大大提高，不少插件上的使用、配置項改變。
3.後端使用node的話，可使用pm2管理工具啓動服務器。
4.TypeScript,有不少報錯項。須要npm install @type/lodash 才能充分利用到其代碼校驗的特性。
5.Vue裏面雙向綁定指的是數據和模板的綁定；單向綁定指的是父子組件的綁定單向。
6.node在服務器渲染SSR中一般充當中間件、中間層，一般處理數據轉發、Cookie轉發，數據轉化。
7.diff算法->stack overflow、segment fault等途徑查找文章

 

8.服務器渲染文章(本身找了幾篇）
https://www.jianshu.com/p/4acde8b6e5e3
https://www.cnblogs.com/zhuzhenwei918/p/8795945.html
https://www.cnblogs.com/zhuzhenwei918/p/9266407.html