asp.net core mvc 中间件之WebpackDevMiddleware
asp.net core mvc 中间件之WebpackDevMiddleware
-
WebpackDevMiddleware
中间件主要用于开发SPA应用,启用Webpack
,增强网页开发体验。好吧,你想用来干嘛就干嘛,这次主要是通过学习该中间件,学习如何在core中启用Webpack
支持 - 通过上上篇asp.net core mvc 管道之中间件,大致可以了解中间件是什么东西,现在就以中间件为单位,一个一个点学习各种中间件,了解并掌握,最后学会自己写中间件
- 该中间件源码
说明
WebpackDevMiddleware
-
Enables Webpack dev middleware support. This hosts an instance of the Webpack compiler in memory
in your application so that you can always serve up-to-date Webpack-built resources without having
to run the compiler manually. Since the Webpack compiler instance is retained in memory, incremental
compilation is vastly faster that re-running the compiler from scratch.
Incoming requests that match Webpack-built files will be handled by returning the Webpack compiler
output directly, regardless of files on disk. If compilation is in progress when the request arrives,
the response will pause until updated compiler output is ready. - 大概意思是
Webpack
编译器实例存在于内存,始终提供最新编译的资源,增量编译比重新编译速度要快得多。任何请求Webpack
编译后的文件,都原样返回,如果请求到达时编译没完成,响应将暂停,直到编译完成,输出准备就绪
NodeServices
-
Unlike other consumers of NodeServices, WebpackDevMiddleware dosen't share Node instances, nor does it
use your DI configuration. It's important for WebpackDevMiddleware to have its own private Node instance
because it must not restart when files change (if it did, you'd lose all the benefits of Webpack
middleware). And since this is a dev-time-only feature, it doesn't matter if the default transport isn't
as fast as some theoretical future alternative. - WebpackDevMiddleware不共享Node实例,也不共享使用的DI配置。因为文件改变时Node服务不能重启。这是个开发时使用的功能,所以传输速度可能不会很快
分析
- 创建Node实例
var nodeServicesOptions = new NodeServicesOptions(appBuilder.ApplicationServices); var nodeServices = NodeServicesFactory.CreateNodeServices(nodeServicesOptions);
- 创建
devServerOptions
,包含设置webpack.config.js
的路径以及整合在Stratup.cs
的设置、模块热加载断点等。这些设置需要传到Node
的aspnet-webpack
模块,如果是自定义的模块,那么参数也是自己定义啦
var devServerOptions = new { webpackConfigPath = Path.Combine(nodeServicesOptions.ProjectPath, options.ConfigFile ?? DefaultConfigFile), suppliedOptions = options, understandsMultiplePublicPaths = true, hotModuleReplacementEndpointUrl = hmrEndpoint };
- 下面是通过
nodeServices
,执行指定aspnet-webpack
模块里面的方法并得到结果。参数分别是模块文件路径、要调用的方法、传递的参数。传递给js模块的参数先序列成json字符串,模块接收参数后再反序列化成对象
var devServerInfo = nodeServices.InvokeExportAsync<WebpackDevServerInfo>(nodeScript.FileName, "createWebpackDevServer", JsonConvert.SerializeObject(devServerOptions, jsonSerializerSettings)).Result;
- 返回结果是
Webpack
编译之后的输出目录,循环输出目录,添加请求代理,代理到所有输出目录。超时时间100s,/__webpack_hmr
无限超时 - 代理源码
foreach (var publicPath in devServerInfo.PublicPaths) { appBuilder.UseProxyToLocalWebpackDevMiddleware(publicPath + hmrEndpoint, devServerInfo.Port, Timeout.InfiniteTimeSpan); appBuilder.UseProxyToLocalWebpackDevMiddleware(publicPath, devServerInfo.Port, TimeSpan.FromSeconds(100)); } // Note that this is hardcoded to make requests to "localhost" regardless of the hostname of the // server as far as the client is concerned. This is because ConditionalProxyMiddlewareOptions is // the one making the internal HTTP requests, and it's going to be to some port on this machine // because aspnet-webpack hosts the dev server there. We can't use the hostname that the client // sees, because that could be anything (e.g., some upstream load balancer) and we might not be // able to make outbound requests to it from here. // Also note that the webpack HMR service always uses HTTP, even if your app server uses HTTPS, // because the HMR service has no need for HTTPS (the client doesn't see it directly - all traffic // to it is proxied), and the HMR service couldn't use HTTPS anyway (in general it wouldn't have // the necessary certificate). var proxyOptions = new ConditionalProxyMiddlewareOptions( "http", "localhost", proxyToPort.ToString(), requestTimeout); appBuilder.UseMiddleware<ConditionalProxyMiddleware>(publicPath, proxyOptions);
结果
- 创建自己的中间件,自定义配置,运行
Webpack
服务,只需要创建Node
实例,调用自己写的模块即可。模块根据传过来的配置运行服务即可 - 关键方法
var nodeServicesOptions = new NodeServicesOptions(appBuilder.ApplicationServices); // node配置 var nodeServices = NodeServicesFactory.CreateNodeServices(nodeServicesOptions); // 创建node实例 // dev服务配置 var devServerOptions = new { webpackConfigPath = Path.Combine(nodeServicesOptions.ProjectPath, options.ConfigFile ?? DefaultConfigFile), suppliedOptions = options, understandsMultiplePublicPaths = true, hotModuleReplacementEndpointUrl = hmrEndpoint }; // 调用js模块,运行dev服务,返回输出目录 var devServerInfo = nodeServices.InvokeExportAsync<WebpackDevServerInfo>(nodeScript.FileName, "createWebpackDevServer", JsonConvert.SerializeObject(devServerOptions, jsonSerializerSettings)).Result; // 添加输出目录到代理 foreach (var publicPath in devServerInfo.PublicPaths) { appBuilder.UseProxyToLocalWebpackDevMiddleware(publicPath + hmrEndpoint, devServerInfo.Port, Timeout.InfiniteTimeSpan); appBuilder.UseProxyToLocalWebpackDevMiddleware(publicPath, devServerInfo.Port, TimeSpan.FromSeconds(100)); } private static void UseProxyToLocalWebpackDevMiddleware(this IApplicationBuilder appBuilder, string publicPath, int proxyToPort, TimeSpan requestTimeout) { var proxyOptions = new ConditionalProxyMiddlewareOptions( "http", "localhost", proxyToPort.ToString(), requestTimeout); appBuilder.UseMiddleware<ConditionalProxyMiddleware>(publicPath, proxyOptions); }
示例
- 待更新...
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
JVM Profiler 整体架构
开篇 整个JVM Profiler的组件类似于上图,抽象出来主要分为: Class File Transformer:负责转换被监控方法的字节码,在前后增加耗时统计。 Profiler:负责数据的采集,各种指标的采集器。 Reporter:数据上报方法,支持kafka,Console,Redis,File等多种方式。 组件介绍 Profiler介绍 CpuAndMemoryProfiler:负责采集cpu和内存指标的Profiler。 IOProfiler:负责采集机器IO指标的Profiler。 MethodArgumentProfiler:负责采集被监控方法参数的Profiler。 MethodDurationProfiler:负责采集被监控方法耗时的Profiler。 ProcessInfoProfiler:负责采集Process相关信息的Profiler。 StacktraceCollectorProfiler:负责Stack相关信息的Profiler,细节还没弄清楚。 StacktraceReporterProfiler:负责Stack相关信息的Profiler,细节还没弄清...
- 下一篇
揭秘React同构应用
随着React和Redux为服务端渲染提供了优良特性,同构应用变得越来越普遍。作为开发者,即使采用的技术架构并不是基于服务端渲染的同构设计,也很有必要对同构设计进行了解并掌握其原理。 前后端架构设计和服务端渲染概念 服务端渲染或直出的概念越来越流行。在了解如何基于React实现服务端渲染之前,我们有必要在架构层面对服务端渲染的“前世今生”进行整体了解:为什么会出现这样一个概念;这个概念落地之后能解决什么问题;服务端渲染和其他方式对比有何利弊等。 前后端配合技术的演进 早期的Web开发,架构设计简单、直接,具体来讲,就是页面由JSP、PHP等工程师在服务端生成,浏览器只负责展现。那时候,前端工程师只需要给静态页面添加一些动态交互效果,很少会涉及数据逻辑等;而后端工程师负责页面内容,即当用户请求页面时,后端进行处理并返回完整的静态页面。这些过程一般会依靠模板引擎来完成。因此,在那个时候,甚至没有独立的前端工程师职位。即使有的话,这种做法的缺点也很明显,比如前后端分工职责不清。 如果由前端人员来开发模板,那么前端将会极度依赖后端环境,难以实现开发效率的最大化,同时关于数据格式的沟通成本也相对...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- CentOS6,CentOS7官方镜像安装Oracle11G
- CentOS7安装Docker,走上虚拟化容器引擎之路
- CentOS7设置SWAP分区,小内存服务器的救世主
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- CentOS8安装Docker,最新的服务器搭配容器使用
- Docker安装Oracle12C,快速搭建Oracle学习环境
- CentOS关闭SELinux安全模块
- CentOS6,7,8上安装Nginx,支持https2.0的开启