最近半年没有做小程序开发,昨天下载了新的1.02.1907081版本,这个乱码问题依然在的。
开发工具unicode支持问题[图片] 正常的目录下面是这样的 [图片] 目录名字乱码的内容是这样的 [图片] 我用的是英文版的Windows 7,非Unicode会用简体中文,但似乎crashpad项目会以比较奇特的方式直接在文件系统里面建目录? [图片]
2019-07-11看了那个带动图的反馈,我忍不住笑了。
开发者工具抖动当系统缩放在某个值的时候,开发者工具全屏就会剧烈抖动,附视频:https://sdk-data-1251552209.cos.ap-guangzhou.myqcloud.com/test/VID_20181116_153346.mp4
2018-11-19我也遇到明显卡顿,模拟器不卡,iPhone/Plus/X都卡
swiper内嵌swiper,swiper-item循环渲染过多后出现卡顿我是swiper里内嵌了swiper,swiper-item是用wx:for循环得到的。 内外层的swiper在滑动过程中都会卡顿,模拟器上不会出现卡顿,但是在真机上测试会出现卡顿。 item数量有所影响,但数量降低到2个的时候,滑动仍然感觉到明显卡顿。 这个是大概结构,放上图片后就开始各种卡,去掉图片也是。
2018-09-28感谢回复,是的,花式编译和前期处理的方法还是非常的多。我建议的支持json5在nodejs社区是被广泛使用的。改动其实并不多。就是在打包nwjs的时候,把json5的包加入进去。然后官方在加载任何一个json文件的时候,不要用require。 如果以前是这样 const fooJsonModule = require(fooJsonFile) 现在改成 const JSON5 = require('json5') const fs = require('fs') function requireJson(filepath) { return JSON5.parse(fs.readFileSync(filepath, 'utf8')) } const fooJsonModule = requireJson(fooJsonFile) 用requireJson就可以非常明确的读取json5格式,同时对json格式也是完全兼容的。
建议支持json5格式小程序的配置里面有很多json文件。但是json格式的语法是非常严格的,不可以有注释!现在市面上有个json5的扩展,支持了注释。node里面加载一个包,就可以用了。强烈建议微信工具团队能支持这个格式。 现在调试不是很方便。小程序好像不能设置默认打开页面的吧?pages数组里面第一个页面就是打开的页面。我在开发一个藏的很深的页面的时候,就只好把这个页面的路径放到`pages`的第一个。联调结束了,再挪回去。 如果支持json5格式,我就可以方便的使用注释来控制页面顺序了。希望团队考虑一下! https://github.com/json5/json5
2018-09-25这个蛮重要的,我想在slot上直接加class定义,如果slot是有内容的,class就生效。如果slot是空的,那么class尤其是padding,就没有必要生效了。希望官方能支持这个功能。
组件如何判断是否传入了slot- 需求的场景描述(希望解决的问题) 组件内部需要根据调用方是否传入了指定的 slot 来做一些处理 - 希望提供的能力 组件内部可以判断是否传入了 slot
2018-09-13做的不好原因很多,可能是来不及改bug吧,iOS不也一直被人吐槽嘛。但要说作恶要有个限度,就有点过分了。楼主请冷静。
吐槽:最近的微信升级以下言论已经在不同的帖子中分别说过了,但是还是觉得如鲠在喉、不吐不快,所以特意单独发一个帖子来吐槽一下最近微信升级给小程序带来的两个变化 1、web-view强制显示顶栏 小程序可以不显示顶栏可以说是小程序少有的几个有亮点的特性之一,开发者可以使用更多的屏幕空间来开发和设计,虽然还有一些不足(比如:不能每个页面单独设置是否需要顶栏),但是瑕不掩瑜,总体来说还是很不错的。这次升级直接就强制web-view必需显示顶栏。有用户提出web-view需要顶栏的时候我就担心官方会无脑一刀切,结果还是不幸猜中了。针对这个需求,有很多更合适的对应方法,比如开放单页面单独设置,比如给web-view加一个全局的单独设置,结果官方选了一个最愚蠢的处理方式:无脑一刀切强制显示。我一直认为升级应该以不影响现有效果,或者最起码短期内不影响为前提,官方这次是实实在在的在作恶。 2、ipad上可以横屏使用小程序 小程序的rpx特性可以说是小程序少有的几个有亮点的特性之一,不管什么条件下屏宽固定都是750rpx,这个就一举解决了困扰开发者的适配问题,虽然还有一些不足(比如:部分组件不支持使用rpx设置尺寸、部分接口返回的尺寸没有rpx),但是瑕不掩瑜,必需点赞。但是这次升级后ipad上可以横屏使用小程序,而且横屏下屏宽不在是固定的750rpx,可以说是把开发者一夜打回解放前。如果说web-view强制显示顶栏是在作恶,这个可能是属于准备不足吧,希望后续可以解决。目前还是有一个应对方法,在app.json中加入“resizable: false”强制禁止横屏使用。 另外以上两个变化在最新的(截至发帖前)开发者工具中并没有对应。 最后我想奉劝微信的技术部门,作恶也要有个限度,不要仗着自己能店大欺客就肆无忌惮,做人留一线,给自己积点德没什么坏处。还有,靓坤教导我们:做错就要认,挨打要立正。不要认为自己是腾讯大厂的,承认自己做错或者不会做是折了面子,把bug硬说成feature这种把戏一直玩就没意思了。 再补一个,我上周发了一bug贴,说ipad横屏宽度不是750rpx,结果官方的回复要我提供代码片段。呵呵,ipad横屏宽度是不是750rpx,自己作为官方心里没点数吗?
2018-09-04按照道理说,rpx应该是按照dpi重新计算的实际像素。是不是大尺寸设备的dpi算错了?
rpx在ipad上问题太多了,rem又被限制了又没有合适的布局方式rpx在手机上不错,达到了,各个分辨率上显示效果一直。 但是ipad上,就整个完蛋了。 字体大的要死 能不能 让开发者 通过类似 @media screen and (min-width: 700px) 重新定义 1rpx = 多少px; rem也和网页的不一样了,也没办法做到 我在page上定义fon-size。我只要更改page的fon-size下面的使用rem的单位也跟着变 现在目前能想到的就是,全部再改成px,给所有的px,在不同的分辨率下,全部复制粘贴,复杂粘贴 啊,hao麻烦呀。蛋疼 为什么 rem 都被 定死 了 现在好后悔上了rpx,在ipad完全糟糕,难受,得重新写了,之后会出 让开发者定义 1rpx = 多少px吗
2018-09-04我分享一下我的几种比较土的方法: 方法一: page{height:100%} view.h100{height:100vh; overflow:scroll;} scroll-view.h100{height:100vh} 方法2: 我用的是bootstrap4的flex布局class 外面的用d-flex 内部需要占满剩余空间的元素用flex-grow-1
scroll-view不全屏的情况下怎么占满剩余空间?似乎不能使用calc和rpx来计算?
2018-09-04你需要这样写 [代码]async [代码][代码]function[代码] [代码]yourHandleDataFunction() {[代码] [代码] if[代码] [代码](res.statusCode == 200) {[代码] ... const squareItems = {} [代码] await Promise.all(res.data.map((item, index) => async () {[代码] [代码] const data = await that.getSquareList(item.square_id)[代码] [代码] squareItems[item.square_id] = data[代码][代码] })[代码] [代码] that.setData(...)[代码] [代码] }[代码] [代码]}[代码]
数组遍历完成设置data总是空[图片] 打印squareLists是空
2018-09-02