React框架概述,react框架( 二 )


1. 改造前页面2. 在webpack.config.js中增加rules3. 在工程中使用带 xxx.bunlde.js结尾的类型文件时 , 就会被bundle-loader识别并做编译处理4. 创建LazyBundle.js文件 , 这个文件会用来调用被bundle-loader处理后的组件5. 对我们需要异步加载的组件函数进行二次封装注:react-router3和4由于是不兼容升级 , 所以处理动态路由的方法也略有不同 , 在此列出了两种版本下的处理方式可供参考6. 改造后页面完成构建后我们就可以从浏览器中看到 , 我们定制后的模块已经被能被支持异步加载了同时在webpack构建中也能清晰地看到多了一个chunk:高阶版实现:dynamic-importsdynamic-imports是webpack在升级到2版本以后 , 对js的模块处理进行了增强的 , 其中就有对require.ensure的改进 , 基于原生的Promise对象进行了重新实现 , 采用了import()作为资源加载方法 , 将其看做一个分割点并将其请求的module打包为一个独立的chunk 。
import()以模块名称作为参数并且返回一个Promise对象 , 具体介绍可以参考笔者之前写过的翻译文章Webpack2 升级指南和特性摘要 , 具体使用比对如下:结合import的高级特性 , 我们就可以省去bundle-loader的处理方式 , 直接在原生模块上进行动态路由处理 , 具体设计实现如下:1.封装一个高阶组件 , 用来实现将普通的组件转换成动态组件2.对我们需要用到的普通组件进行引入和包装处理利用weback3中的Magic Comments对生成的chunk指定chunkName完成构建后我们就可以从浏览器中看到 , 我们定制后的模块也和之前一样 , 被能被支持异步加载了同时在webpack构建界面中的能看到多了一个chunk , 并且chunkName就是我们自定义的名称 , 对于定位分析一些模块问题时会非常管用 。
从中我们也不难发现 , 相对于bundle-loader , dynamic-importsAsyncComponent高阶组件的方式更为简单灵活 , 同时对于现有的代码改动也较小 , 故作为在实际开发中的首选方案使用 , 同时我们也推荐一个非常不错的webpack的chunk分析工具webpack-bundle-analyzer , 方便查看每个异步路由中的构建的具体模块内容 。
【React框架概述,react框架】One more thing:路由模块的组织react-router功能强大 , 上手简单 , 作为官方唯一指定的路由框架已经成为了react应用开发中必备的部分 , 但是由于react天生组件化的原因 , 意味着react-router的配置文件中在实际使用中 , 会难免出现如下不佳场景:1、路由配置入口文件持续臃肿 , 文件越引越多2、路由配置会随着业务嵌套越来越深 , 团队协作开发时极易产生冲突3、非jsx写法 , 模块清晰简单 , 但是会导致路由模块和业务模块耦合 , 不利于集中管理 , 同时无法明确表达出母子路由的嵌套关系 , 参见huge-apps问题来了:如何既保证路由模块的清晰简单 , 又能集中管理维护 , 还能支持嵌套定义和动态加载?借鉴python flask中的blueprint设计思路 , 重新实现路由模块的划分经过前面的分析 , 我们不难发现react-router的路由配置模块会随着业务的深入变得越来越臃肿 , 其根本原因在于我们将所有的资源和配置信息都写在了一个文件中 , 这和软件设计中提倡的清晰一单一 , 低耦合高内聚等指导原则是背道而驰的 , 为此我们针对路由模块的划分这块进行了重构 , 改进方式如下:1、拆分routes.js入口文件将路由模块的整体由一个routes.js文件拆成若干个彼此间互相独立的子路由模块文件模块的拆分原则可以和业务功能划分一一对应 , 逐步减少主配置中的内容耦合 。

推荐阅读