- 内容简介
- 译者序
- 前言
- 第 1 章 安装配置新项目
- 第 2 章 Flexbox 布局介绍
- 第 3 章 用 React Native 开发一个应用
- 第 4 章 在 React Native 中使用导航
- 第 5 章 动画和滑动菜单
- 第 6 章 用 React Native 绘制 Canvas
- 第 7 章 使用 React Native 播放音频
- 第 8 章 你的第一个自定义视图
- 第 9 章 Flux 介绍
- 第 10 章 处理复杂的应用程序状态
- 第 11 章 使用 Node 来实现服务端 API
- 第 12 章 在 React Native 中使用文件上传
- 第 13 章 理解 JavaScript Promise
- 第 14 章 fetch 简介
- 第 15 章 在 iOS 中使用 SQLite
- 第 16 章 集成 Google Admob
- 第 17 章 React Native 组件国际化
- 附录 A React.js 快速介绍
- 附录 B Objective-C Primer
- 附录 C webpack 入门
文章来源于网络收集而来,版权归原创者所有,如有侵权请及时联系!
使用 ReactJS 的弊端
如果你对 ReactJS 组件比较熟悉,并且正在开发富交互的组件,那么你应该会遇到 method 地狱的问题。所谓 method 地狱是指以下伪代码:
<Button onPress={this.onPress}>My Button</Button>
this.onPress 方法有如下模式:
onPress: function(){ // 根据当前状态做些处理 // 或者同服务器进行一些交互 // 或者使用 local storage 进行一些处理 }
想象一下,如果你有许多这样的 button,就会发现这种写法的一些弊端:
- 不能很好地进行扩展。如果你要在许多组件中都添加一个新的 JSON 请求,就不得不在每个组件中都复制一遍代码。
- 可读性和可维护性差。太多的代码意味着难以跟进调试和测试。
- 组件的可移植性不再像以前那样强。如果你在一个组件中引入了太多高耦合的代码,那么在将该组件渲染到其他组件(作为子组件或者父组件)中时,就会出现许多问题。
- 这种写法违背了 Single space of Truth 模式。记住,当你在为一个后台设计分层组件模型时,你有视图层、业务模型层和数据操作层。如果数据操作层是你访问和操作数据库的唯一方式,那么数据操作层就是 Single place of Truth。
几个月以前,当 Flux 模型没有对外公布、尚不为外界所知时,我遇到了上述所有问题。这致使我走入了一个不可维护的体系结构。我相信你的项目在刚开始时一定是一个很棒的项目,并且你也希望随着时间的推移将项目不断更新下去,从而为客户提供更多的功能和价值。所以,请不要使用上文的这种做法,取而代之,使用 Flux 吧。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论