Framework7中文问题解答 framework7和 vue 的相似和不同 怎么配合cordova3

1

们经常在选择哪个前端框架进行开发而苦恼，下面对Framework7（以下写作F7）和vue的主要区别进行粗略比较，
让我们一同建立一个更有效的支持，我有时间会不停增加
（有问题欢迎提出问题和改进建议，更欢迎指正错误，此贴会根据问题总结情况进行完善）。

相同和相似处

  • 都支持单文件方式加载和创建component
  • 组件的主要属性非常相似
  • 都有强大的路由

不同之处

  • F7提供了ui的美化和很多动画和过渡，不过同时也会带来一些黑盒子的情况
  • vue在ui的美化、动画和过渡基本要靠开发者自行定制，当然可以利用一下第三方插件
  • F7同时提供了DOM7作为DOM操作的支持，书写方式非常象jquery

具体编程过程中的困扰

1、首先要改变编程习惯，从vue过渡还好说，从jquery过渡要注意尽量别再直接$(document)对DOM元素进行操作，那样造成的浏览器资源消耗很严重。

2、强烈推荐用component的方式加载页面，为此F7[v3.2]后引入了virtualnode的方式，很象mvvm，可以通过$setState()属性调用随时遍历所在页面的数据变动。

3、采用F7的首先是注意严格按照layout层级结构的要求进行html文件编写index页面和模板代码
容易出现的错误：因为层级结构不对造成页面显示不了或者init过程失败

4、关于js文件加载顺序，当F7和Cordova配合的时候应该是先cordova.js,后framework7.js
容易出现的错误：v3以前的版本没有对Cordova的加载和deviceready进行监控，容易出现cordova和F7实际加载顺序不对出现故障。

5、关于this，由于组件加载方式是先插入DOM，然后绑定事件和加载方法，所以在组件内部的代码编写一定要用var self = this； self.$… 防止自己挖坑，追踪麻烦。

6、关于@event,尽量不要再使用onClick这样的绑定方式，通过@符号来进行事件绑定方法是比较安全的方式，不过没有vue的@keyup.Ener这样的参数判断支持

7、F7还支持很多在element上的class=“somekey”完成自动化

  • <div class=“view init-view” 方式完成view的初始化，但这个属性必须在app.init之前存在
  • <a="/somepage/" class=“back” 如果“back”实在app.init前存在，会立即执行返回上一页的操作，无法打断，无法通过删除history阻止。

8、关于on,$el.on(‘event’,func…是现在就绑定到$el上，只能支持已存在的，如果$el刷新就无效了！$el.on(‘event’,selectString,func…支持委托绑定，DOM发生变化会重新绑定，刷新后依然有效。

9、关于view/router，这个基本上可以说是F7的核心了，基本所有你想要的结果都是可以通过componenturl的方式实现，而且用它给的方式可以避免出现变量、函数泄露。至于那些提供的login screen、popup等等都是针对具体场景提供的简化版的它。

10、敲黑板，敲黑板，敲黑板， 组件加载，这里必须要说一下结合上面9提出的问题，请大家一定要记得，所有我们要实现的类似于一个页面的东东都是可以通过组件的方式加载的 这一点和vue的一部分非常象，当我们不知道该怎么做了就参考一下这个代码
http://framework7.io/docs/router-component.html#component-context
这里有很详细的页面组件加载的方式和调用

11、关于@的补充，这个是给组件加载的方式专门用的，别自己按照自己的理解当成传统的绑定方法用，因为这里隐含着绑定的函数的作用域，就像我们原来说的上下文context。他是组件方式加载过程中F7进行“页内”的函数的绑定，不是全局函数！

12、关于js文件加载顺序，一般来说比较正常的加载顺序是 --cordova.js --framework7.js --app.js。因为我们要根据自己的开发需要调用相关支持，所以并不是全部按照这样的方式才正确，如果调用设备不是主要需要，那也可以优先加载F7，但是要记住所有关于设备交互代码不能优先编译

13、关于动画的取舍，我们知道F7的强项就是漂亮的过场和完美的响应式动画，但并非所有这些都是可以带来很好的用户体验的，数据加载过程使用动画过渡是很好的，但是数据变动刷新的过程就要谨慎选择了。只有一个setstate来遍历状态并不能像vue的实时变动跟踪。要注意开销太大带来的卡顿。

to be continue

3 Likes
2

上次按照你的指导解决了很多问题，非常感谢

3

好长时间没再接触Framework7，这次又拿来用了，配合electron使用，想着喜欢UI，但是还是有很多变化的！接着记录爬坑 v5.7.1

14、好多人都被routes，view，router，component搞得焦头烂额，很正常；这里提供的访问方式太多了，让人容易混乱，阅读文档的时候一定要注意参数的属性，自己不确定可以尝试；刚刚有点儿不习惯routes的利用，摸索后这里记录一下：routes是针对目标容器进行的设置，要加载在目标容器view上，而不是针对事件触发的容器，这可能和我们以往的设计方式不同；

4

15、在electron的环境下想要利用mixin来动态创建router component完成页面的动态路由和加载，结果真是山路崎岖，这里有两个坑 ：一般情况下我们采用利用preload将部分需要的接口暴露给渲染进程，关闭渲染进程的nodejs支持。动态创建component，要实现template，style，js三个部分独立文件的组合，前两个是读取字符串插入即可，js部分是要对象，这对于渲染进程中关闭nodejs的情况下是很困难的，electron提供的remote是在主进程完成加载，文件格式固定为exports的属性，组合成component后的运行脚本部分实际是在主进程完成，这就完全失去了component的意义了；另外想动态插入路由的操作实在是个让人头痛的方法，我们一般情况下不想重复加载框架，所以在框架中采用view作为页面容器，为了安全不想路由的代码部分污染全局，这一点component是非常好的思想，实践起来还是要组装component或者采用独立文件component。独立文件对于自己开发全部功能是很好的方法，但是组装component才能满足可扩展框架的要求，不然只能让所有开发扩展的工作在一个独立的文件中完成。

5

16.使用F7配合electron还是有些不适：首先在开发环境上，webpack和electron不是配合很默契，加上F7的component方式的本意是想能够动态创建页面和获取状态，但webpack需要相对静态引入的理念不是能够很好的得到解决；退而求其次的采用componentUrl的方式使用F7内置的loader加载singleFile component，就需要放弃webpack打包的优势，所以这样看来F7有点儿手伸的太长了。而且我也没明白为什么loader的项目分支为什么不继续了，可能确实这和webpack有些抵触。但总的看来component的方式需要能有个完美的加载方案才行，必须考虑和webpack之类打包工具能够和平相处！！

17.补充一下别的：接触这类的框架多了却一直没有仔细考虑过编程思路的问题，这里小总结一下：国外开发的思路多半是从被操作的对象触发去编写功能和设置属性（面向对象），这部分在浏览器的程序和页面开发上非常明显，等待用户发出指令后进行相关操作。另外此类框架的开发者多数都是前端出身，受限于前端资源的支持，主观上容易产生编程就是搭积木的理念，对于性能的追求容易被语言的解释器性能挡住，认为没有太多的方法可以提高。 这和桌面应用的开发思路上还是有不同的，桌面应用的面向对象不是指的造轮子的方式，是围绕主体功能为对象完成的，不然颗粒度太高。也许不追求极致的方式可以采用无穷的引用来达到功能，但这和我们掌控计算机并追求性能极致的思想有违。方便了开发速度的面向对象很多时候都可能把我们带入疲于奔命的编码循环中，对于真正去了解和学习编程没有太多帮助（除非我们自身也喜欢并造轮子）。 现在看，F7从开始的干净利落到现在的屈从于功能，我觉得应该也必须做减法了，不然会被功能拖垮。优化上，有时间应该做一些小实验测试一下语法的效率影响。