微信小程序自定义组件(二)

微信小程序自定义组件

ps 由于作业部落貌似出了点问题,耽误了点时间,找了一个stackedit.io准备写。无奈,这是要自己建编辑器的节奏啊。没有一个能靠的注为何存在组件

组件间的关系

使用relations实现组件的关系,即父子关系。

定义和使用组件间的关系

有时需要使用如下的组件间的关系

 <custom-ul> 
    <custom-li> item1 </ custom-li> 
    <custom-li> item2 </ custom-li> 
</ custom-ul> 

在上方中,

两个<custom-ul>以及<custom-li>两个组件都为自定义组件,如果进行通信会非常的难以操作,至此通过relations完成子父组件的定义,简化通信。

同样的以上方的栗子作为举例。

继续上一个栗子,新建一个页面,在新的页面中使用组件间的关系。

由于同属于一个custom大组件,所以直接在components中新建一个custom文件夹,表示一个大的新组件

由于其拥有一个子组件,所以再新建一个li文件夹,表示custom-li

目录如下

菜鸟一枚,设置的不一定正确。也不一定是最正统的,只是感觉。╮(╯▽╰)╭

设置custom/custom.js文件的relations的值

// components/custom/custom.js
Component({
  relations: {
    './li/li' : {
      type: 'child',  // 设置关联的目标节点为子节点
    }
  }
})

接着设置祖先节点,即设置custom/li/li.js文件的内容

// components/custom/li/li.js
Component({
  relations: {
    '../../custom': {
      type: 'parent'  // 应为祖先节点
    }
  }
})

设置组件的wxml文件

<! - 组件/自定义/立/ li.wxml  - >
< view > components / custom / li / li.wxml </ view > < slot />
<!--components/custom/custom.wxml-->
<view>components/custom/custom.wxml</view>
<slot/>

接着设置page页面的wxml页面

<!--pages/ming/ming.wxml-->
<text>hello world</text>
<custom-ul>
  <custom-li></custom-li>
  <custom-li></custom-li>
  <custom-li></custom-li>
  <custom-li></custom-li>
</custom-ul>

至此完成。

关联一类组件

被微信的路径折腾的不轻,好吧,无奈,决定重新写微信路径

微信路径太坑了。

理所应当应该是

/ 根目录
../ 父级目录
./ 当前目录

结果非要

../../

至今也没搞清楚路径是这么回事。算了,决定在同一个目录下完成模块的问题,不在另外的分一个模块的文件夹了。

总说

要形成的在page下的结构如下

<custom-form>
	<view>
		input
		<custom-input></custom-input>
	</view>
	<custom-submit>shubmit</custom-submit>
</custom-form>

创建目录

创建目录如下

好啦,目录如上

这一次放弃将模块放在另外一个文件夹,这一场所有的和组件相关的内容都放在同一个文件夹下 。符合组件的精神

其中form表明该为一个form的组件。module表明组件的内容,其中module下还有一个behaviors表明是behaviors的内容的模块,input和submit表明是其子组件。

behaviors

书写behaviors的内容。

// components/form/module/behaviors/controls

module.exports = Behavior({

// ...

})

父组件

书写父组件及form的内容

// components/form/form.js

var formControls = require('./module/behaviors/controls.js')

Component({

relations: {

'formControls': {

type: 'descendant', // 关联目标的节点应为子孙节点

target: formControls // 所有设置behavior的组件的节点都为其子孙节点

}

}

})

继续书写wxml的内容,其实就是添加一个挂载点的问题。

<!--components/form/form.wxml-->

<text>components/form/form.wxml</text>

<slot/>

input组件

// components/form/input/input.js

var formControls = require('../module/behaviors/controls.js')

Component({

behaviors: [formControls],

relations: {

'../form': {

type: 'ancestor', // 关联的目标节点应为祖先节点

}

}

})

wxml

<!--components/form/input/input.wxml-->

<text>components/form/input/input.wxml</text>

