RT

明天起床，
喂马，
劈材，
换uni-id/uni-pay

文字描述错误

app-vue下textarea组件起始标签与闭合标签之间不可存在任何字符，如果存在换行，空格，亦或是其他任意字符都会导致textarea错误，使得该组件不能正常唤醒键盘，输入文字。如下：

<textarea> <textarea /> //错误  
<textarea>  
<textarea /> //错误  
<textarea>其他任意字符<textarea />  //错误

但在微信小程序下至少可以存在换行。

以uniCloud.onRefreshToken为例，目前云对象、clientDB均会自动更新。希望将云函数也加入其中，不要只服务与uni-id-co。

uni-id-co作为云对象，不适用所有开发者。

在此帖中：https://ask.dcloud.net.cn/question/160223，Dcloud建议自写云对象（或云函数）来调用uni-id-co，此时若自写云函数调用uni-id-co，刷新token及需要登录等监听（uniCloud.onNeedLogin、uniCloud.onRefreshToken）则不会被触发。

第一步设置配置文件（不自动关闭启动图）
"splashscreen" : {
"alwaysShowBeforeRender" : false,
"waiting" : false,
"autoclose" : false,
"delay" : 0
},
第二步在app.vue页面判断token逻辑 // 直接跳转首页，后加入关闭方法
uni.reLaunch({
url: '/pages/home/index',
success: this.closeSplash
})

/ 关闭启动图/
closeSplash() {
// #ifdef APP-PLUS
plus.navigator.closeSplashscreen();
// #endif
},

有什么问题可以咨询 QQ728045048
另外接兼职unicloud开发

我简单创建小程序最简单的独立包都会报错，包独立包打包好的代码（const common_vendor = require("../../common/vendor.js")）里的require改成require.async就可以了，希望官方后面能做一下处理。
独立包配置代码
"subPackages": [{
"root": "pagesB",
"pages": [{
"path" : "a/a",
"style" : {
"navigationBarTitleText": "我就是a",
"enablePullDownRefresh": false
}
}],
"independent": true

我平常用 webstorm 写项目，为此还特意将它的保存设置成 ctrl + s 手动的，为了防止不停的给 hb 造成编译的压力。

但是，我改了之后就按了一次 ctrl + s，hb 依然能给我类似死循环的惊喜：

这是其一，其二，我改了一点点样式的问题，大概率是要崩了：

然后真机上的应用，就一直停留再加载的界面进不去了，此时我需要重新让 hb 运行项目的才行。

这是为什么呢，开发一个静态首页，我需要不停的让项目重新运行，唉。。

有时间可以远程兼职或长期合作。
要求有uniapp+ unicloud 开发经验，最好使用过vkadmin 。

联系QQ 12040、126.

如题，uni-app的官方文档对新接触uni-app的人来说，太不友好了，找个东西都很麻烦。
如，要找组件相关文档，还得去“页面”这个左侧菜单里去找。关键找到之后，感觉写得不清不楚的。
我要找uni-app组件的生命周期，可找到一看，只有vue的生命周期，并没有标注和其它各端小程序生命周期的对应关系。包括页面生命周期也一样没标注，只是页面生命周期基本和小程序差不多，还好理解。
原生小程序的一些特性支不支持也不说，看得云里雾里的。
感觉把vue的文档放进来没有太大意义，你们只需要说明和vue的区别应该就可以。
官方能把文档归类整理以及详细补充一下吗？

我目前使用的是参考官方vue3+ts+vite的cli模板示例，去除暂时不涉及到的平台的npm依赖，这样就能够使用eslint+prettier等工具链以及vscode实现更贴近传统web开发的开发体验。整体运行良好，即使需要用插件库也可以通过下载解压对应包到本地实现，唯二有个两问题一直不能很好的解决，其一就是路由跳转的类型校验。

uniapp沿用和对齐微信小程序的pages.json来实现页面路由的控制，hbuilderx可以实现一部分跳转的路由提示，但还是不够完善，且不能对无效路由做错误提示。经过几次尝试，最后终于实现了一个完美的解决方案。

最开始的时候是想通过自己封装下路由，然后import pages.json中的数据结构，去实现路由的类型校验。但是因为ts对于json的解析是直接解析成了string这个比较宽泛的类别，且无法通过类型推断(as const)去实现，详见https://github.com/microsoft/TypeScript/issues/32063。

既然无法通过json实现类型推断，那么可以转换下思路，通过ts去配置pages，但是uniapp不兼容这种方案。那么可以再进一步，通过ts配置pages，在执行uniapp的构建命令前根据这个pages.ts去生成pages.json。

理想很丰满，现实很骨感，这个思路的方向是对的，然而在实现pages.ts输出到pages.json出现了好多问题。迎面而来的是：这段逻辑（下称预构建，文件位于./prebuild.ts）需要执行构建命令前，运行在node运行时，而node运行时不支持解析ts文件类型。那很好办啊，通过ts-node去执行这个预购建脚本不就可以了。当我兴冲冲的修改package.json中的script里的prebuild为npx ts-node ./prebuild.ts，直接就报错了，不支持import。查了下ts-node文档，加了个--esm的执行参数，这下总行了吧？嘿嘿，没这么简单。

最终效果如图所示