组件生命周期真心建议不要自己设计知识点

[BongBongBang]

这个特性解决了什么问题？

减少对你Taro专属技术知识点的依赖。
现在前端的技术栈跟流派太多了，跨平台框架出来，就是为了减少无意义学习成本的，taro3好容易通过reconcile实现了react开发，还非要自己去封装专属的技术点。就一个子组件的生命周期，拿onReady举例，怎么还非要通过taro自己的事件机制实现？
节省性能考虑？是的话，taro3为什么会出现。
统一开发方式，那为什么还要自己发挥？
从taro2用过来的老用户了，升级3就一堆依赖版本问题，真心不希望看到taro走成这样。remax也用过了，差点真心有点远。

这个 API 长什么样？

减少Taro自己专属的知识点

[github-actions]

等待热心的小伙伴解决问题中..., 有一些相关的 issues 可能帮助到你!

• 页面生命周期如何调用vue3 setup里的方法
• Picker组件的mode为region时，不支持官方的leve设定
• Taro 3.x Input 组件 在安卓真机中使用手写模式输入内容时，输入第偶数个字时，未触发input事件，无法正常获取输入内容

Thank you so much!

[Chen-jj]

就一个子组件的生命周期，拿onReady举例，怎么还非要通过taro自己的事件机制实现？

这个问题是因为 Taro3 基于运行时，子组件是普通的 React 组件，Taro 没有办法调用这些子组件的 onReady 方法。页面组件在 onReady 时有很多方法可以通知子组件此刻发生了 onReady，你可以理解为事件机制只是其中一种办法而已。

函数式组件没有这个问题，因为开发者调用 Taro.useReady 时提供了一个时机，让 Taro 可以对这些组件进行收集。

Taro2 是编译时，每个 React 组件对应一个原生组件，因此可以在 onReady 时对应上。

---

Taro2、3 可以看作两个完全不一样的框架，升级的 Breaking Changes 都在文档上有描述，如有遗漏可以提一下 issues~

Anyway，Taro 的理念是在小程序环境尽量提供贴近 Web 端的运行环境，但有些问题可能是无法绕过的，欢迎反馈~

[huiergo]

我想问下 taro v3.5.7 版本， onReady 现在在ios真机上没有调用， but 但是在微信小程序开发工具，和开启 真机调试的 时候，onReady调用了，请问： 这是环境不同还是什么原因呢 ？ @Chen-jj @BongBongBang @Psli
PS : 在之前v3.4.13版本是好使的~