<slot/>

submit组件

此为from的子组件

// components/form/submit/submit.js

var formControls = require('../module/behaviors/controls.js')

Component({

behaviors: [formControls],

relations: {

'../form': {

type: 'ancestor', // 关联的目标节点应为祖先节点s

}

}

})

继续写wxml加上一个

<!--components/form/submit/submit.wxml-->

<text>components/form/submit/submit.wxml</text>

<label><slot/></label>

json配置文件

{

"usingComponents": {

"component": "/components/component",

"body": "/components/body/body",

"custom-form": "/components/form/form",

"custom-input": "/components/form/input/input",

"custom-submit": "/components/form/submit/submit"

}

}

编写页面的wxml

<custom-form>

<view>

<custom-input/>

</view>

<custom-submit/>

</custom-form>

完成(^o^)/

至此,根据一个behaviors完成一个组件

抽象性节点

抽象节点类似于挂载点,但是和挂载点不同的是,可以通过属性来更改挂载的组件。需要注意的一点是,其值需要为静态值,不能为动态值,抽象节点只能使用静态的内容。

但是个人感觉和挂载点还是有一点类似的作用,不过这个是通过不同的条件达到调用的目的。

抽象节点核心在于调用的时候才能确定内部需要什么组件,只有调用才能确认需要的组件,核心在于将业务和逻辑分离,彻底达到消除耦合的目的。

组件的目的在于尽可能的减少业务逻辑在里面。 注意,组件的确是要尽可能的减少逻辑在里面,因为组件的核心在于复用,在于大量的复用。减少重复代码的书写,即将一段业务中的重复的,多次的抽象出来,提取成为一个组件,如果因为某些原因,必须要存在一定的业务逻辑在里面,这个时候就需要抽象节点。

抽象节点和挂载点的不同就在上方体现出来了,抽象节点是必须有的,但是挂载点可有可无

抽象节点的核心在于分离,抽象。 再次感受抽象的重要性

在组件中使用抽象节点

在自定义模板中的一些节点,其对应的自定义组件不是由自定义组件本身确定的,由调用者确定,称为抽象节点

这定义╮(╯▽╰)╭

例如下面的代码

<view>
	<label>
		<selectable disabled="{{false}}"/>
	</label>
</view>

在上方的代码中,selectable 是由调用者确定的,需要在调用的时候根据属性值进行替换

还需要在json文件中添加如下的配置

{
	"componentGenerics": {
		"selectable": true
	}
}

直接声明该节点为抽象节点,其值由调用者确定

使用包含抽象节点的组件

上方是在代码中定义抽象节点。仅仅是定义,还不能使用。

如果要是使用抽象节点,需要再次添加属性

generic 为一个选项

在page页面中写入如下内容

<custom-form  generic:selectable="component">

</custom-form>

表明引入一个组件,其中的抽象节点的selectable替换为component内容。

需要注意的是,需要在json文件中引入component的内容

默认组件

即在未指定组件内容的时候使用的组件

在组件文件夹中的json声明。

此时不需要使用true即可声明抽象节点

{

"usingComponents": {},

"componentGenerics": {

"selectable": {

"default": "/components/component"

}

}

}

自定义组件扩展

自定义组件的扩展实质为提供了修改自定义组件定义段的能力。使用自定义组件的扩展能动态的修改的自定义组件的扩展。

一直别一个及其简单的问题困扰了很久,es6中新增加的对象属性声明,并赋值,可以直接省去function关键字。关于es6

关于es6的问题,是滴,被微信官方文档的一个写法纠结了很久

