簡単に言うとノウハウのアプレット開発
ここで設定アプレットによって.wxml、.wxss、.js、.json（以下、単に4つのファイルと呼ばれる）の構成の4種類。従来のWeb開発とその開発のアプローチは非常に似ています。
.wxml従来のWeb開発にテンプレートファイル対応.htmlファイル、スケルトンのページ（組み立て）。しかし、その中で使用される伝統的な構文とHTML構文などのラベルの名前としていくつかの違いは、パッケージの底に独自のマイクロチャネル成分です。.wxss対応するスタイルファイルCSSのほとんどはスタイルファイル、CSS特性（のようなcss3いくつかの擬似クラスのプロパティはありませんが、一般的なcss3プロパティは、とフィットを行います）、まだこれに基づいて、新たな拡張を行うことに加えて、。js常にページとの相互作用の役割をしてきたように、アプレットの開発も例外ではありません。マイクロ流路を提供するために使用することができます。一般的な（コンフィギュレーション）とAPI、およびマイクロチャネル所与のアクセス特定の権限。jsAPIPageComponentjson設定ファイルは、設定ファイルは、通常、ページまたはコンポーネントそのレベルの範囲内です。
（区別することができ、小さなディテールがあるwxmlとwxss基づいていますどちらも、区別wx(微信)小さな尾の背中の始まりのためには、スタイルファイルやテンプレートファイルとの間の差です）。
より具体的な詳細は、に行くことができる文書の公式サイト。この論文の焦点は、より合理的かつクリーンになり、プロジェクトの構造を配置する方法を検討しています。
プロジェクト構造のデザインのアイデア
各アプレットプロジェクトのルートがありますproject.config.jsonプロジェクトのプロファイルを、あなたが設定することができminiprogramRoot、ルートディレクトリにデフォルト（、アプレットのソースコードディレクトリ属性を指定します/）。ソースコードというこの手段/src/ディレクトリは問題ではありませんが、著者は道のルートにソースを使用しています。
まず、小さな手続き要件：小さなプログラム本体の3つのファイルで構成され、プロジェクトのルートディレクトリに配置する必要があります。
app.jsあなたは、内部で呼び出す必要がありApp()、小さなプログラムを登録し、機能。app.jsonグローバルに設定パスのアプレット、ページファイルの決定、ショーウィンドウには、マルチタブの設定など、ネットワークのタイムアウトを設定します。app.wxssグローバルスタイル、すべてのページに作用します。しかし、ことは注目app.wxssグローバルなスタイルで書かれたスタイルは、コンポーネントには影響しません。
├── app.js
├── app.json
├── app.wxss
└── project.config.jsonページ
アプレットは、我々は通常、このフォルダの名前は入れて、我々はページを保持するディレクトリを必要とするので、多くのページで構成されています/pages/。アレイは、各アレイは、ページへのパスを指定するために使用され、フレームは自動的に4つのファイル（アプレットコードを構成する）経路の相対的な位置を探します。配列の最初の項目は、小さなプログラムのエントリページです。app.jsonpages
各ページには、団結の名前を使用して、ファイル・ページの4種類の別のディレクトリです。ここでは、行くためにディレクトリ名を次の書類の公式、4種類と同期：
├── pages
│ │── home
│ │ ├── home.wxml
│ │ ├── home.js
│ │ ├── home.json
│ │ └── home.wxss
│ └── user
│ ├── user.wxml
│ └── user.js
├── ...
└── project.config.jsonまた、小型の手順の開発では、ページが分割されますメインページや二次ページ（サブページ）は、サブページは、物事のリストページのストーリーページの一部が通常です。理論的には、唯一の入り口を過ぎてジャンプすることができ、二次ページのようなものがあるでしょう。そのような子より1ページ以上ならば、その後、すべての上/pages/のディレクトリ、それはディレクトリリストにつながる巨大になり、それを見つけるのはもっと難しいだろう...
次に、ページのフォルダのプラスと呼ばれるフォルダに、店舗への別の方法を考えることができますsubpage。階層関係が明確であるように、このページフォルダのハンドルが、欠点は、深いセットには適していません。または製品は、ユーザーが見つけることができないように、あまりにも深くページに隠されてはならないということ...
├── pages
│ └── home
│ ├── subpage
│ │ └── detail
│ │ ├── index.wxml
│ │ └── ...
│ ├── home.wxml
│ └── ...
├── ...
└── project.config.json単純なプロジェクトについては、前者が良くなる（基準命名サブページmaster-description形式）、ページがあまりにも複雑で、それはより後者のであってもよいが推奨されます。
絵
既然有了页面，那么页面必不可免会需要引用到图片。图片大致可以分为业务类和公共类。一些可以复用的图片我们可以放在同一个地方统一管理。而业务类则放在对应的页面目录下, 命名格式推荐为dir@description:
├── iamges (公共图片)
│ │── icon
│ │ ├── [email protected]
│ │ └── [email protected]
| └── ...
├── 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/[email protected]" />
<!-- 相对路径 -->
<images src="./images/[email protected]" />// 会报错
import iconDownload from '/images/[email protected]'
// 只能使用相对路径
import iconDownload from '/../../[email protected]'样式
写完页面后自然需要给页面润色, 我们可以通过在页面的.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.jsonutils
在原生小程序开发中，一般在源码的根目录下，都会有一个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
│ ├── [email protected]
│ └── [email protected]
├── 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封装和管理，欢迎指导~