Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
BongBongBang opened this issue Mar 13, 2022 · 3 comments
Closed

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

BongBongBang opened this issue Mar 13, 2022 · 3 comments

Comments

@BongBongBang
Copy link

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

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

这个 API 长什么样?

减少Taro自己专属的知识点

@Chen-jj
Copy link
Contributor

Chen-jj commented Mar 13, 2022

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

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

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

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


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

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

@huiergo
Copy link

huiergo commented Nov 2, 2022

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants