其中小程序的構成是由.wxml
、.wxss
、.js
、.json
四種類型構成(下文將簡稱爲四類文件)。其開發方式跟傳統網頁開發是十分相似的。css
.wxml
模板文件對應爲傳統網頁開發的.html
文件,是一個頁面(組件)的骨架。只不過它裏面採用的語法跟傳統的HTML
語法有些差別, 好比標籤的名稱是微信本身在底層封裝的組件。.wxss
樣式文件則對應CSS
樣式文件,具備大部分CSS
的特性(好比css3
的某些僞類特性就沒有,但常見的css3
屬性卻是能夠用),除此以外還在此基礎上作了新的擴展。js
一直都是做爲跟頁面交互角色,在小程序開發中也不例外。js
中,可使用微信提供的API
。如常見的Page
(構造器)和Component
,還有微信給出的一些特定權限的API.json
則是配置文件,通常是頁面或者組件內那一級的配置文件。(這裏有個小細節能夠區分wxml
和wxss
區別,這二者都是以wx(微信)
爲開頭,後面的小尾巴是區別是樣式文件仍是模板文件)。html
具體的更多細節能夠去看官網文檔。本文的重心仍是在討論項目結構如何安排會比較整潔合理。css3
每一個小程序項目的根目錄會有一個project.config.json
的項目配置文件,能夠設置miniprogramRoot
屬性指定小程序源碼的目錄, 默認爲根目錄(/
)。意思是說把源代碼放在/src/
下的目錄也沒有問題,筆者採用的是源碼在根目錄方式。git
首先,小程序規定:一個小程序主體部分由三個文件組成,同時必須放在項目的根目錄。json
app.js
須要在裏面調用App()
函數,註冊一個小程序。app.json
小程序進行全局配置,決定頁面文件的路徑、窗口表現、設置網絡超時時間、設置多 tab 等。app.wxss
全局樣式,做用於每個頁面。但注意的是app.wxss
寫的全局樣式不會影響組件內的樣式。├── app.js ├── app.json ├── app.wxss └── project.config.json
小程序是由許多頁面組成的,所以咱們須要一個目錄來存放頁面, 咱們一般把這個文件夾命名爲/pages/
。app.json
的pages
是一個數組,數組的每一項是用來指定頁面的路徑,框架會根據路徑自動去尋找相對位置的四類文件(小程序的代碼構成)。數組第一項爲小程序入口頁面。小程序
每一個頁面爲單獨的一個目錄, 頁面的四類文件使用統一的名稱。這裏咱們跟官方同步,四類文件跟隨目錄的名稱走:api
├── pages │ │── home │ │ ├── home.wxml │ │ ├── home.js │ │ ├── home.json │ │ └── home.wxss │ └── user │ ├── user.wxml │ └── user.js ├── ... └── project.config.json
除此以外,在開發小程序時,頁面是會分主要頁面和次要頁面(子頁),子頁一般是一些列表頁詳情頁的東西。理論上只會有一個入口能跳的過去那種二級頁面。若是這樣的子頁一多,而後全都放在了/pages/
目錄下,就會致使目錄列表變得龐大,會比較難找...數組
這時能夠考慮換一種方式儲存,在頁面文件夾裏再加一個文件夾, 名爲subpage
。把子頁放在這個文件夾內,這樣層級關係就清晰了,缺點就是不適合套太深。或者說一個產品也不該該把頁面藏得太深讓用戶找不到...微信
├── pages │ └── home │ ├── subpage │ │ └── detail │ │ ├── index.wxml │ │ └── ... │ ├── home.wxml │ └── ... ├── ... └── project.config.json
至於項目簡單一些的話前者會好一點(子頁命名參照master-description
的格式),頁面太過複雜的話可能會比較推薦使用後者的方式。網絡
既然有了頁面,那麼頁面必不可免會須要引用到圖片。圖片大體能夠分爲業務類和公共類。一些能夠複用的圖片咱們能夠放在同一個地方統一管理。而業務類則放在對應的頁面目錄下, 命名格式推薦爲dir@description
:
├── iamges (公共圖片) │ │── icon │ │ ├── icon@download.png │ │ └── icon@cancel.png | └── ... ├── pages │ └── index │ ├── images │ | └── index@bg.png │ | └── index@video.png │ ├── index.wxml │ ├── index.js │ ├── index.json │ └── index.wxss ├── ... └── project.config.json
但值得注意的是,在js中使用import
引入圖片時不能經過根目錄進行查找,而wxml
則沒有這種限制。
<!-- 絕對路徑 --> <images src="/images/icon@download.png" /> <!-- 相對路徑 --> <images src="./images/index@video.png" />
// 會報錯 import iconDownload from '/images/icon@download.png' // 只能使用相對路徑 import iconDownload from '/../../icon@download.png'
寫完頁面後天然須要給頁面潤色, 咱們能夠經過在頁面的.wxss
來寫局部樣式,這沒問題。但在咱們完成一個又一個頁面後,這時你可能會發現有些頁面的樣式重複性過高了。
由於一個成熟的設計師,在設計每個產品時,大多會有一套設計風格或者稱之爲主題的東西。這些元素大量重複在各個頁面中,咱們重複寫這些樣式實際上代碼是有點冗餘的。
{% asset_img button.png 主題按鈕 %}
這時有經驗的開發者很天然就會想到將重複性的代碼抽出來,所幸微信提供了@import
語句能夠導入外聯樣式表。而這些通用的樣式能夠放在/style/
目錄下
├── style │ ├── button.wxss │ └── ... ├── ... └── project.config.json
直接在.wxss
的頂層引入便可複用。
@improt '/style/button.wxss'; /* other code */
至因而爲什麼不在app.json
中設定全局樣式而單獨抽出來的緣由也是前文所說起的問題————組件中默認狀況下不受全局樣式影響的,理論上組件也不應受到外部樣式的」無心「的影響。
但app.json
中的樣式只須要加載一次就全局可用,外部樣式就不必定了(由於沒有實際的調研過),並且還須要額外的去作引入的那一步。具體用哪種方式仍是要看具體狀況來本身斟酌啦~
還有一些方法,好比使用scss
、less
之類的預處理之類的方案,也是能夠,只不過超出了本文的討論範圍,不展開講。
組件對於熟悉模塊化開發的同窗天然不陌生,小程序基礎庫版本 1.6.3
就開始支持自定義組件了,至今爲止也不用擔憂兼容性的問題了。從筆者角度來看見解,小程序的組件能夠分爲全局組件和局部組件。
全局性是指那種封裝了登陸、彈框、動畫組件等等之類的組件,局部的大可能是減輕一個頁面內的複雜度,經過模塊"搭積木"的方式來組成一個頁面。即便某個功能砍了也能對頁面減小牽連。
咱們習慣於將全局性的東西放在源碼的根目錄上,所以會在根目錄上建立/components
文件夾,裏面存放全局性的組件。
其中全局性的組件有很多會有同等類型的組件,由於能夠再進一步的分類,如動畫類組件存放爲一個文件夾內。
再利用編輯器的文件名排序的特性,能夠加上@
提早組件集合。
組件下的四類文件按照componment/index
的方式命名與page
區分。
├── componments (公共組件) │ │── anima │ │ ├── coin │ | | ├── index.js │ | | └── ... │ │ └── liquid │ | └── ... | └── ... ├── pages │ └── home │ ├── componments │ | └── goods │ | ├── index.wxml │ | └── ... │ ├── home.wxml │ ├── home.js │ ├── home.json │ └── home.wxss ├── ... └── project.config.json
在原生小程序開發中,通常在源碼的根目錄下,都會有一個utils
文件夾,專門來幹雜七雜八的髒話累活。其中包含工具類函數、API
的管理、配置信息等。
├── utils (工具集) │ │── api │ │ └── ... | ├── ... (其餘工具類) | ├── config.js | └── local.config.js (本地配置,git忽略) ├── ... └── project.config.json
當小程序的資源大小超過了2M
時,進行預覽調試時就會報文件過大的錯誤,這時你可能就須要進行分包,將資源分開加載。小程序文檔給出的目錄結構是:
├── app.js ├── app.json ├── app.wxss ├── packageA │ └── pages │ ├── cat │ └── dog ├── packageB │ └── pages │ ├── apple │ └── banana ├── pages │ ├── index │ └── user └── utils
但通過咱們在項目中嘗試,咱們發現經過編輯器的字符串排序後,會破壞目錄結構的清晰度,因此推薦將分包放置到一個文件夾內。
├── subpackages (分包) │ │── news │ │ └── ... | └── store │ └── ... ├── ... └── project.config.json
最後的一個小程序項目主體結構大體是:
├── components (公共組件目錄) │ ├── @anima (動畫組件) │ └── ... ├── images(公共圖片) │ └── icon │ ├── icon@download.png │ └── icon@cancel.png ├── pages(主包目錄) │ └── home (app.json 設置的入口頁) │ ├── home.wxml │ ├── home.js │ ├── home.json │ └── home.wxss ├── style(公用樣式目錄) ├── subpackages(分包目錄) │ │── news | └── store ├── utils(公共模塊,工具類) │ ├── config.js(項目配置) │ └── local.config.js (本地配置,git忽略) ├── .editorconfig ├── .gitignore ├── app.js ├── app.json ├── app.wxss ├── project.config.json └── README.md
以上是從原生小程序開發的角度來對項目結構的設計進行一個思路總結,沒有過多的講更深刻的東西。下一期想整理一下關於API
封裝和管理,歡迎指導~