react前端架构图_做“传统行业外包”的前端工程师的2018

最新推荐文章于 2024-07-25 10:34:29 发布

人体疾病研究室

最新推荐文章于 2024-07-25 10:34:29 发布

阅读量789

点赞数

文章标签： react前端架构图

本文链接：https://blog.csdn.net/weixin_42561623/article/details/113452643

版权

本文介绍了从jQuery过渡到React的前端开发过程，包括选择React的原因，如何处理IE8兼容性，开发工具的演进，简洁的Redux实现，权限控制策略，以及对未来前端架构的探索和规范制定。文章还讨论了GraphQL、Web开发模式的思考，并提到了San.js框架在资源和支持方面的挑战。

摘要由CSDN通过智能技术生成

从2.5人到8人，从JSP到前后端分离，从JQuery到React，从没有自动化构建到有自己的覆盖全流程的开发工具，从没有工程化到有自己的架构等等。
我是一名前端工程师，跟大家分享一下我们2018年走过的一些路。

都已经8012年了，我们才从从JQuery到React，对不起是我来迟了！

IE8！！！对的，就是为了兼容IE8，找了一堆的react-like的框架的，改写了一大堆的代码，在项目的压力下，做了简单的测试就开始投入使用了，当时我只写过Vue，和几行React，写了简单的demo，嗯，ie8能跑，开始撸业务代码去了。

然而，这么长时间过去了，我们慢慢的抛弃了IE8，我们找了其他办法去做兼容。

第一个前后端分离的项目中，我们把webpack+babel等等的配置写在了工程里面，为了方便各个项目使用，我们把他抽离开来，然后丰富了功能，勉强成为了一个可用的工具，发展到现在，已经是全家桶一样的工具，那么他有什么功能呢：

ps: 为了兼容其他工具的使用，现在我们又重新把eslint/babel/mocha(现在改成了jest)的相关配置注进了工程里面，不过，这些当然是一键注入的，我们所有的升级都会提供一键升级的功能。

先放一张前端业务架构图。

更简洁的redux

看起来，他跟一般的react全家桶架构没什么不一样对吧。嗯是的，但是我们把redux + redux-saga + xhr + 界面反馈耦合到一块去了。

这样做使得我们不用定义一堆的type + action + reducer + saga，不用去梳理每一次数据操作，不用去处理错误，不用去设置界面反馈（多种反馈可选），不用去操心怎么存数据，只管dispatch，这些东西只需要来自一个最少一个选项的配置即可。

当然这样耦合当然也有不好的地方，例如单元测试显得没那么透明清晰。

权限控制

我们基于react-router做了权限控制组件，配合一份权限配置以及我们的开发工具，能够很方便的做数据模拟，做开发，部署。由于我们是基于context的，任何元素的权限控制自然不在话下啦。

真正的架构

再放一张整前端架构图：

没错，组件市场我们有了，配套的私服和贡献工具肯定是有的。然而，应用市场是我自己虚构的东西，希望把服务或者应用细分，然后项目有这些简单组装。

虽然生活很苟且，但是还是得不断的探索，对吗？

GraphQL：其实我已经在内部分享过一次了，带着像极了spring的nestjs的demo，可是大家都这么忙对吧（你懂得）。
最佳的web开发方式：我个人觉得，web开发就不应该分前后端，前后端分离搞得前后端的隔阂与矛盾越来越多，反而，我觉得前后端统一语言（如typescript）会好一些，毕竟可以共用接口，共用校验，共用枚举，方便理解等等。

兼容IE

我们有其他的几套方案做兼容

Sanjs：看起来san.js真的不错，可惜资源太少，就连esnext的样例都不能在ie8及以下跑，配置一下babel，加加补丁就能解决的事情，别人一看不兼容马上跑了。san-store没有connect使用派生也是一个大隐患，解决了这些，搞个san-saga，再搞个最佳实践，用户多了，UI组件库自然会有累积吧。
控件：这个别人做的，我就不详细说了。
React-like：社区了大把方案了啊