js拆分字符串？永遠不變:橫向切割業(yè)務(wù)/功能，縱向切割技術(shù)層。首先，site.js按照功能劃分成幾個獨立的模塊。:如果site.js只在一個頁面上使用，會根據(jù)頁面上的功能拆分成模塊；或者site.js

js拆分字符串？

永遠不變:橫向切割業(yè)務(wù)/功能，縱向切割技術(shù)層。

首先，site.js按照功能劃分成幾個獨立的模塊。

:如果site.js只在一個頁面上使用，會根據(jù)頁面上的功能拆分成模塊；或者site.js在多個頁面中使用，可以分成一對一頁面的小入口模塊。這些頁面之間可能有類似的模塊，這些模塊也是分開的。入口模塊放置每個頁面的獨立邏輯，并組織共享模塊。以一個聊天工具為例，可以拆解為:

雖然是并列放置，但是組件是有層次的，小組件有獨立的功能。大組件負責(zé)初始化和組合小組件。

然后從技術(shù)架構(gòu)的角度將代碼分為多個層。

注意，并不是所有的項目都需要劃分層次，層次可以根據(jù)項目的大小和復(fù)雜程度來劃分。越是復(fù)雜的項目，越要注意把代碼分成不同的層次，而簡單的項目就沒必要了，甚至代碼都不需要放在不同的文件里。

技術(shù)分層的方案是MVC。無論你或流行的框架如何解讀MVC，MVC都是一個隨常數(shù)變化的架構(gòu)。例如:

成分

有一個視圖控制器，視圖和控制器關(guān)系比較密切，可以放在一起:

Chat.js主要用于初始化其他模塊，綁定事件，處理事件，充當(dāng)控制器。

Style.css樣式，沒什么好說的。

有了模板，如果業(yè)務(wù)簡單，還可以直接在chat.js中去掉拼接字符串

模型

如果項目很簡單，這就是與服務(wù)器交互的部分，比如Ajax請求。如果項目比較復(fù)雜，可以分為兩層:Ajax請求和模型(視圖模型或者數(shù)據(jù)集中管理的地方)。這一部分可能在許多組件中使用，因此它可以是獨立的。

路由器

不用說，如果你的項目復(fù)雜到要有路由器，那就單獨放置。

單說組件:

模塊基礎(chǔ)包括:

Config:來自源全局或父組件的配置。

狀態(tài):自身的狀態(tài)，比如聊天是流暢還是短暫，這是其他方法操作過程中判斷進一步操作所需要的。

BindEvents:您可以在這里為$ selecting綁定事件放置大量代碼。

EventHandler:許多事件處理程序。

ModifyView:對視圖的許多更改

每一層都有許多模塊，這些模塊根據(jù)業(yè)務(wù)/功能進行細分。

工具:

分割的原則都在那里，工具的選擇并不難。

項目并不復(fù)雜也不重要，去掉后模塊也不多，可以使用像RequireJS，Sea.js這樣的加載器主要是為了處理JS的模塊化。直接壓制后，它 不用合并就可以在線運行。

項目復(fù)雜重要，模塊多，可以用browserify和CommonJS組織代碼(也可以繼續(xù)用RequireJS，生態(tài)和工具都可以)。上線時通過工具做好合并壓縮工作。

如果你采用非常標準的模塊化開發(fā)，即每個模塊都有自己的模板、控制器、樣式和圖片，那么就用webpack。webpack的優(yōu)勢就像它的名字一樣，不是js bundle，不是js loader，而是webpack，就是其他的資源也可以幫你很好的打包處理，對于完全模塊化的開發(fā)要好得多。唐 不要考慮如何組織JS以外的資源。

有什么辦法在一個頁面通過js修改另一個頁面里對應(yīng)標簽的內(nèi)容？

我想用一個前景頁面來模擬背景。

跨選項卡頁面，除非它們在同一個域中，并且相關(guān)事件嵌入在另一個頁面中，否則可以使用postmessage或localstorge。如果是iframe，跨域是不可以的，同域可以。

其他的因果技術(shù)比如逆向生成或者修改瀏覽器參數(shù)或者劫持都不算，因為普通用戶是不會做的。