```js

module.exports = Behavior({

definitionFilter(defFields) {

defFields.data.from = 'behavior'

},

})

就上方的写法,由于是一种新的写法,上方的等价于下方的内容

module.exports = Behavior({

definitionFilter: function definitionfilter(defFields) {
	defFields.data.form = 'behavior'
}

})

仅仅是一种新的es6的写法。一种声明私有函数的方式,一般在组件里声明私有函数。这个时候,可以直接省去function。
好啦,最大的障碍解决了。
## definitionfilter函数
```Behavior()``` 构造器定义了一个新的段,即```definitionfilter```段。

该函数具有两个定义段,分别是defFields 以及 definitionFilterAll 此为两个参数

下面解释这两个参数

defFields参数

对于该参数来说,是当前被调用使用的behavior,这个灰常简单不在多说

definitionFilterAll 参数

这个参数为behaviors顺序。

使用一个官方的栗子来解释吧

// behavior3.js
module.exports = Behavior({
    definitionFilter(defFields, definitionFilterArr) {},
})

// behavior2.js
module.exports = Behavior({
  behaviors: [require('behavior3.js')],
  definitionFilter(defFields, definitionFilterArr) {
    // definitionFilterArr[0](defFields)
  },
})

// behavior1.js
module.exports = Behavior({
  behaviors: [require('behavior2.js')],
  definitionFilter(defFields, definitionFilterArr) {},
})

// component.js
Component({
  behaviors: [require('behavior1.js')],
})

在上方的栗子中,每个defFelds都为当前调用的behaviors,而definitionFilterArr是这样的情况

当调用2的时候,因为会调用3的definitionFilter函数,对其内容进行更改,在3中的definitionFilter函数有两个参数,第一个参数为2的behavior的定义段,即2中的各项内容进行更改,第二个参数为3的behaviors的内容,由于3没有引用其他的behaviors,所以为一个空数组

总结,当调用的时候,第一个参数为调用者的behaviors,而第二个参数为其本身的behaviors

当进行到1的时候,将会调用2的definitionFilter,其2的该函数的第一个参数为1的behaviors,和其他的一些项,第二个参数为2引用的behaviors,由于2引用了3的behaviors,而3没有引用,所以是一个只有一项的数组,该数组的内容为2引用的behaviors,即3的definitionFilter定义段

如果当调用1的时候,要调用3的definitionFilter函数

分析,3的definitionFilter函数由2的behaviors函数调用,而2的·definitionFilter函数是由1的behaviors调用,并且3的definitionFilter函数在2中的definitionFilter函数的第二个参数的第一项(数组)中有其内容,所以需要在2中写数组,用来调用3的definitionFilter函数。

所以第2中有definitionFilterArr[0](defFields)表明是调用3的definitionFilter而参数defFields表明是2中的behaviors中的内容。

同理使用Component构造函数的时候,将会调用1的definitionFilter函数对Component内容进行更改。

最后,总结就是一句话

当调用的时候,第一个参数为调用者的behaviors,而第二个参数为其本身的behaviors

官方扩展包 https://github.com/wechat-miniprogram/computed 实现动态的计算属性

哦。貌似切图仔最重要的瀑布流还没有学习

第三方自定义组件

终于到自己的知识范畴啦。目前已经会node.js和npm,下面的就比较好学习了。

微信小程序的官方ide支持npm

官方提供有一个模板 https://github.com/wechat-miniprogram/miniprogram-custom-component

属于小程序的自定义脚手架的相关内容。

官方的事例的组件 https://github.com/wechat-miniprogram/slide-view

以及官方提供的命令行工具 https://github.com/wechat-miniprogram/miniprogram-cli

命令行工具

npm install -g @wechat-miniprogram/miniprogram-cli

东西有点多

安装完成以后进行初始化

miniprogram init [options] [dirPath]

进行选择即可。

miniprogram

即第三方的自定义组件,custom-component为创建一个空的自定义组件目录,miniprogram为一个小程序的自定义组件的快速的开始,会有一个从github上下的一个模板,写代码即可。

属于脚手架的一部分。

由于涉及到glup,暂时搁置。

目录如下

|--miniprogram_dev // 开发环境构建目录
|--miniprogram_dist // 生产环境构建目录
|--src // 源码
|   |--common // 通用 js 模块
|   |--components // 通用自定义组件
|   |--images // 图片资源
|   |--wxml // 通用 wxml 模版资源
|   |--wxs // 通用 wxs 资源
|   |--wxss // 通用 wxss 资源
|   |
|   |--xxx.js/xxx.wxml/xxx.json/xxx.wxss // 暴露的 js 模块/自定义组件入口文件
|
|--test // 测试用例
|--tools // 构建相关代码
|   |--demo // demo 小程序目录,开发环境下会被拷贝生成到 miniprogram_dev 目录中
|   |--test // 测试工具相关目录
|   |--config.js // 构建相关配置文件
|
|--gulpfile.js

即,按照上方进行构建相关的组件即可。目前src部分能看明白,暴露的接口和node.js的包如出一辙,都是直接在主文件中进行暴露出接口的,最上方两个文件,最开始接触到的是git的工作流,根据git的工作流也能明白,最后test和tools这一点还有点晕。测试用例使用下方的命令构建出测试用例。

npm run test

tools中的demo为一个演示,即开发者下载下来内容以后将会直接出现的内容,例如,文档中的使用微信小程序打开这一点就是参考这样的,

test测试工具相关目录,进行测试的工具存放的目录。例如进行自动化测试的一些脚本要书写在这里。

config.js为进行自动化构建所要进行的文件,

ps 由于构建工具未学,构建工具的学习重点肯定是配置文件的书写。以及对接口的暴露等。

至此,暂时结束微信小程序的自定义组件化,明天写插件。

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏逆向技术

框架原理第一讲,熟悉常用的设计方式.(以MFC框架讲解)

          框架原理第一讲,熟悉常用的设计方式.(以MFC框架讲解) 一丶什么是框架,以及框架的作用 什么是框架?   框架,简而言之就是把东西封装好了...

23811
来自专栏Debian社区

Linux 系统 vim 编辑器使用简明教程

vi(vim)是上Linux非常常用的代码编辑器,很多Linux发行版都默认安装了vi(vim)。vi(vim)命令繁多但是如果使用灵活之后将会大大提高效率。v...

1377
来自专栏Python

python文件和目录操作方法大全

一、python中对文件、文件夹操作时经常用到的os模块和shutil模块常用方法。 1.得到当前工作目录,即当前Python脚本工作的目录路径: os.get...

2936
来自专栏阮一峰的网络日志

PHP最佳实践

虽然名字叫《PHP最佳实践》,但是它主要谈的不是编程规则,而是PHP应用程序的合理架构。

2351
来自专栏Python小屋

使用Python读写文本文件内容

本文主要演示如何读写文本文件的内容,以及上下文管理语句with的用法。使用上下文管理语句with时,即使在操作文件内容时引发异常也能保证文件被正确关闭。 #'w...

2625
来自专栏北京马哥教育

大神带你 20 分钟学会 Ansible !

4992
来自专栏王纯的专栏

Valgrind 使用入门

Valgrind 是一套类似于 gprof 的动态检测的工具集,由于使用方便,不需修改目标程序源码,输出清晰图文并茂等优势,常被用作后台(特别是linux后台)...

2.1K0
来自专栏IMWeb前端团队

Nodejs进阶:基于express+multer的文件上传

概览 图片上传是web开发中经常用到的功能,node社区在这方面也有了相对完善的支持。 常用的开源组件有multer、formidable等,借助这两个开源组件...

4889
来自专栏Linux驱动

22.Linux-块设备驱动之框架详细分析(详解)

本节目的:     通过分析块设备驱动的框架,知道如何来写驱动 1.之前我们学的都是字符设备驱动,先来回忆一下 字符设备驱动: 当我们的应用层读写(read()...

3945
来自专栏小狼的世界

CoffeeScript学习笔记

CoffeeScript编程语言构建于Javascript之上,它可编译成高效JavaScript。可以在Web浏览器上,或者结合Node.js一类的技术构建服...

1171

扫码关注云+社区

领取腾讯云代金券