首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往
您找到你想要的搜索结果了吗?
是的
没有找到

Redux + Hooks 工程实践

“都 1202 年了怎么还有人在用 Redux”——这大概不少人看到这篇文章的第一反应。首先先表明一下,这篇文章并不讨论是不是应该使用 Redux,这是一个比较大的话题,应该单独水一篇。而且社区已经存在许许多多的讨论了,你总能从几篇高赞的文章中找到一些优缺点的对比图,然后结合你项目的场景最终作出决定。我们来随便举几个团队使用 Redux 的原因。首先是易懂,Redux 被人吐槽很多的可能是写法繁琐,但是在繁琐写法的背后就没有那么多黑科技了,非常容易排查问题。另外,Redux 本质是对逻辑处理方式提出了标准范式,并且搭配得给到了一组实践规范,有助于保持项目代码书写风格与组织方式的一致性,这点在多人合作开发的项目里面尤为重要。其他的优点就不在此赘述啦。

01

前端分层:把业务逻辑从交互代码中解救出来

在分层理念中,一种通用的分层思想,是将应用分为“数据层”“逻辑层”“表现层”,在每层内,我们又可以细分。你可能会想,“分层?有必要吗?”就像我们接触毒药一样,离开了剂量谈毒是没有意义的,同样的道理,离开了具体的业务复杂度谈分层,也是没有意义的。在极为简单的应用中,我们当然要追求快速高效立马上线,但在一些企业应用中,却需要我们慢条斯理,在长达数年的岁月里慢慢推进一套系统的演进。我们谈分层,大多是在这类有比较复杂的业务逻辑的系统中去谈,这类系统可能在具体界面的呈现上实现起来并不复杂,甚至没有什么交互上的难度。但是,这类系统中的前端开发者们,常常还是很抓狂,因为一个逻辑可能被折腾死,最后一定会思考,我们如何才能合理的区分哪些代码是业务的,哪些代码是交互的,应该如何组织代码才能高效的解决自己遇到的烦恼?

01
领券